SSL/TLS and forward secrecy

Here is an interesting question: does SSL have perfect forward secrecy, so that an attacker who compromises a server key still can't decrypt the server's conversations?

(While lots of people talk about SSL, the real name of the whole protocol is TLS, more or less. 'SSL' is the name Netscape gave to the original protocol; TLS is the name that it was officially standardized as.)

The answer turns out to be 'sort of', as I have found out through a bunch of web searching and reading. As far as I can tell, the situation is more or like this:

• in general, SSL (the original Netscape thing) does not have forward secrecy.

• some versions of SSL in some circumstances will generate ephemeral server keys, giving you forward secrecy; my reading suggests that this happens when a server is talking to an 'export-restricted' client (a client that had the key lengths it could use crippled due to old US export regulations). Such clients are likely to be very extinct by now.

• TLS has optional perfect forward secrecy. TLS (like SSL) supports a variety of ciphers, and some of those ciphers include using Diffie-Hellman ephemeral key exchange, which gives you perfect forward secrecy.
• however, various sources suggest that many TLS implementations do not use these ciphers by default, and must be specifically configured to enable them. Unfortunately it's hard to tell, since many clients don't report the cipher used at this level of detail.

(Such TLS ciphers all have names that start with TLS_DHE_. Note that there are other ciphers starting with TLS_DH_; these apparently do not provide forward secrecy. Some programs may report the cipher names without the TLS_ on the front.)

(Update: some TLS ciphers that use ephemeral Diffie-Hellman have names that start with TLS_EDH_ instead of TLS_DHE_.)

Sidebar: the versions of SSL and TLS

Since I just sorted this out myself:

• SSL v2 is the original version released by Netscape in their first products. After a while it was discovered to have relatively fatal security flaws.
• SSL v3 is Netscape's second attempt, closing the holes in SSL v2.
• TLS 1.0 is what was standardized by the IETF; it is based on SSL v3 but is not the same thing. There have been two subsequent revisions, TLS 1.1 and TLS 1.2; I believe both were done to fix security issues.

None of the protocols are interoperable with each other, although they are compatible enough that the initial handshake between the client and the server will let the two figure out the most advanced version that can be used.

(Although it is very depreciated by this point, SSL v2 support still lingers on in many libraries and programs, mostly for backwards compatibility reasons. There are probably still SSL v2 servers and clients still running in the wild.)