It’s worth emphasising 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 organisations’ 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 licence.