SSL/TLS cipher selection, with examples and discussion

The last post has examples of some TLS web server crypto configs, but I didn't explain them, particularly why some are better than others. Let's remedy that.

We'll start with some good ones (always start by examining properly packed parachutes!).

Thawte
The completist

grade for www.thawte.com is HIGH

negotiated cipher for www.thawte.com:
DHE-RSA-AES256-SHA
ephemeral keying -> 1024 bits [expires Sat Jan 17 23:59:59 UTC 2009]

valid ciphers for www.thawte.com:
DHE-RSA-AES256-SHA
AES256-SHA
EDH-RSA-DES-CBC3-SHA
DES-CBC3-SHA
DHE-RSA-AES128-SHA
AES128-SHA
RC4-SHA
RC4-MD5
RC4-MD5 (SSLv2)

It is clear that a lot of thought went into the selection of these ciphers and their order of preference (this test only shows us the top choice of the server). Starting at the bottom we have the sole SSLv2 cipher for use by the crustiest old browsers. RC4-MD5 is the strongest, widely deployed, unencumbered SSLv2 cipher, so this is the best choice for backwards compatibility. Next there are 2 more RC4 ciphers (both MD5 versions likely come from the same config statement): the same as the bottom, but in TLSv1/SSLv3 guise, and a slightly improved version with SHA1. Again, these are great choices for balancing the minimum security supported against the need to support as many clients as possible.

The top 6 ciphers can be divided into 3 pairs, with each pair using a strong symmetric cipher with and without ephemeral keying. AES128 and Triple DES (the DES ciphers shown with 168 bit keys) are the most common, high strength, symmetric ciphers in modern browsers. The top cipher (DHE-RSA-AES256-SHA) is not only the strongest cipher you can reasonably expect browsers to support, it's also the most preferred cipher from this server. Although I'd like to see a 2048 bit server key to give a bit more strength to sessions not using the DH ciphers, this is a really clean config.

Great job, Thawte!

Microsoft
The minimalist

grade for www.microsoft.com is MEDIUM

negotiated cipher for www.microsoft.com:
AES128-SHA
server certificate strength is LOW -> 1024 bits [expires Wed Feb 11 18:25:18 UTC 2009]

valid ciphers for www.microsoft.com:
AES256-SHA
DES-CBC3-SHA
AES128-SHA
RC4-SHA
RC4-MD5
RC4-MD5 (SSLv2)

This config is very similar to the one from Thawte (great minds think alike?), with the elimination of the DH ciphers. One point of note is that they have chosen not to make the default cipher the strongest one available. This, again, is likely a conscious choice to balance compatibility, security, and performance. AES128-SHA is a very high security cipher, but it also has good performance on a variety of devices. A 2048 bit server key would make this a perfect, all-purpose config.

I haven't checked whether these ciphers are the defaults for IIS. If they are, even more credit to Microsoft for delivering a default security posture superior to many, competing products. Either way, good job!

As a side note, Comodo has a very good, very similar configuration, but the difference makes it less useful as an example.

UPDATE 2008-03-30: This is a really useful little post about IE ciphers. Good reading!

And now, some not so good ones.

Facebook
The kitchen sink

grade for www.facebook.com is LOW

negotiated cipher for www.facebook.com:
RC4-MD5
server certificate strength is LOW -> 1024 bits [expires Tue Sep 28 23:53:12 UTC 2010]

valid ciphers for www.facebook.com:
DHE-RSA-AES256-SHA
AES256-SHA
EDH-RSA-DES-CBC3-SHA
DES-CBC3-SHA
DHE-RSA-AES128-SHA
AES128-SHA
RC4-SHA
RC4-MD5
RC4-MD5 (SSLv2)
EDH-RSA-DES-CBC-SHA
DES-CBC-SHA
EXP-EDH-RSA-DES-CBC-SHA
EXP-DES-CBC-SHA
EXP-RC2-CBC-MD5
EXP-RC2-CBC-MD5 (SSLv2)
EXP-RC4-MD5
EXP-RC4-MD5 (SSLv2)

Yikes! I have to think they didn't put much thought into this configuration. It looks like they either went with the Apache default config (which is a bloated mess), or just turned on almost every option and (mostly) called it a day. There is no good reason to include any export ciphers, much less lots of export ciphers (if anyone has solid data supporting or contradicting that assertion, I'd really love to see it). Those 56 bit DES ciphers are similarly antiquated and have no business in there.

The worst part is that, having thrown in every cipher they could find, they set the default to RC4-MD5, a medium security cipher. Facebook has chosen to take the same cipher our good examples above use as a last-ditch fallback for TLSv1/SSLv3 negotiation and made it their preferred cipher. Adding insult to injury is that 1024 bit server key.

A little thought and planning would go a long way.

Bank of America
The heist

grade for www.bankofamerica.com is LOW

negotiated cipher for www.bankofamerica.com:
RC4-MD5
server certificate strength is LOW -> 1024 bits [expires Sat Jan 17 23:59:59 UTC 2009]

valid ciphers for www.bankofamerica.com:
DES-CBC3-SHA
RC4-MD5
RC4-MD5 (SSLv2)
DES-CBC-SHA

It looks like someone spent a little time thinking about what to do here, and then decided on the wrong things. The 56 bit DES cipher serves no purpose, there are no AES-based ciphers, and the server default cipher is, as with Facebook, a medium security cipher best used as a fallback. Finally, they have the traditional, 1024 bit server key to round things out.

I'd like to say I expect better from a bank. Instead, all I can say is that I hope for better from a bank. I won't hold my breath.

Yes, gentle reader, the state of affairs in the rarefied world of SSL/TLS web server configuration is pretty rotten. I know we can do better than this. The problems are not technical, but social. Vendors must ship products with sane defaults. Companies who run secure web servers must take due care in configuring them. Customers of those companies should pressure them to fix things that are broken and then take their business elsewhere if problems persist.

setec astronomy