On Oct 31, 2014, at 7:24 AM, Maxim Dounin <mdounin@mdounin.ru> wrote:

> Hello!
>
> On Thu, Oct 30, 2014 at 04:33:09PM -0700, Piotr Sikora wrote:
>
>> Hey Maxim,
>>
>>> - SSLv3 is still important from compatibility point of view, there
>>> are various clients which doesn't support (or enable by default)
>>> anything better;
>>
>> But is it, really?
>>
>> All major browsers (Chrome [1], Firefox [2], IE [3], Opera [4]) either
>> already disabled SSLv3 or are about to do it.
>
> AFAIK, the only browser already disabled SSLv3 for now is Opera
> 12, an obsolete Presto-based branch. The links provided suggests
> the same.
>
> (This is mostly unrelated though, as from nginx point of view it's
> the number of clients without anything better than SSLv3 is
> important.)
>
>> Huge chunk of websites (>42% of Alexa's top 10.000 [5]) requires at
>> least TLSv1.0, including major properties like Facebook, Twitter [6],
>> Wikipedia [7] and websites that are using one of the popular CDNs
>> (CloudFlare [8], Akamai [9], MaxCDN [10], Fastly [11]).
>
> The 42% here means, on the other hand, that 58% are still
> available via SSLv3, including Google, Youtube, Amazon, Microsoft
> and so on. While 42% is a good number, I'm pretty sure the
> question is different.

As a minor comment, some interesting stats here

http://news.netcraft.com/archives/2014/10/15/googles-poodle-affects-oodles.html

>> OpenBSD and LibreSSL disabled SSLv3 by default [12].
>>
>> Furthermore, when we disabled SSLv3 across our network [8] and gave
>> website owners the ability to opt-in back to it... less than 0.001%
>> did re-enable it.
>
> And the comments there suggests people have problems with at least
> libcurl. On the other hand, I'm pretty sure that php scripts
> using libcurl with SSLv3 aren't vulnerable to POODLE.
>
>> Hopefully that list is long enough to convince you that SSLv3 is not
>> really important... Definitely not important enough to be enabled by
>> default, because that's what the commit changes, people can still
>> enable SSLv3 in the conf if they really need to.
>
> As previously said, this was alrady discussed excessively and
> we decided to preserve the default for now. We'll likely
> reconsider the change later.
>
> --
> Maxim Dounin
> http://nginx.org/
>
> _______________________________________________
> nginx-devel mailing list
> nginx-devel@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-devel
>

_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel