Why the Web Needs Perfect Forward Secrecy More Than Ever

 

 

APRIL 8, 2014 | BY YAN ZHU

Why the Web Needs Perfect Forward Secrecy More Than Ever

EFF has long advocated for websites to support HTTPS instead of plain HTTP to encrypt and authenticate data transmitted on the Internet. However, 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. 1

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 could actually protect some users from the worst-case scenario: 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 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. 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.2 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.

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.3

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.