This article, written by activist Peter Higgins, originally appeared on the Electronic Frontier Foundation website on August 28.
When you access a Web site over an encrypted connection, you’re using a protocol called HTTPS. But not all HTTPS connections are created equal. In the first few milliseconds after a browser connects securely to a server, an important choice is made: the browser sends a list of preferences for what kind of encryption it’s willing to support, and the server replies with a verification certificate and picks a choice for encryption from the browser’s list. These different encryption choices are called “cipher suites.” Most of the time, users don’t have to worry about which suite the browsers and servers are using, but in some cases it can make a big difference.
One important property is called “perfect forward secrecy,” but only some servers and only some browsers are configured to support it. Sites that use perfect forward secrecy can provide better security to users in cases where the encrypted data is being monitored and recorded by a third party. That particular threat may have once seemed unlikely, but we now know that the NSA does exactly this kind of long-term storage of at least some encrypted communications as they flow through telecommunications hubs, in a collection effort it calls “upstream.”
How can perfect forward secrecy help protect user privacy against that kind of threat? In order to understand that, it’s helpful to have a basic idea of how HTTPS works in general. Every Web server that uses HTTPS has its own secret key that it uses to encrypt data that it sends to users. Specifically, it uses that secret key to generate a new “session key” that only the server and the browser know. Without that secret key, the traffic traveling back and forth between the user and the server is incomprehensible, to the NSA and to any other eavesdroppers.
But imagine that some of that incomprehensible data is being recorded anyway—as leaked NSA documents confirm the agency is doing. An eavesdropper who gets the secret key at any time in the future—even years later—can use it to decrypt all of the stored data! That means that the encrypted data, once stored, is only as secure as the secret key, which may be vulnerable to compromised server security or disclosure by the service provider.
That’s where perfect forward secrecy comes in. When an encrypted connection uses perfect forward secrecy, that means that the session keys the server generates are truly ephemeral, and even somebody with access to the secret key can’t later derive the relevant session key that would allow her to decrypt any particular HTTPS session. So intercepted encrypted data is protected from prying eyes long into the future, even if the website’s secret key is later compromised.
It’s important to note that no flavor of HTTPS, on its own, will protect the data once it’s on the server. Web services should definitely take precautions to protect that data, too. Services should give user data the strongest legal protection possible, and minimize what they collect and store in the first place. But against the known threat of “upstream” data collection, supporting perfect forward secrecy is an essential step.
So who protects long-term privacy by supporting perfect forward secrecy? Unfortunately, it’s not a very long list—but it’s growing. Google made headlines when it became the first major web player to enable the feature in November of 2011. Facebook announced last month that, as part of security efforts that included turning on HTTPS by default for all users, it would enable perfect forward secrecy soon. And while it doesn’t serve the same volume as those other sites, www.eff.org is also configured to use perfect forward secrecy. Outside of the web, emails encrypted using the OpenPGP standard do not have forward secrecy, but instant messages (or text messages) encrypted using the OTR protocol do.
Supporting the right cipher suites—and today, for the Web, that means ones that support perfect forward secrecy—is an important component of doing security correctly. But sites may need encouragement from users because, like HTTPS generally, supporting perfect forward secrecy doesn’t come completely without a cost. In particular, it requires more computational resources to calculate the truly ephemeral session keys required.
It may not be as obvious a step as simply enabling HTTPS, but turning on perfect forward secrecy is an important improvement that protects users. More sites should enable it, and more users should demand it of the sites they trust with their private data.