----- Original Message ----- > From: "Brian Smith" <br...@briansmith.org> > To: "mozilla's crypto code discussion list" > <dev-tech-crypto@lists.mozilla.org> > Sent: Monday, June 30, 2014 12:23:41 AM > Subject: Re: Road to RC4-free web (the case for YouTube without RC4) > > On Sun, Jun 29, 2014 at 11:18 AM, Hubert Kario <hka...@redhat.com> wrote: > > > Because of that, disabling RC4 should be possible for many users. The big > > exception for that was YouTube video servers[4] which only recently gained > > support for TLS_RSA_WITH_AES_128_GCM_SHA256. > > > > Hi, > > I read your blog post at > http://securitypitfalls.wordpress.com/2014/06/29/is-rc4-less, which is > interesting. The blog post compares how enabling/disabling various cipher > suites affects the percentage of sites that end up negotiating RC4. > However, I noticed that you didn't measure how enabling/disabling various > cipher suites affects how often Firefox uses ECDHE, DHE with a strong > (>=1280 bit, at least), DHE with weak, or RSA key exchange.
This data is in the full scan results at: http://securitypitfalls.wordpress.com/2014/06/24/rc4-only-servers-fall-below-1-june-2014-scan-results/ Basically, for DHE there exist 2 sizes: 1024 bit (93% of DHE) and 2048 bit (6% of DHE servers). > Using the Firefox 30 telemetry data [0], I saw that > TLS_ECDHE_RSA_WITH_RC4_128_SHA is still the 7th most commonly negotiated > cipher suite, at ~1.1% of all full handshakes that Firefox does, and that > TLS_ECDHE_ECDSA_WITH_RC4_128_SHA is the 12th most common cipher suite, at > 0.1%. Also note that these two cipher suites are the least-preferred ECDHE > cipher suites in Firefox's ClientHello, so it seems likely that disabling > these two cipher suites will reduce the use of ECDHE by ~1.2%. That's true only if we don't enable any other ECDHE suites. Enabling just ECDHE-RSA-AES128-SHA256 causes Firefox to negotiate RC4 with 2% less servers, without disabling or changing order of any RC4 cipher. The "Firefox 29 and one more cipher" section at the blog. > IIRC, when I > analyzed this previously, I found that almost every site negotiating > ECDHE-RC4 cipher suites would do RSA key exchange if we disabled these two > cipher suites. That's assuming we don't enable any other suites. > The benefits of ECDHE outweigh the risks of using RC4, I have to disagree here. Even 1024 bit DHE requires a targeted attack at ~80 bit complexity. Currently we see RC4 at around 56 bit, with a completely unoptimized attack... > so I > think that disabling these two cipher suites or changing their > prioritization in the Firefox ClientHello would be a bad idea at this time. > So, at a minimum, it would be important to re-run your analysis with these > two cipher suites still enabled to see what the real effect of adding > RSA-AES-GCM cipher suites. I'm assuming that you want to see the effect with regards to selected cipher suite and key exchange (ECDHE vs DHE vs RSA). Please say which cipher lists you want simulated. > As I noted in my bug comment [1], I think that the rhetoric of us not > adding any more RSA-key-exchange-based cipher suites, even the AES-GCM > ones, is significant. Software engineers at multiple companies referenced > our positions on this as part of making the business case for raising the > priority of ECDHE support in their products. I fail to see how changing /non default/ settings affects that. I mean, I've been surfing with disallowed pictures for mixed content (security.mixed_content.block_display_content). You'd be surprised at amount of sites that break because of that. Disabled JavaScript is similar. Webmasters make sites and configure servers against the lowest common denominator: it works, then the work is done. They don't check what happens if the user is running non standard configuration. I've never seen a website that said to the user to modify the settings in about:config to make the site work as intended. It's not like you plan to remove support for those ciphers from NSS, do you? Disabling access to just under 1% of servers is too much, so we can't remove RC4 from default. Adding additional ciphers may bring the amount of sites that use RC4 from 20% to 18% but it will not bring it below 18% as long as RC4 ciphers are enabled. I want a setting for early adopters. So that statistics for servers start showing that the clients don't advertise support for RC4 ciphers, so that server side stats show that support for other ciphers is important for interoperability. > It has been slow going, but > also it has only been half a year since we shipped the new cipher suite > configuration in Firefox. The effects on other products will be more clear > soon, if what I am told is correct. In particular, I see that Red Hat [2] > and Canonical [3] are still debating whether to backport ECDHE support to > Apache 2.2. I think that by maintaining our position here, we can help the > engineers working on that make a stronger case for those backports. > > By the way, I'd like to again thank Kurt Roeckx for his efforts to convince > Debian to backport ECDHE support to Debian's Apache 2.2 [4]. I'm glad to hear that there are similar initiatives to the one we have in RedHat. > > Note that I'm not talking about changing the default configuration, I'm > > talking only about adding optional functionality. > > > > Like I said in the bug [1], in PSM we only add such prefs as a last resort, > and I don't think we're that desperate yet. 20% of Internet servers negotiating suboptimal ciphers is not *really bad*? How much do we have to reach for that to be a problem? -- Regards, Hubert Kario -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
