(+CC: Analytics)
On Wed, Oct 15, 2014 at 8:54 AM, Giuseppe Lavagetto glavagetto@wikimedia.org wrote:
So, the somewhat-anticipated new SSL vulnerability is out, CVE-2014-3566.
To make the long story short:
- SSL v 3.0 operating with CBC-mode chiphers is vulnerable to this
attack and could allow an attacker to get plaintext info on the traffic being exchanged with the server
- It's fairly easy for an attacker to induce a downgrade from more
modern version of TLS to SSL 3.0
There are some patches that would eliminate the downgrading issues *for chrome users only at the moment*, but I'm not that happy with the idea of patching openssl and maintaining the patch.
Another possibility would be to force use of RC4 in SSL 3.0, which as Brandon put it on IRC is almost as using rot13.
So, the easiest (and best) way of getting rid of this vulnerability (and a bunch of others, to be honest) would be to drop SSL 3.0 support. That would mean dropping HTTPS support for IE6 users, which is a decision we can't make lightly, but keeping SSL 3.0 exposes the vast majority of our users to this vulnerability.
What should we do? This is not as serious as heartbleed but shouldn't be taken lightly anyway.
So to sum it up again:
SSL 3.0 is vulnerable/weak, enabling RC4 doesn't help much. Keeping SSL 3.0 enabled with RC4 for clients that only support SSL 3.0 (mostly IE 6 and below it seems) -might- be acceptable, if we could warn those users when they use it, and if we can prevent every other browser from downgrading to it. But that doesn't seem possible at the moment; Google's TLS_FALLBACK_SCSV needs all clients and servers patched, which will obviously take a long while and has maintainability issues. Also depends on whether OpenSSL and/or Debian will incorporate this nonstandard patch... at least this affects a lot of people.
Disabling SSL 3.0 could break SSL completely for something in the order of 1.5% of HTML page requests, according to http://stats.wikimedia.org/wikimedia/squids/SquidReportClients.htm Perhaps the Analytics team could do some additional, specific investigation on this to aid this decision?
I think if we can't allow secure HTTPS by keeping SSL 3.0 enabled, we should probably disable it even if it breaks a small number of requests. 1.5% doesn't seem insignificant though. Obviously we'd need to communicate that very well, as we don't seem to have good options for doing any sort of fallback to HTTP. I guess it also depends on what the public awareness of this issue will be...