On April 7, 2014, a bug in the OpenSSL software library was announced by the OpenSSL organization. This bug, called Heartbleed, impacts versions 1.0.1 through 1.0.1f of OpenSSL.
Heartbleed is not an SSL bug or flaw with the SSL/TLS protocol — it’s a bug in OpenSSL’s implementation of SSL/TLS which servers rely on to create secured connections online.
What is Heartbleed?
Heartbleed affects nearly two-thirds of servers on the Internet. Chances are you administer a server affected by the Heartbleed bug or have received an email notification to update passwords because of the effect of Heartbleed.
According to the Heartbleed website hosted by Codenomicon, whose engineers were among those who discovered Heartbleed:
The Heartbleed Bug is a serious vulnerability in the popular OpenSSL cryptographic software library. This weakness allows stealing the information protected, under normal conditions, by the SSL/TLS encryption used to secure the Internet. SSL/TLS provides communication security and privacy over the Internet for applications such as web, email, instant messaging (IM) and some virtual private networks (VPNs).
The Heartbleed bug allows anyone on the Internet to read the memory of the systems protected by the vulnerable versions of the OpenSSL software. This compromises the secret keys used to identify the service providers and to encrypt the traffic, the names and passwords of the users and the actual content. This allows attackers to eavesdrop on communications, steal data directly from the services and users and to impersonate services and users.
A few things that set Heartbleed apart from other bugs are:
- It is impossible to tell if your information has been compromised by Heartbleed.
- The vulnerability has existed for over two years, which increases the scope of potentially affected. At this point, there are no known cases of this vulnerability being exploited.
- Heartbleed does not depend on any other vulnerability. Many attacks require the attacker to gain a foothold through some poor security practice, but Heartbleed does not.
- The affected versions of OpenSSL have been pushed by security experts because they contain fixes for other vulnerabilities.
The versions of OpenSSL that are vulnerable to Heartbleed are 1.0.1 through 1.0.1f, and 1.0.2-beta1. The 1.0.0 branch and earlier were not vulnerable, and the 1.0.1g version released yesterday fixes the vulnerability. (Version 1.0.2-beta2 will include the fix.)
How does Heartbleed affect you?
If your servers do not use version 1.0.1 through 1.0.1f or 1.0.2-beta1 of OpenSSL, or if they are compiled without the heartbeat extension, they are not vulnerable to Heartbleed.
Microsoft-based platforms, not utilizing OpenSSL are unaffected by Heartbleed. Java along with many other servers and network devices not use OpenSSL. Although some devices can still rely on OpenSSL, so it’s best to contact your device manufacturer or the DigiCert 24/7 Technical Support team to verify if you’re vulnerable to Heartbleed. If you are using keystores and truststores, you most likely are using JSSE rather than OpenSSL and are not vulnerable to Heartbleed.
If you’re unsure whether a site you administer or use is vulnerable, you can use the DigiCert Certificate Checker tool for free on by going to digicert.com/help. The DigiCert Certificate Checker allows users to check the security for any site on the Internet using an SSL Certificates from any Certificate Provider.
No documented cases of Heartbleed the exploit
Although there are no documented cases of Heartbleed being exploited to date, because the attack is undetectable, it is impossible to say that no attempt has been made. Compromised data has yet to be linked to Heartbleed, but if your server is running a version of OpenSSL between 1.0.1 and 1.0.1f with the heartbeat extension enabled, you are potentially vulnerable to Heartbleed and should take the steps below to address it.
If you have any question as to whether you are vulnerable, the latest version of DigiCert’s free Certificate Inspector has added Heartbleed to the lengthy list of vulnerabilities it can detect. To learn more and get access to this tool, visit https://www.digicert.com/heartbleed-bug-vulnerability.htm.
What do can do to fix Heartbleed
If you are vulnerable to Heartbleed, there are two steps you need to take:
- Update your server to the latest version so it is no longer vulnerable to Heartbleed.
- Re-key all your SSL/TLS certificates, install the new certificate, then remove all certificates that have been used with vulnerable versions of OpenSSL.
The order of these steps is very important — it’s critical that you stop the bleeding before addressing the possible damage — but both steps need to be done as quickly as possible.
How to update your server so it is no longer vulnerable
There are two three (see update below) options for updating your server. You can either update to OpenSSL version 1.0.1g, or you can recompile your existing version of OpenSSL with -DOPENSSL_NO_HEARTBEATS. Neither option is inherently better than the other; different dependencies and situations call for different solutions. But you should take one of these actions immediately.
[UPDATE:] There is a third option for updating your server: your Linux distribution may have patched the bug itself, rather than updating to version 1.0.1g of OpenSSL. If that is the case, updating to the latest version of your distribution will fix the problem, even if your OpenSSL version does not change. Please note that DigiCert’s Certificate Inspector will properly assess your security if you take this approach, because it actually tests for the vulnerability rather than just looking at version numbers. (Thank you to Xan Charbonnet for pointing out this option in the comments.)
How to re-key an SSL Certificate
The first step, whether you are a DigiCert customer or not, is to create a new key pair and Certificate Signing Request. DigiCert has a very useful free tool to quickly create CSR creation commands. The last thing you want to do when quickly trying to address Heartbleed is fumble with complicated shell commands. The DigiCert Easy CSR for Apache and Exchange CSR Command Generator make it easy to re-key or create a new a new SSL Certificate. These tools are available to anyone, whether using DigiCert or another SSL Certificate provider.
If you are a DigiCert customer, re-keying is always free, easy, and nearly instantaneous. Here are the steps:
- Simply go to https://www.digicert.com/custsupport/ and login to your account.
- Under the My Orders tab, click the + next to the order number of the certificate you need to re-key, and click on the “Re-Key Your Certificate” link that appears.
- Enter the requested information, including your new CSR, and follow the quick process.
- Your new certificate will be ready for you within minutes.
You will need to re-key every certificate that has been on a vulnerable server.
Keeping Your systems safe from Heartbleed
Now that Heartbleed has been made public, if you use one of the affected versions of OpenSSL, it is important that you address the issue.
The DigiCert team is always available 24/7 to provide any assistance you may need in re-keying your DigiCert certificates or answer any questions about Heartbleed. As a DigiCert policy, any SSL user, whether a DigiCert customer or not, can call, email, or live chat with us by visiting our Contact page at http://www.digicert.com/contact-digicert-inc.htm.
Thanks for the information. I also got several email from providers and clients today and i have taken action too. Thanks for the information anyway
Thanks for this well written post. Too many (certificate) companies emphasize wrong points: “our certificates themselves have no vulnerabilities” etc… This post actually tells you the basics: Do I have a problem or not – and what to do, if I do have a problem.
You are on to something here Halsvaha. Service is more than just self-serving. SSL is not just a product, it’s also a service. It’s key that continued customer service goes beyond the sale. If you’re interested in the Heartbleed scanner, you should check out the cloud-service Certificate Inspector. It’s a free service to scan all certificates you own and monitor ongoing security on certificates and the servers where they’re installed. Certificate Inspector is the next step in SSL as a service.
Big heads up for user complaints… Lastpass just released a tool for scanning sites https://lastpass.com/heartbleed/ .
However it appears to use the publicly visible Issued on date for the certificate to claim if a site has updated. If you re-key your current certificate with a new private key it is a new cert, and the version number increments however the issued on is the SAME. Thus even newly keyed certs will fail the lastpass tool. There tool might be wrong but it does raise an issue from a user visibility perspective. Why doesn’t the issued on date change when we re-key?
In several places in this blog entry, the option of installing a fixed version from your distribution is ignored. It makes it sound like if you’re running 1.0.1f then you’re vulnerable, but this is only true if the version you’re running hasn’t been fixed.
Probably most people will be able to fix it with a simple “apt-get update” (or equivalent). This post will make them think that wasn’t sufficient, and send them on a wild goose change downloading code and shoehorning something onto their systems.
Also, Busy IT Guy is right; it’s a little disheartening to be listed as Unsafe after having done all the right things, just because the issue date didn’t get updated.
Thoughts:
1. If a hacker extracts the private keys for a security certificate provider, they could decrypt encrypted traffic between the security certificate provider and the customer.
2. Said hacker could obtain the login and password for that customer.
3. Hacker could login to security certificate provider and obtain the certificates of that company and build a website with the certificates of that customer.
That tells me that first step BEFORE you re-key your certificates is to change your password on your security certificate providers website.
Let the resetting begin!
How did the re-key process go? It should have taken just a few minutes with the free reissue process.
The “Re-Key Your Certificate” action still keeps the issue date of the certificate. It looks like our certificate has not been regenerated and the domain is still vulnerable to heartbleed. Is there a good reason why DigiCert recycles the issue date?
Thanks for your questions, Busy IT Guy, Xan, and Andreas.
There are a few reasons why we use the same issue date on a re-key. Over the years, we have actually run into several instances where it is important that a cert maintains its original dates, either to the customers themselves or to certain applications they are working with. In our 10+ years in business, this is the first time we have run into a situation where any customers wanted the issue date to change. Changing the issue date will help some faulty tools return “better” results, but the results won’t actually be more meaningful (see our blog post about that here).
Knowing that keeping the dates the same has been important to many customers over the years, and knowing that changing the dates won’t actually improve the current situation, we are being careful to weigh all our options before we jump headfirst into a change that could negatively affect a lot of customers.