Sunday, June 15, 2008
What not to do, part 2
As expected, there are many TLS sites using keys generated using the flawed, Ubuntu version of OpenSSL. Netcraft has the latest.
Thursday, June 12, 2008
Selecting cryptographic key sizes
Selecting cryptographic key sizes is a valuable reference for estimating the security margin for algorithms and key sizes and is deliciously applicable to TLS configuration choices.
A few tasty tidbits:
Does anyone seriously believe that published attacks represent the state of the art? It may safely be assumed that unpublished work is many years ahead of what the public at large gets to see: a public announcement that a system is broken provides at best a rather trivial upper bound – and a very simple-minded one, in our opinion – for the date that the system became vulnerable.
According to Table 1, 512-bit RSA keys should not have been used beyond 1986.
According to Table 1 usage of 768-bit RSA keys can no longer be recommended. Even in the cost-equivalent model 768-bit RSA keys will soon no longer offer security comparable to the security of the DES in 1982.
A few tasty tidbits:
Does anyone seriously believe that published attacks represent the state of the art? It may safely be assumed that unpublished work is many years ahead of what the public at large gets to see: a public announcement that a system is broken provides at best a rather trivial upper bound – and a very simple-minded one, in our opinion – for the date that the system became vulnerable.
According to Table 1, 512-bit RSA keys should not have been used beyond 1986.
According to Table 1 usage of 768-bit RSA keys can no longer be recommended. Even in the cost-equivalent model 768-bit RSA keys will soon no longer offer security comparable to the security of the DES in 1982.
SNI is goodness
SSL-enabled Name-based Apache Virtual Hosts with mod_gnutls.
I encourage you to try it out. I have no experience with mod_gnutls, but gnutls is top notch and 80% less code than mod_ssl is a good thing.
I encourage you to try it out. I have no experience with mod_gnutls, but gnutls is top notch and 80% less code than mod_ssl is a good thing.
Tuesday, June 10, 2008
Vertebra == genius
Vertebra is absolute genius. If the implementation is even half as spectacular as the concept, it will take over the planet and we will all worship it like a big golden calf written in Erlang and Ruby.
SSLv2 still considered harmful
Some argue that, although it is deeply flawed, SSLv2 is better than nothing and some very old clients don't support anything better. This is true in the same way that a beautiful lie is better than an ugly truth. I'm an ugly truth kind of guy. What about you?
From 2005: SSL V2 SNAFU
No doubt, everyone is patched up by now and no other such vulnerabilities are present, waiting to be discovered. No doubt.
From 2005: SSL V2 SNAFU
No doubt, everyone is patched up by now and no other such vulnerabilities are present, waiting to be discovered. No doubt.
Monday, June 09, 2008
The excuses
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.
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.
Subscribe to:
Posts (Atom)
