Perfect Forward Secrecy

Perfect Forward Secrecy. The term sounds like something out of the latest Bond film. When I first checked how to configure PFS ciphers several years ago, I couldn’t find much documentation because I didn’t realize that that PFS described a class of ciphers, which included Diffie Hellman Ephemeral (DHE) and Elliptic Curve DHE (ECDHE). Further complicating matters was that some implementations made reference to ECDH, EDH, and DHE.

But I’m getting ahead of myself. First, let’s dissect the term itself and then what these ciphers are intended to achieve.  Ivan Ristic of Qualys SSL Labs balks at the notion of calling it perfect, and refers to it only as Forward Secrecy. Indeed, some implementations of Forward Secrecy have already been found to be profoundly imperfect, as in the research done on DHE by the team at WeakDH.org, famous for the LogJam attack published in 2015. The use of weak or common primes for the generation of ephemeral keys, along with an ephemeral key length of less than 2048 bits has been classified as potentially vulnerable to this LogJam attack. As with any cryptographic method, the implementation is vital to the effective security. So, PFS certainly isn’t “perfect”.

The Forward Secrecy part of the term refers to the use of those ephemeral keys. In a classic key exchange, without an FS cipher, a single private key is used to encrypt all connections. This private key is the one associated with the SSL certificate. In that non-FS scenario, anyone could record encrypted communications, and at some future date, get a copy of that private key and decrypt all of that recorded data. For that reason, it may be helpful to think of it as Future Secrecy, as the ephemeral key exchange is designed to defeat the exploit of a private key compromised at a future date.

The ephemeral key exchange is a per-session key generated using a random prime number. This key is ephemeral because it isn’t stored anywhere, and therefore isn’t subject to the same risk of compromise described above. However, as with the LogJam attack, the use of weak or common primes could severely undermine the security of an implementation of DHE or ECDHE. More dangerous than the use of weak or common primes is the reuse of the “per session” ephemeral keys. Because the generation of the ephemeral key is computationally expensive, many TLS stacks implement ECDHE and DHE with an ephemeral key reuse setting. While some reuse in the name of performance is defensible, make sure that any systems in use minimize key reuse and auto-rotate the primes used for key generation. Ivan Ristic has an excellent write up on deploying forward secrecy that everyone interested in practical cryptography should read.

Why is all this Forward Secrecy stuff important?

If you follow this column, you’ll know that I’ve predicted (twice) that the adoption of HTTP/2 and TLS 1.3 will have a profound impact on Internet traffic. The most obvious effects of these latest protocol versions are the built-in performance enhancements. However, both protocols use only Forward Secrecy ciphers. SSL Labs has been pushing the use of Forward Secrecy to achieve their highest A+ grade for some time now. In 2017, Forward Secrecy will be required or your SSL Labs grade will be capped to a B.

Forward Secrecy ciphers such as DHE and ECDHE can only be decrypted by authorized full-proxy devices (or men-in-the-middle). Many security solutions such as IPS and WAF rely on the weakness of a static key exchange described above to passively decrypt traffic, and are effectively blinded by Forward Secrecy cipher usage. Beware when enforcing the use of Forward Secrecy that visibility into that traffic from various security sensors is properly preserved, as covered in this column in the past.