Perfect Forward Secrecy

July 17, 2013 by Bruce Morton     7 Comments

The topic of perfect forward secrecy has come up due to the alleged actions of NSA and PRISM. It has been reported the NSA has been able to trap website communications and then are able to search and review those communications at a future time.

perfect forward secretUsers that use SSL were assuming their communications were secure. The traffic was encrypted with SSL session keys that were protected by the Web server’s private key.

Unfortunately, this isn’t necessarily the case. What if that one private key gets compromised? What if the right employee is bribed or subverted? What if a government demands that the server owner provide their private key as it is a matter of national security? If the session key is exposed, then all of the SSL traffic can be decrypted — unless you were using perfect forward secrecy.

So, what is perfect forward secrecy? The solution was originally introduced in 1992 by researchers associated to Entrust — Whitfield Diffie, Paul van Oorschot and Michael Wiener. The vulnerability of the single private key vanishes through perfect forward secrecy’s use of temporary individual keys. Separate keys are developed for each session, which a passive onlooker cannot determine. A man-in-the-middle attack could be successful, but it is far more difficult to perform and could be detected by modern browsers.

Of course there is a problem — perfect forward secrecy is not well deployed. In order to deploy, it needs support by both the server and the browser. On the server side, a cipher suite that supports Diffie-Hellman key exchange must be used, that is the standard Diffie-Hellman (DHE) and the adapted version for use with Elliptic Curve cryptography (ECDHE).

More problems. Perfect forward secrecy has not been well deployed as DHE is significantly slower than other standard algorithms, and ECDHE is slow as well. There is a solution.

In 2011, Google implemented perfect forward secrecy for their websites. They did this by implementing changes in OpenSSL to make fast, constant-time implementations of ECDHE to support elliptic curves P-224, P-256 and P-521.

If you are going to support perfect forward secrecy, Ivan Ristić recommends adding the following cipher suites close to the top in your server:

  • TLS_ECDHE_RSA_WITH_RC4_128_SHA
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
  • TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA

I suppose the suite with RC4 was placed at the top to mitigate the BEAST attack as well.

You can test your server or other server for perfect forward secrecy with CASC SSL Configuration Checker.

Updated December 5, 2013: Adam Langley uses high school math to explain Forward Security For Journalists.

About

Bruce Morton has worked in the public key infrastructure and digital certificate industry for more than 15 years and has focused on SSL and other publicly trusted certificates since 2005. He has been an active member of the CA/Browser Forum that released guidelines for extended validation (EV) certificates and Baseline Requirements for SSL certificates. Bruce oversees the governance and compliance of Entrust’s publicly trusted PKI.