- DHE is significantly slower. For this reason, web site operators tend to disable all DHE suites in order to achieve better performance. In recent years, we've seen DHE fall out of fashion. 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.
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. Place ECDHE and DHE suites at 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:
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 determines which suite would be negotiated with each. As a result, it also tells you if the negotiated suite supports forward secrecy.
Here's what it looks like 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 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 rarely 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 at the time the communication is taking place. It is not possible to pile up mountains of encrypted traffic to decrypt later.
(2) It's also sometimes called perfect forward secrecy, but, because it is possible to uncover 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.