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. 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%. 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. The benefits of ECDHE outweigh the risks of using RC4, 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. 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. 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]. > So let me be blunt. Why we can't have[5] a setting that will allow users of > over 2% of servers increase their security[6] and make youtube usable for > people that disabled RC4[7,8,9]. While we have a setting like > security.ssl3.rsa_seed_sha which as far as I can see affects no servers[6]? > I agree that we should treat the RSA-AES-GCM cipher suites the same way we treat those other cipher suites that are disabled by default. I filed bug 1031952 [5] and wrote the patch to remove the unneeded preferences. > 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. The prefs like security.ssl3.rsa_seed_sha existed before we started the effort to reform Firefox's cipher suite, and it was always intended to remove them once we'd verified that we hadn't caused any significant compatibility issues with the new configuration. Cheers, Brian [0] http://telemetry.mozilla.org/#filter=release%2F30%2FSSL_CIPHER_SUITE_FULL&aggregates=multiselect-all!Submissions&evoOver=Builds&locked=true&sanitize=false&renderhistogram=Table [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1029179#c3 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1035818 [3] https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1197884 [4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=733564 [5] https://bugzilla.mozilla.org/show_bug.cgi?id=1031952 -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
