From what I understand, all it takes to enable PFS on a webserver is adding ephemeral cipher suites (ones that use DHE and ECDHE for the key exchange) to the list of cipher suites used in SSL/TLS handshake. I'm aware that some older web services and crypto libraries do not support these cipher suites. But besides that, all modern browsers support PFS. Enabling PFS does not prevent older, incompatible browsers from working in case some users can't or refuse to upgrade.

So, what's the issue here? Why don't more websites implement Perfect Forward Secrecy?

3 Answers 3


Actually most Web sites do implement forward secrecy, i.e. at least one of the "DHE" (or "ECDHE") cipher suites. Most SSL implementations support them out of the box, and most SSL server certificates are adequate (with a DHE cipher suite, the server's key is used for a signature; but almost everybody uses RSA and almost all RSA certificates allow the key usage for signatures).

However, most SSL implementations are also courteous, in that the server follows the client preferences. This means that, in the list of cipher suites announced as supported by the client (in the ClientHello message), the server will usually select the first one which is also supported on the server side. Since most clients tend to put the non-DHE cipher suites first, DHE suites remain unused.

The extra cost incurred by DHE cipher suites is slight, and almost always negligible:

  • The computational cost for the handshake is about doubled. This means that a basic server may do "only" 1000 full handshakes per second instead of 3000, based on its available CPU. Since servers don't usually boast 1000 new clients per second, on a single PC, this limitation is never a true limitation in practice.

  • The extra bandwidth is small: less than 1 kilobyte of overhead induced by the use of a DHE cipher suite. There again, this overhead is only for a full handshake, i.e. the very first connection between a client and a server; subsequent connections will use the "abbreviated handshake", which is more efficient, and completely unimpacted by the actual cipher suite.

So, to sum up, forward secrecy is already there and it is underused only because of the traditional behaviour of clients and servers (preference order) which remains as it is for no good technical reason, only inertia. In some cases, developers or sysadmins deactivate DHE support based on some unsubstantiated rumour about how DHE is "very expensive" and "might heavily impact performance", but these myths are easily dispelled with some actual benchmarks, and are still rare. Browsers and servers choose non-DHE cipher suites mostly because that is the default behaviour and nobody feels motivated enough to do anything about it.

To be complete, there is an extra effect: when the BEAST attack was published, people semi-panicked, and the common mantra was: "use RC4, it is immune". SSL has no DHE cipher suite with RC4 (there is no incompatibility between DH and RC4, but it just happens that no such standard cipher suite has been defined). So this resulted in clients and servers preferring RC4 cipher suites, which indirectly implies not using the DHE cipher suites.

  • 1
    According to Qualys SSL Labs, 51% of SSL-enabled sites surveyed did not support PFS with modern browsers, 42% had some PFS suites enabled and only 2.6% supported PFS with most browsers. So, if you're arguing that most servers do support it and that it's just not chosen by the client, then why aren't more servers configured to honor cipher order with the PFS suites placed first in line. I understand what you're getting at with BEAST, but it has been mitigated client-side now. Plus, RC4 is now considered broken. Apr 11, 2014 at 19:47
  • BEAST has been mitigated client-side in many ways, but some widely used "test your server" sites will award a "A+" mark only if your server enforces RC4 whenever possible. If you want to conclude that such test sites simply make problems worse... well, you would be right.
    – Tom Leek
    Apr 11, 2014 at 19:53

DHE handshake is very expensive and thus might heavily impact the performance of the server. ECDHE is much better (only about 15% overhead with optimized implementations) but you need a library which supports it. OpenSSL, e.g. the library which is behind most of the UNIX based webservers, added support with 1.0.1 - and yes, this is exactly the version which added the heartbeat extension which let to the famous heartbleed attack. So, if your server requires OpenSSL and you want to use effective PFS and be also be immune against this severe attack you have to use an OpenSSL version a few days old or patch your version.

So in the end it might have been a good thing that lots of web sites where too lazy to add PFS :)

  • 1
    Not quite. OpenSSL implements ECDHE (and ECDH-anon and ECDH-static) since 0.9.8, but they were disabled by default and you needed to rather arcanely tweak the cipherlist to get them. 1.0.0 (and 1.0.1) enabled them by default -- in upstream; RedHat builds disabled all ECC in OpenSSL apparently over patent issues until a few months ago. But in all versions through 1.0.1 even when an ephemeral suite is in both cipherlists (client and server) it can only be selected if the server also sets the "temporary" parameters (curve for ECDHE, p,g for DHE) -- that has NO default. ... Apr 11, 2014 at 6:32
  • ... And for ECDHE the server must set a curve the client supports; that part can be automated (only) in 1.0.2 now in beta. What 1.0.1 added that many people wanted was TLS versions 1.1 (with the real fix for BEAST rather than workaround) and 1.2 (with SHA-2 HMAC and KDF, and AEAD modes/suites), and it also added (as you correctly say) Heartbeat. Apr 11, 2014 at 6:35

Here are some reasons that sites do not implement forward secrecy (also called Perfect Forward Secrecy or PFS).

By definition, only the TLS-terminating server and the client can decrypt the actual payload. This means that other processes, which may have a legitimate reason to decrypt the cipher text, are locked out of the conversation. There are many legitimate reasons to do this, and here are some examples.

  • PFS will break an availability-monitoring system that periodically taps the traffic, decrypts it, checks for status codes and then marks the network as "up" or "down." I've seen entire datacenters go dark because of this.

  • Diagnostic tools, such as 'ssldump' no longer work with PFS. Suppose an end-customer says "I enter my username and password, and the system says I am logged in, but I am not. What is happening?" With PFS, administrator cannot capture a specific connection and then decrypt it to see the HTML inside.

  • WAN accelerators get each session key and then perform de-duplication of data for a whole office in spoke-and-hub configurations. WAN accelerators improved performance and reduced bandwidth. Imagine 50 people in a campus office connecting to headquarters to download the same 5Mb PDF file (e.g. new price list). De-duplication meant that the PDF was transferred from the home office exactly ONCE, and everyone else accessing it from the campus site would silently receive the local copy cached by the WAN accelerator. PFS breaks that, and now the PDF has to be transferred 50 times.

  • High-availability (HA) systems that share SSL keys can be broken by PFS. Suppose you are downloading a gigabyte ISO file over a slow TLS connection and the TLS server suddenly goes dark. In an HA system, another TLS server can compute the session key and can silently "pick-up" the connection and keep your download going. PFS can break older HA systems. Note: HA SSL sites are pretty rare but they are out there.

    I have seen all of the examples with customers. Yes, there are ways around each of them, but they all involve extra work.

When a site administrator or TLS vendor is trying to prioritize fixes and features, they may decide that the touted benefit of forward secrecy (preventing nation-states from spying), does not justify network changes or increased bandwidth at this time.

That said, if you measure by IP addresses (and not alexa rank) most of the Internet (50%+) supports TLS because the are simple one-box servers that don't have these more complicated requirements.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .