SSL Labs: Deploying Forward Secrecy

Ivan Ristic

Last updated on: December 20, 2022

Update: This post is obsolete. For guidance on how to deploy TLS securely, please read SSL/TLS Deployment Best Practices, which we always keep up to date.

With revelations about mass surveillance in the news everywhere, an obscure feature of SSL/TLS called Forward Secrecy has suddenly become very interesting. So what is it, and why is it so interesting now?

Session keys generation and exchange

Every SSL connection begins with a handshake, during which the two parties communicate their capabilities to the other side, perform authentication, and agree on their session keys. The session keys are then used to encrypt the rest of the conversation (session), possibly spanning multiple connections. They are deleted afterwards. The goal of the key exchange phase is to enable the two parties to negotiate the keys securely; in other words, to prevent anyone else from learning these keys.

Several key exchange mechanisms exist, but, at the moment, by far the most commonly used one is based on RSA, where the server’s private key is used to protect the session keys. This is an efficient key exchange approach, but it has an important side-effect: anyone with access to a copy of the server’s private key can uncover the session keys and decrypt the conversation.

For some, this side-effect is desirable. Many network security devices, for example, can be configured to decrypt communication (and inspect traffic) when given servers’ private keys. Without this capability, passive IDS/IPS and WAF devices have no visibility into the traffic and thus provide no protection.

In the context of mass surveillance, however, the RSA key exchange is a serious liability. Your adversaries might not have your private key today, but what they can do now is record all your encrypted traffic. Eventually, they might obtain the key in one way or another (e.g., by bribing someone, obtaining a warrant, or by breaking the key after sufficient technology advances) and, at that time, they will be able to go back in time to decrypt everything.

Diffie–Hellman key exchange

An alternative to the RSA-based key exchange is to use the ephemeral Diffie-Hellman algorithm, which is slower, but generates session keys in such a way that only the two parties involved in the communication can obtain them. No one else can, even if they have access to the server’s private key.1

After the session is complete, and both parties destroy the session keys, the only way to decrypt the communication is to break the session keys themselves. This protocol feature is known as forward secrecy.2

Now, breaking session keys is clearly much more difficult than obtaining the server’s private key (especially if you can get it using a warrant, for example). Furthermore, in order to decrypt all communication, now you can no longer obtain just one key (the server’s), but you have to compromise the session keys belonging to every individual conversation.

SSL and Forward Secrecy

SSL supports forward secrecy using two algorithms, the standard Diffie-Hellman (DHE) and the adapted version for use with Elliptic Curve cryptography (ECDHE). Why isn’t everyone using them, then?

Assuming the interest and the knowledge to deploy forward secrecy are there, two obstacles remain:

  • DHE is significantly slower. For this reason, web site operators tend to disable DHE suites in order to achieve better performance. Furthermore, not all browsers support all the necessary suites. Internet Explorer 9 and 10, for example, support DHE only in combination with obsolete DSA keys.
  • ECDHE too is slower, but not as much as DHE. (Vincent Bernat published a blog post about the impact of ECDHE on performance, but be warned that the situation might have changed since 2011. I am planning to do my own tests soon.) However, ECDHE algorithms are relatively new and not as widely supported. For example, they were added to OpenSSL only fairly recently, in the 1.x releases.

If you’re willing to support both ECDHE and DHE, then you will probably be able to support forward secrecy with virtually all clients. But ECDHE alone is supported by all major modern browsers, which means that even with only ECDHE you might be able to cover a large-enough chunk of your user base. The decision what to do is entirely up to you. Google’s sites, for example, tend to not have any DHE suites in their configuration.

Configuring Forward Secrecy

Enabling forward secrecy can be done in two steps:

  1. Configure your server to actively select the most desirable suite from the list offered by SSL clients.
  2. Put ECDHE and DHE suites to the top of your list. (The order is important; because ECDHE suites are faster, you want to use them whenever clients supports them.)

Knowing which suites to enable and move to the top can be tricky, because not all browsers (devices) support all forward secrecy suites. At this point you may want to look for inspiration from those who are already supporting forward secrecy, for example Google.

In the nutshell, these are some of the suites you might want to enable3 and push (close) to the top:

  • TLS_ECDHE_RSA_WITH_RC4_128_SHA [Updated] RC4 is no longer recommended

To make this process easier, I’ve added a new feature to the SSL Labs test; this feature, tentatively called handshake simulation, understands the capabilities of major browsers and can determine which suites would be negotiated. It will then tell you if the negotiated suites supports forward secrecy.

Here’s a screenshot of this feature in action:

When you get it right, you will be rewarded with a strong forward secrecy indicator in the summary section at the top:

Alternative attack vectors

Although the use of Diffie-Hellman key exchange eliminates the main attack vector, there are other actions powerful adversaries could take. For example, they could convince the server operator to simply record all session keys.

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.

(1) Someone with access to the server’s private key can, of course, perform an active man in the middle attack and impersonate the server. However, they can do that only when the communication is taking place. It is not possible to pile up a mountain of encrypted traffic and decrypt it later.

(2) It’s also sometimes called perfect forward secrecy, but, because it is possible to decrypt the communication by breaking the session keys, it’s clearly not perfect.

(3) I am assuming the most common case, that you have an RSA key (virtually everyone does). There’s a number of ECDHE suites that need to enabled if you’re using an ECDSA key. I am also ignoring GCM suites for the time being, because they are not very widely supported. I am also ignoring any potential desire to mitigate BEAST by favouring RC4, which might be impossible to do across all client devices.

Show Comments (30)


Your email address will not be published. Required fields are marked *

  1. the mentioned handshake simulation actually needs some more treaks. On servers that have a CACert certificate and when the server supports TLS 1.2 the handshake simulation says that IE would be able to connect with TLS 1.2. IE with TLS 1.1/1.2 enabled however refuses to connect to servers that have a CA with MD5 signature, even if it is just the root CA certificate that has a MD5 (self-)signature. Unfortunately threre is no obvious error message in IE when that error happens. Maybe a dedicated compatibility test result in the SSL Labs test should point out this pitfall on affected hosts – would be very helpful I think.

    1. Hi Benjamin,

      I not sure what to say. Good for you for building a similar tool before I did. I clearly wasn’t the first and I am sure I am not going to be last. If any similarities exist, they are due to the fact that tools of this kind will naturally follow the design of the SSL/TLS protocols. To be fair, given that your tool had been out before mine and that I had probably seen it then, it is possible that it influenced my thinking in some way. If you are looking for recognition, then, absolutely, thank you for your prior work.

      I prefer to think that it’s the years of hard work and sustained effort that make SSL Labs a great tool, not what yours might have looked like back in 2008.

      Now that that’s clear, let’s please stick to the topic of this blog.

  2. You reference Google as an example for the forward secrecy… Shame that Google is rated B on your scanner due to SSL3 and RC4.

    But they do Forward secrecy! :)

  3. The forward secrecy shows a failure “With some browsers”, even when I have set the ciphers in the server as per your recommendation:

    Is DHE required to completely pass the forward secrecy (for all browsers) in ssllabs?

    1. Probably; if you tell me the hostname you’re looking at I can provide more information. You can do it yourself, too. Scroll down to the simulations and check which suite is negotiated with every client there.

  4. We have configured our Forward Secrecy exactly to your specifications, yet it still shows weak on your scan. I cannot figure out why.

    Can you shed some light as to why I am still getting a weak Forward Secrecy when we have ordered strong to weak as per your recommendations?

    1. A “Robust” Attribute is assigned if you have only TLS 1.2 enabled, which means your Server does not support any older Protocols.
      This is a very safe Configuration, resulting in Availability of your Website only to Clients which are capable of TLS 1.2 .

      1. Well, no. Robust is triggered when a server supports both the DHE and ECDHE key exchanges, meaning it can use forward secrecy with a wide range of clients. The issue is that some clients don’t support DHE and some don’t support ECDHE; supporting both is the best approach.

        1. That doesn’t seem to be correct. The test can only find support for TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 on our server, but still adds the “ROBUST” mark to Forward Secrecy.

  5. I just ran this test on a testing server I have, and it said “The server does not support Forward Secrecy with the reference browsers. Grade reduced to A-.” and lead me to this page.

    The only browsers which had the “no FS” warning on them were IE6/XP (which failed to even connect due to restricted ciphers) and IE8/XP neither of which is marked with “R” for reference browser. Could you clarify what else could be causing that downgrade?

  6. So to make this change within WHM’s cipher suite command, would the following be correct with what you are suggesting?


  7. I used this setting on Apache 2.4 and the scan is all green:

  8. Hi everybody. Has anyone get an A grade with IBM IHS? (in my case 8.5) A obtain an A- due to the forward secrecy in “some browsers”. A can’t find the way to activate the ECDHE in TLSv1.0 for example.