Millions of websites and billions of people rely on SSL to protect the transmission of sensitive information such as passwords, credit card details, and personal information with the expectation that encryption guarantees privacy. However, recently leaked documents appear to reveal that the NSA, the United States National Security Agency, logs very high volumes of internet traffic and retains captured encrypted communication for later cryptanalysis. The United States is far from the only government wishing to monitor encrypted internet traffic: Saudi Arabia has asked for help decrypting SSL traffic, China has been accused of performing a MITM attack against SSL-only GitHub, and Iran has been reported to be engaged in deep packet inspection and more, to name but a few.
The reason that governments might consider going to great lengths to log and store high volumes of encrypted traffic is that if the SSL private key to the encrypted traffic later becomes available — perhaps through court order, social engineering, successful attack against the website, or through cryptanalysis — all of the affected site’s historical traffic may then be decrypted at once. This really would open Pandora’s Box, as on a busy site a single key would decrypt all of the past encrypted traffic for millions of people.
There is a defence against this, known as perfect forward secrecy (PFS). When PFS is used, the compromise of an SSL site's private key does not necessarily reveal the secrets of past private communication; connections to SSL sites which use PFS have a per-session key which is not revealed if the long-term private key is compromised.
The security of PFS depends on both parties discarding the shared secret after the transaction is complete (or after a reasonable period to allow for session resumption).
Eavesdroppers wishing to decrypt past communication which has used PFS face a daunting task: each previous session needs to be attacked independently. Even knowing the long-term private key does not help as the session key is not available by simple decryption. Conversely, when SSL connections do not use PFS, the secret key used to encrypt the rest of the session is generated by the SSL site and sent encrypted with the long-term private-public key pair. If this long-term private key is ever compromised all previous encrypted sessions are easily decrypted.
Perfect forward secrecy was invented in 1992, pre-dating the SSL protocol by two years, and consequently one might reasonably have expected that SSL would have made operational use of PFS from the outset. Nevertheless, almost twenty years later, PFS usage is not used by the majority of SSL sites.
The use of PFS is dependent on the negotiation between the browser and the web site successfully agreeing on a PFS cipher suite. One might reasonably expect browsers to do all they can to support PFS cipher suites as PFS confers an advantage in privacy for the browser’s user community, and any PFS performance disadvantages may only be a serious issue at the larger scales found on the server-side. On the other hand, there are only a small number of browsers in widespread use, and if a government wished to maximise its influence in restricting the use of PFS in order to facilitate decryption of recorded encrypted transactions it would start with the web browsers.
Browser support for PFS
Netcraft has tested the cipher suite selection of five major browsers — Internet Explorer, Google Chrome, Firefox, Safari and Opera — against 2.4 Million SSL sites from Netcraft's June SSL Survey. The support for PFS varied significantly between browsers: only a tiny fraction of Internet Explorer's SSL connections operated with PFS; whereas Google Chrome, Opera and Firefox were protected for approximately one third of connections. Safari fared only a little better than Internet Explorer.
The actual cipher suites used when connecting to 2.4 Million SSL sites with the cipher suite settings extracted from each browser. *Opera does not include its TLS 1.2 cipher suites.
Internet Explorer does particularly poorly as it does not support any cipher suite that uses both RSA public keys and non-elliptic-curve DH key exchange, which includes the most popular PFS cipher suite. The PFS cipher suites that IE does support have a lower priority than some of the most commonly supported non-PFS cipher suites. Curiously, IE does support DHE-DSS-AES256-SHA, which uses the rarer DSS authentication method, but not the very popular DHE-RSA-AES256-SHA.
Browser priority
Cipher Suite
Real-world usage in SSL Survey
1
AES128-SHA
63.52%
2
AES256-SHA
2.21%
3
RC4-SHA
17.12%
4
DES-CBC3-SHA
0.41%
5
ECDHE-RSA-AES128-SHA
0.08%
6
ECDHE-RSA-AES256-SHA
0.21%
7
ECDHE-ECDSA-AES128-SHA
0.00%
8
ECDHE-ECDSA-AES256-SHA
0.00%
9
DHE-DSS-AES128-SHA
0.00%
10
DHE-DSS-AES256-SHA
0.00%
11
EDH-DSS-DES-CBC3-SHA
0.00%
12
RC4-MD5
16.46%
Internet Explorer 10's cipher suite ordering and the actual negotiated cipher suite in Netcraft's SSL survey. PFS cipher suites are highlighted in bold and green.
Safari supports many PFS cipher suites but non-elliptic-curve cipher suites are used only as a last resort. As several non-PFS ciphers have a higher priority, web servers respecting the browser's preferences will end up selecting a non-PFS cipher suite even if the web server itself does support some (non elliptic-curve) PFS cipher suites.
Chrome, Firefox, and Opera all do better, preferring PFS cipher suites ahead of non-PFS at any given strength level — for example Opera's preference list starts: DHE-RSA-AES256-SHA, DHE-DSS-AES256-SHA, AES256-SHA, DHE-RSA-AES128-SHA, DHE-DSS-AES128-SHA, AES128-SHA. Netcraft did not include any cipher suites only present in TLS 1.2 which includes many of Opera's PFS cipher suites, so the results for Opera form a lower bound on the number of SSL sites using PFS with Opera.
None of the browsers change their user interface perceptibly to reflect the presence of PFS akin to the way EV certificates are treated to a green address bar. Google Chrome and Opera show the cipher suite used (in popups or dialog boxes), but they rely on a user understanding the implications of wording such as "[..] ECDHE_RSA as the key exchange mechanism".
Web server support for PFS
Despite a browser's best efforts to prefer PFS cipher suites, the key exchange method used is selected by the server and it may either not support any PFS cipher suites or it may prefer to use an alternative cipher suite (and perhaps reasonably so for performance reasons). The use of the Diffie-Hellman key exchange does impose a performance penalty as there is additional computation required to derive the secret key.
Using any browser's cipher suite preference order, at least two-thirds of the SSL connections made in the Netcraft SSL survey did not use a cipher suite with PFS at all.
Connections to 2.4 Million SSL sites in the SSL survey, once for each browser, split by the web server vendor
nginx, an open-source web server originally written by Russian Igor Sysoev, uses strong cipher suites by default, which has caused some to comment on nginx's SSL performance. With the exception of Internet Explorer and Safari, more than 70% of SSL sites using the web server selected a PFS cipher suite when visited with a modern browser.
The usage of PFS amongst SSL sites using Apache is also fair, around two-thirds of the SSL sites it serves use a PFS cipher suite when visited in Firefox, Chrome, or Opera.
Conversely, Microsoft's support for PFS cipher suites is notably lacking; both Microsoft IIS and Internet Explorer only rarely use PFS cipher suites — when used together only 111 (0.01%) of SSL connections between IIS and IE used PFS.
Whilst Google uses PFS cipher suites for some Google SSL sites, it appears that many SSL sites hosted on Google App Engine do not.
How is this related to PRISM?
Website
Internet Explorer
Google Chrome
Firefox
Safari
Opera
www.facebook.com
RC4-SHA
RC4-SHA
RC4-SHA
RC4-SHA
RC4-SHA
www.twitter.com
RC4-SHA
RC4-SHA
RC4-SHA
RC4-SHA
RC4-SHA
www.yahoo.com
AES128-SHA
CAMELLIA256-SHA
CAMELLIA256-SHA
AES128-SHA
AES256-SHA
www.google.com
ECDHE-RSA-AES128-SHA
ECDHE-RSA-RC4-SHA
ECDHE-RSA-RC4-SHA
ECDHE-RSA-RC4-SHA
RC4-SHA
login.live.com
AES128-SHA
AES128-SHA
AES128-SHA
AES128-SHA
AES128-SHA
www.aol.com
RC4-SHA
RC4-SHA
RC4-SHA
RC4-SHA
RC4-SHA
www.apple.com
AES256-SHA
AES256-SHA
AES256-SHA
AES256-SHA
AES256-SHA
commerce.paltalk.com
RC4-SHA
RC4-SHA
RC4-SHA
RC4-SHA
RC4-SHA
The negotiated cipher suite for a selection of SSL sites belonging to companies implicated in the PRISM programme. PFS cipher suites are highlighted in bold and green.
Many SSL sites of those companies implicated in the PRISM programme do not use PFS cipher suites when visited in any of the major browsers. Google, however, does use a PFS cipher suite in most browsers, with the notable exception of Opera. If PRISM operates by examining SSL traffic, which has been said to be fairly unlikely given its quoted $20M cost, all of the traffic to these SSL sites (except for Google) could have been compromised if the NSA had access to the private key.
Some other noteworthy SSL sites
Website
Internet Explorer
Google Chrome
Firefox
Safari
Opera
www.cloudflare.com
ECDHE-RSA-AES128-SHA
ECDHE-RSA-RC4-SHA
ECDHE-RSA-RC4-SHA
ECDHE-RSA-RC4-SHA
RC4-SHA
www.duckduckgo.com
RC4-SHA
RC4-SHA
RC4-SHA
RC4-SHA
RC4-SHA
www.mega.co.nz
RC4-SHA
RC4-SHA
RC4-SHA
RC4-SHA
RC4-SHA
The negotiated cipher suite for a selection of SSL sites. PFS cipher suites are highlighted in bold and green.
DuckDuckGo, a search engine, has been prominent in the media since the start of the Snowden revelations due to its privacy policy which promotes anonymity. If the private key used by DuckDuckGo were ever compromised — for example if one of their servers were seized — all previous searches would be revealed where logged traffic is available. DuckDuckGo may be a particularly interesting target for the NSA due to its audience and the small volume of traffic (as compared to Google).
CloudFlare has taken a similar approach to Google using ECDHE RC4 or AES cipher suites, but also leave Opera users without the protection of PFS. One of CloudFlare's options for SSL deployment is 'flexible' SSL which encrypts traffic from the browser to CloudFlare but if the content is not returned from its cache, the connection from CloudFlare to the original website is made without SSL. Rather than attempting to decrypt the encrypted content it may be easier to intercept unencrypted traffic between CloudFlare and the original website.
Mega does not use PFS cipher suites, perhaps a risky move given the history of raids on Megaupload's servers by the US Government. With physical access to the servers, it is not implausible that the private keys of any server could be extracted, even if it is from non-persistent memory.
Conclusions
Conspiracy theorists may be unsurprised that:
Microsoft’s support for PFS is conspicuous by its absence across Internet Explorer, IIS, and some of its own web sites. Apple’s support for PFS in Safari is only slightly better.
Russia, long-time target of US spies, is the home of the developer of nginx, the web server which uses PFS most often.
Almost all of the websites run by companies involved in the PRISM programme do not use PFS.
Whilst conspiracy theorists may delight in speculating on the reasons why PFS isn't ubiquitous, one reason may be web sites' (bona fide) performance concerns: Mavrogiannopoulos reports up to a 3x performance penalty starting an SSL connection using DHE-RSA instead of plain RSA. The lack of clear in-browser notifications of the use of PFS cipher suites may persuade popular SSL sites to forgo the protection PFS offers, which typical users do not notice, to instead improve the web site's performance, which typical users do notice.
Without the support of two major browsers and major websites most internet users are missing out on the security benefits of perfect forward secrecy. Without the protection of PFS, if an organisation were ever compelled — legally or otherwise — to turn over RSA private keys, all past communication over SSL is at risk. Perfect forward secrecy is no panacea, however; whilst it makes wholesale decryption of past SSL connections difficult, it does not protect against targeted attack on individual sessions. Whether or not PFS is used, SSL remains an important tool for web sites to use to secure data transmission across the internet to protect against (perhaps all but the most well-equipped) eavesdroppers.
It should be noted that the US Government, along with many others governments, can issue any SSL certificate of its choosing — albeit at the risk of breaking the rules of the programme and at the risk of detection by alert users and by Google (for certain SSL sites). The scale at which an active attack is practical and unlikely to be detected, however, would be significantly smaller than that of a passive eavesdropper exploiting the lack of PFS.
More detail on PFS negotiation
The cipher suite selected for the SSL connection depends on an agreement between the browser and the SSL site. Both browsers and SSL sites can each have independent preference lists for SSL cipher suites. During the handshake the browser sends a ClientHello message which contains an ordered list of all supported cipher suites in preference order. The SSL site can either select the first cipher on that list which it also supports or it can use override the clients preference list with its own. As illustrated in the above diagram, either Cipher A (if the browser's preference order is respected) or Cipher C (if the website's preference order is respected) is used for the connection depending on the settings of the SSL site.
Illustration of cipher suite selection algorithms.
Diffie-Hellman key exchange (DH) and variants of it are used to negotiate a per-session shared secret key between two parties without ever transmitting the key itself. The per-session key can be discarded after the session has terminated (and after a suitable time period for renegotiation) leading to the ephemeral property which PFS relies upon. The security of Diffie-Hellman relies on the difficulty of the discrete logarithm problem to exchange DH public keys whilst making it difficult for an eavesdropper to determine the resulting shared secret. SSL cipher suites support both conventional ephemeral Diffie-Hellman key exchange (often referred to as EDH or DHE) and ephemeral elliptic curve Diffie-Hellman (ECDHE) which uses a similar scheme but relies on the difficulty of the elliptic curve Discrete Logarithm problem. Elliptic curve-based DHE key exchange despite being faster is supported by fewer SSL sites than conventional DHE.