« Holy depeering, Batman! | Main | Home AIDS testing »
October 11, 2005
OpenSSL SSLv2 rollback vulnerability
OpenSSL has announced a new vulnerability in their SSL implementation. Ordinarily, these things are simple (and boring) coding errors, but in this one is kind of an interesting study in how things can go wrong with security protocol implementations.One common problem in the design of protocols, especially security protocols, is version transitions. If you have multiple versions (or multiple algorithms) you generally want two implementations to use the strongest version (or algorithm) they have in common. But you also want switch-hitting implementations to roll back when they contact older implementations, in order to maximize compatibility. You also want to be able to detect if an active attacker is trying to downgrade you to a weaker set of parameters.
There are three commonly-used versions of SSL: SSLv2, SSLv3, and TLS. Despite the names, TLS and SSLv3 are very similar (and fairly strong) and SSLv2 is different (and somewhat broken). We naturally want to stop active attackers from forcing people's connections down from SSLv3/TLS to SSLv2. To make matters worse, while SSLv3/TLS has defenses against downgrading to weaker algorithms, SSLv2 does not. This makes it even more important to detect downgrade to SSLv2, because the attacker can roll you back to SSLv2 and then to a weaker algorithm inside SSLv2. Of course, it also makes it harder to detect downgrade to SSLv2 by active attackers.
In order to prevent this, SSLv3 and TLS use an interesting trick to detect rollback. When SSLv3 and TLS-capable client implementations communicate with an SSLv2 implementation, they use a special type of padding in the RSA encryption. SSLv3 and TLS server implementations automatically detect this padding and generate an error. What makes this work is that this looks like legitimate padding to ordinary SSLv2-only implementations.
So far so good. Here's the problem: old versions of Microsoft Internet Explorer
always used this kind of padding even when SSLv3 had been turned off.
This meant that there's no way to make an IE version
work in SSLv2 mode with a conforming switch-hitting SSLv3/SSLv3 implementation. In
order to compensate for this, OpenSSL had a flag SSL_OP_MSIE_SSLV2_RSA_PADDING, that turned off this check (thus making downgrade attacks possible, but
also preserving compatibility).
That's not a crazy design decision, but here's where things go wrong:
there are a lot of such client bugs, all of which potentially need
workarounds, so OpenSSL has a flag called SSL_OP_ALL,
which turns them all on for maximal compatibility. This flag is
set by default in some common OpenSSL-using programs programs, like mod_SSL.
Of course, if you're smart, you've probably already turned off SSLv2; very few clients are SSLv2 only these days and as I've said, it's not very secure under active attack. In that case, this problem doesn't affect you. But in most programs, having SSLv2 on is the default, and experience indicates that defaults are very powerful. The good news, of course, is that this is only useful for an attacker mounting an active attack on a connection and there's not a lot of evidence that those happen frequently. And of course, there are other potential active attacks (especially social ones) that we don't really control for, so it's not clear how much difference this particular vulnerability makes. Still, now would probably be a good time to turn off SSLv2, patch your copy of OpenSSL, or both.
Posted by ekr at October 11, 2005 9:46 PM | Filed under: