I got some feedback from someone responsible for security at a major site currently tracked in the TLS Report. They took issue with my methodology and gave what I can only describe as excuses for how they were choosing to configure their servers. His argument went something like this:
We support (several) export ciphers because we want to make sure everyone on every browser ever released can access our service. If users want to negotiate a strong cipher, they can! Also, we use a mediocre default cipher because stronger ciphers would be too slow.
Let's break this down:
1) Support for export ciphers
It's 2008. There is no good reason anymore to support export ciphers. If you insist on supporting export ciphers, at least alert users when such a weak cipher is negotiated. Heck, give them suggestions for upgrading to a better browser. Users see the little lock and they assume everything is locked down. They don't know the difference between DHE-RSA-AES256-SHA and EXP-RC2-CBC-MD5. You do.
2) Stronger ciphers are there if people want them
Browser vendors recognize they must support a huge variety of ciphers to deal with the huge variety of ciphers supported by servers. By default, they are almost all turned on. The result is obvious: regardless of the stronger ciphers that could be negotiated, the server default is what will be used. In order to get those stronger ciphers, users would either have to disable all the weaker ones, locking them out of numerous sites, or switch to a browser like Opera, that plays tricks to figure out the strongest available cipher on a server.
The power for this is almost entirely in the hands of the server operators. You know this. Use your power for niceness.
3) Stronger ciphers would be too slow
This is mostly true, although not always relevant. For pages that are not huge, the total processing is often dominated by the session setup. Public key crypto is extremely expensive. If you are spending most of your time on it, then moving to a stronger cipher may have no interesting impact on total performance. See this and this for some really interesting analysis.
The most important aspect of this response, however, is that it is free of any factual basis. Do the analysis, and make decisions based on the facts. If you collect statistics on the set of ciphers your customers' browsers are offering, and you see lots of folks who require export ciphers, figure out how to support them. If you don't see that sort of traffic, or not enough of it to keep supporting it, turn the export ciphers off. If you do performance analysis based on request traces to see the impact of, say, switching from RC4-SHA to AES128-SHA as your default cipher, and discover it would be hideously expensive to change, then don't. What you should not do is assert, without analysis, that these things are true (or false).
No excuses, y'all. As operators of TLS servers, you are the experts on which your users depend. Don't let them down.
Enter the 36 chambers of infrastructure wu-tang
- ▼ June (7)