The Simple Secruity Measure That Could've Stopped Heartbleed Dead

We learned yesterday of a catastrophic bug, nicknamed "Heartbleed," that has critically threatened the security of some HTTPS sites since 2011. By some estimates, Heartbleed affects 2 out of 3 web servers on the Internet.

Heartbleed isn't a bug in the design of HTTPS itself but rather the result of a simple programming error in a widely-used piece of software called OpenSSL. It allows an attacker who connects to an HTTPS server running a vulnerable version of OpenSSL to access up to 64KB of private memory space. Doing the attack once can easily cause the server to leak cookies, emails, and passwords. Doing the attack repeatedly in a clever way can potentially leak entire encryption keys, such as the private SSL keys used to protect HTTPS traffic. If an attacker has access to a website's private SSL key, they can run a fake version of the website and/or steal any information that users send, including passwords, private messages, and credit card numbers. Neither users nor website owners can detect this attack as it happens.

It's worth emphasizing that some important services that users access everyday were affected by Heartbleed, including Yahoo Mail and LastPass. We weren't immune either, since most EFF servers were running vulnerable versions of OpenSSL. Even the private identity keys used by Tor Hidden Services may have been compromised, potentially putting some journalist organizations' communication with anonymous sources at risk.

Luckily, there's one important mitigation that actually protected some users from this security nightmare: perfect forward secrecy. If a server was configured to support forward secrecy, then a compromise of its private key can't be used to decrypt past communications. In other words, if someone leaks or steals a copy of EFF's private SSL key today, any traffic sent to EFF's website in the past since EFF started supporting forward secrecy is still safe.

Unfortunately, most HTTPS websites on the Internet still don't support forward secrecy, which means that a large chunk of your past communications with those servers is vulnerable to decryption when private SSL keys are compromised. For example, if someone has been intercepting your HTTPS-encrypted messages to Yahoo for the past several years and then stole a copy of Yahoo's private key yesterday with Heartbleed, they would be able to use it to go back and decrypt the previously-unintelligible recording of your old communications today — if those communications weren't made using a forward-secrecy-enabled connection.

At this moment, forward secrecy is more crucial than ever before. 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 to affected servers that don't use forward secrecy remains open to eavesdropping and malicious tampering.

In the aftermath of yesterday's events, it's clear that forward secrecy is necessary to protect against unforseeable threats to SSL private keys. Whether that threat is an existing or future software bug, an insider who steals the key, a secret government demand to enable surveillance, or a new cryptographic breakthrough, the beauty of forward secrecy is that the privacy of today's sessions doesn't depend on keeping information secret tomorrow.

Although we've patched this bug on EFF's servers and are scrambling to rotate our keys as fast as possible, we're relieved that our potential damage from Heartbleed is lower because we enabled forward secrecy last summer. It's clearly time for other websites to do so as well.

PS: Fortunately, the integrity of HTTPS Everywhere downloads for Firefox and Chrome are not compromised by Heartbleed. That's because, in addition to serving downloads over SSL/TLS, we sign HTTPS Everywhere updates with an offline key to guarantee authenticity even if transport-level security is broken. You can use these instructions to check that your copy of HTTPS Everywhere has the correct update key. In light of Heartbleed, we're glad that the Chrome web store allows extension developers to include their own code signing keys in case Google's SSL certificates are compromised; until the Mozilla Addons Store does similarly, we plan to keep hosting HTTPS Everywhere for Firefox on our own servers.

1.Given the severity of this bug we urge site operators using versions 1.0.1-1.0.1f of OpenSSL to immediately upgrade to OpenSSL 1.0.1g or recompile OpenSSL with the -DOPENSSL_NO_HEARTBEATS flag; furthermore, any affected server should get a new SSL certificate and rotate any keys that could have been leaked from memory after updating. Please also remember to restart your load balancers after updating.

2.Qualys SSL Labs has an excellent online tool to check whether a website is currently vulnerable to Heartbleed attacks. The "Protocol Details" section of the results also shows support for forward secrecy.

3.This is assuming that an attacker is not performing active man-in-the-middle attacks during every SSL handshake. However, this threat will likely be mitigated in the future by efforts such as Certificate Transparency.


This post first appeared on Electronic Frontier Foundation and is republished here under Creative Commons license.