Why don't more websites implement Perfect Forward Secrecy?

Question

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?

Answer 1

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.

Answer 2

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 :)

Answer 3

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.