In SSL/TLS, the cipher suite selects a set of algorithms, for several tasks: key agreement, symmetric encryption, integrity check.
The certificate type impacts the choice of the key agreement. Two parameters must be taken into account: the key type and the key usage:
- With a RSA key you can nominally use the "RSA" and "DHE_RSA" cipher suite. But if the server certificate has a Key Usage extension which does not include the "keyEncipherment" flag, then you are nominally limited to "DHE_RSA".
- With a DSA key you can use only a "DHE_DSS" cipher suite.
- With a Diffie-Hellman key, you can use only one of "DH_RSA" or "DH_DSS", depending on the issuing certificate authority key type.
Most SSL server certificates have a RSA key which is not restricted through a Key Usage extension, so you can use both "RSA" and "DHE_RSA" key types.
"DHE" stands for "Diffie-Hellman Ephemeral". This allows Perfect Forward Secrecy. PFS means that if an attacker steals the server private key (the one which is stored in a file, hence plausibly vulnerable to ulterior theft), he will still not be able to decrypt past recorded transactions. This is a desirable property, especially when you want your system to look good during an audit.
For the integrity check, you should not use MD5, and, if possible, avoid SHA-1 as well. None of the currently known weaknesses of MD5 and SHA-1 impacts the security of TLS (except possibly when used within a certificate, but that's chosen by the CA, not you). Nevertheless, using MD5 (or, to a lesser extent, SHA-1) is bad for public relations. MD5 is "broken". If you use MD5, you may have to justify yourself. Nobody would question the choice of SHA-256. The general consensus is that SHA-1 is "tolerable" for legacy reasons.
For symmetric encryption, you have the choice between (mostly) RC4, 3DES and AES (for the latter, the 256-bit version is overkill; AES-128 is already fine). The following points can be made:
RC4 and 3DES will be supported everywhere. The oldest clients may not support AES (e.g. Internet Explorer 6.0 does not appear to be able to negotiate AES-based cipher suites).
There are known weaknesses in RC4. None is fatal right away. Situation is somewhat similar to that of SHA-1: academically "broken", but not a problem right now. This still is a good reason not to use RC4 if it can be avoided.
3DES is a 64-bit block cipher. This implies some (academic) weaknesses when you encrypt more than a few gigabytes in a single session.
3DES can be heavy on your CPU. On a 2.7 GHz Intel i7, OpenSSL achieves 180 MB/s encryption speed with AES-128 (it could do much better if it used the AES-NI instructions) but only 25 MB/s with 3DES. 25 MB/s is still good (that's 2.5x what a 100 Mbits/s link can handle, and using a single core) but might not be negligible, depending on your situation.
The BEAST attack is an old academic weaknesses which has recently been demonstrated to be applicable in practice. It requires that the attacker spies on the link and runs hostile code on the client (and that code must communicate with the external spying system); the BEAST authors have managed to run it when the hostile internal code uses Java or Javascript. The generic solution is to switch to TLS 1.1 or 1.2, which are immune. Also, this concerns only block ciphers in CBC mode; RC4 is immune.
In a SSL/TLS handshake, the client announces his supported cipher suites (preferred suites come first), then the server chooses the suite which will be used. It is traditional that the server honours the client preferences -- i.e. chooses the first suite in the list sent by the client that the server can handle. But a server could enforce its own order of preferences.
DHE implies somewhat higher CPU consumption on the server (but it will not make a noticeable difference unless you establish several hundreds new SSL sessions per second).
There is no DHE cipher suite which uses RC4.
Summary: this leads me to the following preferred list of cipher suites. If the BEAST attack may apply to you (i.e. the client is a Web browser), use this:
- If the session uses SSL-3.0 or TLS-1.0, try to use
TLS_RSA_WITH_RC4_128_SHA.
- If the client supports TLS 1.1+, or if it does not support
TLS_RSA_WITH_RC4_128_SHA, or if you consider PFS to be more important to you than BEAST-like active attacks (e.g. you are most concerned about long-term confidentiality, not immediate breaches), then use TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (fallback to TLS_DHE_RSA_WITH_AES_128_CBC_SHA if the client does not support SHA-256).
- If DHE cipher suites are not supported by the client, use the corresponding non-DHE suite.
- Generic fallback is
TLS_RSA_WITH_3DES_EDE_CBC_SHA which should work everywhere.
Note that the choices above assume that you can alter the suite selection depending on the negotiated protocol version, which may or may not be an available option for your particular SSL server.
If BEAST does not apply to you (the client will not run hostile code), then drop RC4 support altogether; concentrate on AES-128 and SHA-256; fallback on 3DES and SHA-1, respectively; use DHE if available.
