TLS: all those DH modes and PFS

Advice is easy to come by, explanation less so.  What are all these acronyms, and what makes them secure, or not?

Diffie-Hellman

All of these *DH* modes are variations on Diffie-Hellman key exchange, in which two parties pick secrets, "mix" them into a common starting point, exchange the results, then "mix" in their secrets once more to generate a shared key.  The important property of this shared key is that it can't be easily created even if an attacker has both of the numbers that were exchanged in public.  This is a widely-used crypto algorithm that underlies SSH as well.

Depending on how it's used, DH can also derive a new key every session, yielding perfect forward secrecy (PFS): if the key on a given connection were brute-forced by Sam, he can now see data only from that connection, not from all communications between Alice and Bob.

ADH

First off, it stands for Anonymous Diffie-Hellman.  Cipher suites incorporating ADH do not have a certificate verification step.  If Sam intercepts your communication and your client software supports ADH ciphers, then he can pretend to be the real server—and your client software won't know the difference.

Industry best practice calls for disabling the ADH suites on your server, but I'm not convinced it's actually relevant.  Firefox does not support ADH in the first place.  Assuming an ADH-capable client in the presence of a man-in-the-middle (MITM), it's not clear that preventing that attacker from using ADH upstream is any sort of gain.

RSA vs. DH

TLS uses asymmetric encryption (which is how both RSA and DH work) in order to establish a symmetric secret key for the session.  Symmetric keys are faster and smaller, but knowing the symmetric key allows for decrypting all of the channel traffic.  With RSA and DH, the information is split between public and private portions and data encrypted under the public key is useless without the private key.  (Hence the asymmetry: it's not just one key.)

In order to establish a symmetric session key, some data about it has to be exchanged on the wire, but knowing the data means knowing the key.  To hide the session data from the attacker, it's encrypted either with the server's public RSA key, or the key derived from a DH exchange.  I touched on how DH derives a key above; in the RSA alternative, only the server holds the private key needed for decryption, which ensures Sam can't read the session key material if he intercepts it.

As I understand it, RSA and DH are pretty much equivalent in terms of security properties at the moment.  But what about those DHE modes?

DHE

If Sam breaks DH or RSA, then he gains access to all of the key material for all connections he has ever intercepted that use that server certificate.  All of the data that was transferred on the wire exists within the server's keys, so once he obtains the key, decrypting any stream becomes trivial.

DHE (the E stands for ephemeral) exists to avoid this problem.  Instead of using the same parameters for every connection, the server performs the DH exchange with a per connection secret, and signs the resulting public parameters.  Once signed, the client can use the server's certificate to verify that those DH parameters were really generated by the server it wants to talk to, not an attacker.

Furthermore, in event the server's private key is stolen, it doesn't yield the DH parameters.  They were generated for the specific connection and never saved anywhere.  This is what gives DHE its "ephemeral" label and provides the perfect forward secrecy: in the future, those secrets are gone.  In the end, the server's certificate (which contains its identification and public key) authenticates the server and protects the session key, but that key is no longer derived from data stored on the server.

ECDH(E)

ECDH and ECDHE bear the same relationship to each other as DH and DHE: the latter is the ephemeral version offering perfect forward secrecy.  The EC at the beginning stands for Elliptic Curve and refers to yet another math problem.

In this case, the underlying mathematics behave similarly to DH, but the same level of security can be attained using fewer bits in the secret.  It's currently believed that a 224-bit elliptic curve system is equivalent to a 2048-bit RSA or DH secret.  The complexity of the problem from an attacker's standpoint is raised to compensate, and the smaller key size means the server can perform its part much faster.

This was, in fact, the main motivation for ECDHE: that DHE was difficult for large websites to use.  Benchmarks show a 3100% increase in time to compute DHE compared to RSA, but only 27% for ECDHE.

The Real World

It's my understanding that DH and ECDH support is uncommon in the real world; as the DH parameters are part of the certificate, it seems they would need to be included in the certificate request, which no "Set up TLS" tutorial has ever covered.  I'm also going to bet that large sites who would see a lot of benefit from heavily optimizing their crypto layer would shy away from DHE, which leaves RSA and the much younger ECDHE as contenders.

And in fact, Google has rolled out ECDHE as the preferred cipher for clients which support it, and contributed the support for it back into OpenSSL.  Older platforms like IE (even version 8) on Windows XP don't support ECDHE, though.

If you're curious about what TLS ciphers your browser supports, there's a site for that.

Happy encrypting!