Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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?

share|improve this question

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

share|improve this answer
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. ... –  dave_thompson_085 Apr 11 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. –  dave_thompson_085 Apr 11 at 6:35

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.

share|improve this answer
    
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. –  Python Noob Apr 11 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 at 19:53

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.