(+CC: Analytics)

On Wed, Oct 15, 2014 at 8:54 AM, Giuseppe Lavagetto
<[email protected]> 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...

_______________________________________________
Analytics mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/analytics

Reply via email to