What is FS?

Forward Secrecy (also known as Perfect Forward Secrecy) is an attribute of the specific key exchange mechanisms in SSL/TLS security protocols that implies the independence of the session key generated during the secure session establishment from the set of long-term Public and Private keys and the session keys used in previous sessions.

The mission of the key exchange is to ensure that two parties will agree on a session key upon the security settings available for both participants of the secure negotiation and that no one else will know it.

For a better understanding, let’s review the non-FS key agreement based on the example of the RSA key exchange mechanism firstly. RSA key exchange is supported by nearly any application using SSL/TLS protocol.

Here is how it works: the server sends its certificate, the client picks a random session key, encrypts it with the server’s Public key obtained from the certificate and sends it back to the server. The session key can only be decrypted with the server’s Private key that corresponds to the Public key, thus creating the secure session.

In such a way the server establishes hundreds of thousands sessions using the same key pair, creating a link between the long-term keys and the session key for each unique session.

As we see, the secrecy of the session key solely relies on the server’s Private key secrecy which leads to the obvious conclusion: what if someone gets hold of the Private key?

If the Private key is leaked or compromised, an adversary is able to go back in time and decrypt all the previously sniffed (recorded) traffic encrypted using the same long-term key pair and steal the sensitive information transmitted through the network channels.

A simple analogy, as if someone breaks into your house, he’ll be able to see not only what's in there right now, but also know everything from the past: all the people who used to live there, all the conversations that used to take place in the house or even the name of your cat.

By implementing the exchange mechanisms that provide Forward Secrecy, even though someone breaks into a house, he still won't know what was happening before he got there.

Benefits/Drawbacks

The mechanisms that provide FS use the Diffie-Hellman (DH) key exchange as key material, precisely its Ephemeral mode. OWASP (Open Web Application Security Project) gives the following definition of ephemeral keys:

Ephemeral keys are temporary keys used for one instance of a protocol execution and then thrown away. An ephemeral key has the benefit of providing forward secrecy, meaning a compromise of the site or service's long term (static) signing key does not facilitate decrypting past messages because the key was temporary and discarded (once the session terminated).

In other words, the session key generated upon the negotiated DH parameters is unique for each individual session, does not rely on the server’s long-term keys (they are only used for the server’s authentication purposes) and will be erased after the session is ended. Obviously, this increases drastically the protection of the encrypted traffic.

Only the Diffie-Hellman Ephemeral (DHE) and its lighter version based on Elliptic Curves (ECDHE) key exchange mechanisms provide the Forward Secrecy.

After all, both DHE and ECDHE degrade the website’s performance (i.e. page’s loading speed) when used with RSA long-term keys, as both imply the heavy arithmetics that significantly increase the CPU load. When used with ECDSA (Elliptic-Curve Digital Signature Algorithm) long-term keys however, the difference in performance is not so crucial. For now, EC keys are not yet so widely supported. Despite that, you can already get the certificate signed with EC key from us. Feel free to check more details here.

Using the cipher suites that provide key exchanges with FS only can cause some incompatibilities with legacy systems, but isn’t it a reasonable cost for such a security enhancement?

It is worth mentioning that you should pay special attention when enabling the support of the cipher suites that imply DHE key exchange as they are the main vector of the new vulnerability in TLS protocol discovered by the group of researchers who brought to us the FREAK Attack. The new attack is called Logjam. DHE with weak DH group and DHE_EXPORT cipher suites are affected.

In order to mitigate the attack, the support of the DHE-EXPORT cipher suites should be disabled. As for the DHE ciphers, it is recommended that the custom DH group is used instead. The size of the DH key in a custom DH cipher group should be increased so that it matches the recommended length of the long-term key (current standard is 2048-bit).

Some servers don’t have an option to set the custom DH groups or change the size of the DH key, therefore, the support of DHE cipher suites should be disabled. As an alternative, the ECDHE should be used. The ECDHE key exchange is slightly faster in comparison to DHE and is widely supported by the majority of web browsers.

Another drawback is that due to the server administrators’ unawareness, the Forward Secrecy can easily be broken. It is not enough to enable the support of the cipher suites with certain FS key exchange mechanisms on the server, but to prioritize them to be used by the server in the first place at all times.

Another way to mess up the Forward Secrecy is to configure the server to use the long duration session IDs or session tickets, which are used for the session resumption.

Ivan Ristic, the Director of Engineering at the cloud security firm Qualys, defines the following attack vectors in his article dedicated to Forward Secrecy:

“Server-side session management mechanisms could also impact forward secrecy. For performance reasons, session keys might be kept for many hours (or longer) after the conversation had been terminated.

In addition, there is an alternative session management mechanism called session tickets, which uses separate encryption keys that are infrequently rotated (possibly never in extreme cases). Unless you understand your session tickets implementation very well, this feature is best disabled to ensure it does not compromise forward secrecy.”