SSL Labs Test for the Heartbleed Attack
Last updated on: September 6, 2020
Heartbleed is a name for a critical vulnerability in OpenSSL, a very widely deployed SSL/TLS stack. A coding error had been made in the OpenSSL 1.0.1 code, which was subsequently released in March 2012. The vulnerability is in the rarely used heartbeat mechanism, specified in RFC 6520. The error allows an attacker to trick the server into disclosing a substantial chunk of memory, repeatedly. As you can imagine, process memory is likely to contain sensitive information, for example server private keys for encryption. If those are compromised, the security of the server goes down the drain, too.
Your server is probably vulnerable if it’s running any version in the OpenSSL 1.0.1 branch. If you’d like to verify if you’re vulnerable, today I released a new version of the SSL Labs Server Test. I went through a lot of effort to implement a test that doesn’t attempt exploitation (no server data is retrieved). So it should be safe to use. Despite the availability of the test, if you can identify the library version number, I would urge to assume that you are vulnerable, even if the test is not showing a problem.
It’s difficult to underestimate the impact of this problem. Although we can’t conclusively say what exactly can leak in an attack, it’s reasonable to assume that your private keys have been compromised. Addressing this issue requires at least three steps: 1) patch, 2) replace the key and certificate, and 3) revoke the old certificate. After that you will need to consider if any additional data might have been leaked too, and take steps to mitigate the leak.
Unless your server used Forward Secrecy (only about 7% do), it is also possible that any past traffic could be compromised, but only if you are faced with a powerful adversary who has means to record and store encrypted traffic. If you did not before Forward Secrecy before, now is a great time to ensure you do support it from now on. If this topic is new for you, you can follow my advice here and here.
For more details on the nature of this OpenSSL blog, have a look at this post from Matthew Green.
18k+ views… 'bout time someone said "Thanks!"
You Rock Ivan! Thanks for the quick response and all the help! Your work is greatly appreciated by many…
@Ivan, I have already suggested few months ago that servers without Perfect Forward Secrecy (PFS) should be graded down to B. This is now a good proof that PFS cat at least protects against past recorded sessions. I still believe that non-PFS servers should get graded down to B. This is my suggestion that system administrators gets more serious about PFS.
P.S. Yes, Ivan you Rock!
One scary point: revocation is almost broken. There are many situations where it is not enforced (think about browser getting access through a wifi hotspot: before authentication is done, CRL/OCSP cannot be checked, 802.1x with EAP-TTLS also comes to my mind)
This means that even after certificate has been renewed, someone that stole it may still be able to impersonate the legitimate machine. The only workaround I see is changing DNS name.
Thanks, Ivan. I wonder if you could add a test to determine if the server is running OpenSSL 1.0.1, whether patched or not. The reason is that a lot of websites seem to pass the test but haven’t revoked their old certificates. If they’re running OpenSSL 1.0.1, they’re still presumptively insecure (any bad guy who figured this out before it was published had up to two years to grab their certificate) until they do. I ran your test on the sites of all of my financial institutions yesterday and they all passed, but none of them had revoked their certificates. So I’m left uncertain. Even if the bug wasn’t being exploited before it was published, it’s a pretty good bet some people in Russia, Ukraine and Moldova exploited it against a short list of major financial institution sites between publication and patch. Since the exploit leaves no trace, they wouldn’t know that had happened.
@ethstone, or probably even better: do additional check. All servers within OpenSSL 1.0.1 branch should have a issued certificate date after 2014-04-10 – if not, certificates could be compromised and so grade F in this case.
But it can lead to some false positive – most probably very tiny possibilites. For example someone having a domain http://www.mydomain.com and having web server that is using OpenSSL 1.0.0 branch that is not vulnerable. System administrator sets up a web server with OpenSSL 1.0.1g and copies the certificates from old server. In this case certificates are not compromised and so no need to be revoked.
Just wondering isn’t Hearbleed functionality an TLS 1.2 extension? If yes, would it help like a work-around to just disable TLS 1.2 protocol on HTTP server? You know all of the web servers can’t just be upgraded without testing. So disabling TLS 1.2 (and enable TLS 1.0 and TLS 1.1) would temporally solve this problem and so give system administrators few days for proper testing. Would disabling TLS 1.2 temporally solve the problem? Or another question which protocol versions are
vulnerable: SSLv3.0, TLS 1.0, TLS 1.1, TLS 1.2? All of them or just TLS 1.2?
FYI – If your IPS, firewall, or WAF are configured to block this attack but you’d still like to test your sites with SSL Labs, you’ll need to allow the following Rackspace public IPs through:
173.203.81.36
173.203.82.67
173.203.82.154
173.203.82.166
173.203.82.175
All of these IPs are in a 173.203.64.0/19 registered to Rackspace Cloud Servers.
Best,
Jason
@manu@qualys, ahhh sorry, I have written the wrong date. 2014-04-10 was yesterday when I wrote a post, so mistype the date. But what I really meant is that there should be a check in ssltest of issued certificates BEFORE 2014-04-07 – official date of release of OpenSSL library 1.0.1g – so if using 1.0.1 branch there is NO WAY someone can be sure that certificates are not already compromised.
I have been talking to system administrator and his suggestion was just to upgrade the server to use 1.0.1g and not revoking old certificates. I totally disagree with him, but he said ssltest will show the green A+ grade or our servers, so why should we bother of revoking a certificates… This is totally wrong mentality and if grade would be at least downgraded to grade B (I think it should be grade F) if old issued certificate date with 1.0.1g branch, then system administrators would take this way more serious. Or… at very least make it red or orange issued certificate date in certification section if older then 2014-04-07.
First of all, thank you for this great work.
Would it be possible to share more information about how the test actually works? There are a number of tests available on the Internet by now, and some have been already criticized for being non-ethical (i.e. to test, they retrieve data from the server’s memory without permission).
You said the test works "without retrieving any bytes from the server, other than the bytes we send in the heartbeat request". For the sake of transparency, would it be possible to elaborate further?
Ivan, regarding your comment –
Forward Secrecy (only about 7% do) –
I read the percentage as 48.3%, not 7%, for Forward Secrecy at the link you gave. That would
be the remainder of the "51.7%" who don’t offer it in any form, if I’m reading
the graphic correctly.
No. 42% support some Forward Security suites, but they are not using them well, and end up using non-FS suites with reference browsers.
Just to follow up, Lastpass has a tool that does what I suggested above. In other words, it will test to see if the bug has been patched, tell you what’s publicly available about the server software (often nothing, unfortunately), test whether the site has replaced its old certificate and give you advice based on all three datapoints. It is unfortunately the case that too many sites are hiding their server software, haven’t replaced their certificates and aren’t saying anything publicly (or anything useful, anyway) about whether they were vulnerable in the first place. But the Lastpass tool seems to be as good as we’re going to get.
It’s good to know that my server is not hearthbleed vulnerable .
As the SSLLabs server test shows almost all of my ciphers are FS enabled. It’s bad that YandexBot3.0 cannot visit my site but .. i wont open SSLv3 protocol just because of it.