Website and server administrators will have to spend considerable time, effort and money to mitigate all the security risks associated with Heartbleed, one of the most severe vulnerabilities to endanger encrypted SSL communications in recent years.
The flaw, which was publicly revealed Monday, is not the result of a cryptographic weakness in the widely used TLS (Transport Layer Security) or SSL (Secure Sockets Layer) communication protocols, but stems from a rather mundane programming error in a popular SSL/TLS library called OpenSSL that’s used by various operating systems, Web server software, browsers, mobile applications and even hardware appliances and embedded systems.
Attackers can exploit the vulnerability to force servers that use OpenSSL versions 1.0.1 through 1.0.1f to expose information from their private memory space. That information can include confidential data like passwords, TLS session keys and long-term server private keys that allow decrypting past and future SSL traffic captured from the server.
At first glance, dealing with this problem appears to be easy: update OpenSSL to the patched versions that should now be available for most operating systems and it’s done. However, taking into consideration the possibility that the flaw might have been exploited by attackers by the time a particular server was patched and that its secret TLS keys might have been compromised, things are suddenly more complicated.
First step: which version of OpenSSL was used?
The first thing website owners should do is determine who is responsible for maintaining the OpenSSL software on the servers that host their sites.
“If it is a dedicated server, it is your responsibility,” researchers from Web security firm Sucuri said in a blog post. “If you are on a shared hosting platform, contact your hosting provider to remind them to update their servers.”
Once the OpenSSL installation is patched on the server and attacks are no longer possible, it’s time to obtain a new SSL certificate and revoke the old one to ensure that any private key information attackers might have obtained though the flaw won’t allow them to decrypt traffic in the future.
“The recommendation is for server operators to revoke and re-issue their certificates, since theres a possibility that secret keys may have been stolen,” said Matthew Green, a cryptographer and assistant research professor at the Johns Hopkins University Information Security Institute in Baltimore, via email. “The problem is that this takes time and money. I wouldnt be surprised if many server operators skip this step.”
Website owners should check with the certificate authorities (CAs) that issued their existing SSL certificates about any potential costs involved in re-keying and re-issuing those certificates.
Step 2: New certs
“The Trustwave SSL Services Platform has always included free certificate reissues for the life of the certificate; we have never charged for people to rekey and replace their certificates,” said Brian Trzupek, vice president of managed identity and SSL at Trustwave, a large certificate authority, via email. “In this particular instance with the Heart Bleed vulnerability to OpenSSL we have already had a large volume of customers employ the free self-service reissuance features within our SSL portal to help remediate the Heart Bleed issues with their SSL certificate.”
Symantec, which operates one of the largest CAs since acquiring VeriSign’s SSL business in 2010, said that it has taken the necessary steps to patch its systems that used affected versions of OpenSSL. “We are following best practices and have re-keyed all certificates on web servers that used affected versions of OpenSSL,” the company said via email. “While there was never an issue with Symantec Certificates, to address the OpenSSL bug we will be offering replacements free of charge for our existing customers and the old certificates will be revoked.”
Dealing with this OpenSSL vulnerability might also be a good opportunity for website and server administrators to review their SSL/TLS configurations and make sure they’re up to modern standards.
Step 3: Review existing configurations
“Since you have to touch your server configuration and create new SSL certificates, we would recommend that you also go through certificate generation settings and server configuration,” researchers from antivirus firm F-Secure said in a blog post. “Heartbleed is not the only problem in SSL/TLS implementations, a poorly chosen protocol or weak cipher can be just as dangerous as the Heartbleed bug.”
The Open Web Application Security Project’s (OWASP) Transport Layer Protection Cheat Sheet and the SSL/TLS Deployment Best Practices by Qualys SSL Labs might serve as good starting points.
It might also be a good time to consider configuring TLS with Perfect Forward Secrecy (PFS), a property of DiffieHellman key agreement protocols—DHE and ECDHE—that are already in use on some large websites, including Google. PFS makes decrypting previously captured TLS traffic impossible even if the server’s private key is compromised and Heartbleed did not affect servers that had TLS configured for PFS.
Perfect Forward Secrecy: a potent band-aid
“One of the strongest protections you can have against TLS vulnerabilities is Perfect Forward Secrecy,” said David Grant, systems administrator at advocacy group Electronic Frontier Foundation, in a blog post. “This is not simple to configure, and does not yet have global browser support. However, it is the encryption technology that provides the best defense against attacks with the potential to steal your private key and use it to decrypt your traffic.”
Ivan Ristic, who runs the SSL Labs at Qualys, provided instructions on how to configure Apache, Nginx and OpenSSL with forward secrecy in a blog post in August.
“At this moment, forward secrecy is more crucial than ever,” said Yan Zhu, a staff technologist at the Electronic Frontier Foundation, in a recent blog post in which he makes the case for wider PFS adoption on the Web. “Now that the details of Heartbleed are public, anyone can use it against servers that haven’t yet patched the OpenSSL bug and changed SSL certificates. It can easily take weeks or months for developers to deploy new SSL certificates, and even so, certificate revocation systems are unreliable and poorly-suited to the modern web. In the meantime, any data you send now to affected servers that don’t support forward secrecy will be open to eavesdropping and malicious tampering as soon as their SSL private keys are exposed.”
Because the Heartbleed vulnerability can also be used to steal passwords from the server’s memory, website administrators should assess and consider what categories of passwords should be changed as a precaution. In some cases it might be wise to force or at least advise all users to change their passwords.
In addition to resetting passwords, it might also be a good idea to invalidate all cross-site request forgery (CSRF) and OAUTH tokens, as well as session cookies. If stolen from the server memory or from decrypted traffic, such tokens could be used to gain unauthorized access to user accounts on the affected site.
Finally, it’s also important for administrators to look at their whole Web infrastructure and not just individual Web servers when assessing the impact of this vulnerability.
For example, even if a Web server runs as IIS (Internet Information Services) on Windows and is not affected by this flaw because IIS doesn’t use OpenSSL, there might be an Nginx server with OpenSSL running as a load balancer for encrypted traffic or as a reverse proxy in front of that IIS server, said Troy Hunt, a software architect and Microsoft’s MVP, in a blog post.