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.
2 comments:
If you're going to say 'no excuses', then you're going to need to answer the following:
Why is it that there is no way for any site to get 100?
What is your grading process?
Why are you supporting the Certification Cartel by stating that a certificate that is issued by a root that you (arbitrarily) don't recognize is a 0-point thing, REGARDLESS OF THE SECURITY POLICY AND NEEDS OF THE SITE?
No excuses. If we're the experts, then you need to let us be the experts on what our security policies require.
Kyle,
Thanks for the comment. Your questions are orthogonal to the points in the post, however, as the point I made was that decisions should be based on data and analysis, not on assumptions (or misinformation).
To your questions:
1) It is entirely possible for a site to achieve a score of 100. A related, and possibly more informative question, is why is there a 21 point range (80-100) for a grade of 'A'? The answer is that there are rapidly diminishing returns, a common engineering theme. For example, there is no meaningful advantage right now to use of 4096 bit instead of 2048 bit server keys. The scoring system allows for sane security trade-offs people have to make in the real world.
2) I'll be publishing this in the near future. There's no voodoo, I just haven't gotten around to writing it up in post form.
3) If you do not like the tool you are free not to use it and to ignore its results. Heck, you could even write your own that works the way you want. Good luck!
Ben
Post a Comment