----- Original Message ----- > From: "Brian Smith" <br...@briansmith.org> > To: "mozilla's crypto code discussion list" > <dev-tech-crypto@lists.mozilla.org> > Cc: mozilla-dev-tech-cry...@lists.mozilla.org > Sent: Thursday, 10 July, 2014 2:40:55 AM > Subject: Re: Road to RC4-free web (the case for YouTube without RC4) > > On Tue, Jul 1, 2014 at 7:15 PM, Julien Pierre <julien.pie...@oracle.com> > wrote: > > > On 7/1/2014 14:05, Brian Smith wrote: > > > >> I think, in parallel with that, we can figure out why so many sites are > >> still using TLS_ECDHE_*_WITH_RC4_* instead of TLS_ECDHE_*_WITH_AES* and > >> start the technical evangelism efforts to help them. Cheers, Brian > >> > > The reason for sites choosing RC4 over AES_CBC might be due to the various > > vulnerabilities against CBC mode, at least for sites that support TLS 1.0 . > > I think a more useful form of evangelism would be to get sites to stop > > accepting SSL 3.0 and TLS 1.0 protocols. > > > > Servers that cannot, for whatever reason, support the AES-GCM cipher > suites, should be changed to prefer AES-CBC cipher suites over RC4-based > cipher suites at least for TLS 1.1 and later. > > Most sites are not going to stop accepting SSL 3.0 and/or TLS 1.0 any time > soon, because they want to be compatible with Internet Explorer on Windows > XP and other software that doesn't support TLS 1.1+. > > However, in the IETF, there is an effort, spearheaded by our friends at > Google, for solving the downgrade problem: > http://tools.ietf.org/html/draft-ietf-tls-downgrade-scsv-00 > > This simple feature, if implemented by the browser and by the server, > allows the server to recognize that the browser has tried a non-secure > downgrade to a lower version of TLS. Once the server recognizes that, the > server can reject the downgraded connection. The net effect is that, > assuming modern browsers quickly add support for this mechanism, the server > can be ensure that it only uses CBC cipher suites with modern browsers over > TLS 1.1 or later and that it never uses RC4-based cipher suites with modern > browsers (in conjunction with the "prefer AES-CBC cipher suites over RC4 > cipher suites" change I suggest above). > > However, it is likely that crypto libraries that make the two changes above > will also have support for TLS_ECDHE_*_WITH_AES_*_GCM cipher suites too. > So, I hope that they also enable TLS_ECDHE_*_WITH_AES_*_GCM at the same > time they deploy these changes. > > FWIW, I filed bugs [1][2] for adding support for > draft-ietf-tls-downgrade-scsv-00 to NSS, Gecko, and Firefox.
What basis do you have to assume that server administrators will actually upgrade their Apache/nginx/lighttpd/OpenSSL/etc. installations? There are many installation that still haven't fixed their servers after Heartbleed (0.5%) or the CCS vulnerability (9%)[1]! Over 1% of servers still support SSL3 only[2]! 1 - https://www.trustworthyinternet.org/ssl-pulse/ 2 - http://wp.me/p4BPwe-x -- Regards, Hubert Kario -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
