On Oct 31, 2014, at 7:24 AM, Maxim Dounin <[email protected]> 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 > [email protected] > http://mailman.nginx.org/mailman/listinfo/nginx-devel > _______________________________________________ nginx-devel mailing list [email protected] http://mailman.nginx.org/mailman/listinfo/nginx-devel
