Bug 999544 proposes to disable RC4 completely. The most discussed cipher is RC4-SHA, because it's the most used RC4 cipher. But other ciphers like RC4-MD5 (bug 1114809) and ECDHE-RC4 are not widely used and there are more secure and widely supported alternatives. Furthermore, since bug 1088915 is landed, it's very unlikely that a server still use ECDHE-RC4 and I've never seen a server, that requires ECDHE-RC4.

(In reply to sjw from comment #0) > Bug 999544 proposes to disable RC4 completely. The most discussed cipher is > RC4-SHA, because it's the most used RC4 cipher. But other ciphers like > RC4-MD5 (bug 1114809) and ECDHE-RC4 are not widely used and there are more > secure and widely supported alternatives. You can see the measurements of this here: http://telemetry.mozilla.org/#filter=beta%2F36%2FSSL_CIPHER_SUITE_FULL&aggregates=multiselect-all!Submissions&evoOver=Builds&locked=true&sanitize=true&renderhistogram=Table It is indeed the case that the ECDHE-RC4 cipher suites are rarely used now. It would be interesting to know which servers still negotiate ECDHE-RC4 with Firefox, and what cipher suite they negotiate when the ECDHE-RC4 cipher suites are disabled. In particular, it doesn't make sense to disable ECDHE-RC4 if all the servers that use it would choose RSA-RC4 (with no ephemeral key exchange) instead.

Referring to what I've seen on ssllabs and what every well-known guide recommend, I think they will fallback to ecdhe-cbc or dhe-cbc before rc4-sha is used. Sadly, Firefox does not support dhe-gcm and rsa-gcm (without FS).

(In reply to sjw from comment #2) > Referring to what I've seen on ssllabs and what every well-known guide > recommend, I think they will fallback to ecdhe-cbc or dhe-cbc before rc4-sha > is used. I think that would be rare. The reason is that Firefox first tries to handshake with this list of cipher suites: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b) TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a) TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009) TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x33) TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39) TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) TLS_RSA_WITH_AES_256_CBC_SHA (0x35) TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa) And then, only if that initial handshake fails, does it try again with RC4 enabled: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b) TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a) TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009) TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) TLS_ECDHE_ECDSA_WITH_RC4_128_SHA TLS_ECDHE_RSA_WITH_RC4_128_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x33) TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39) TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) TLS_RSA_WITH_AES_256_CBC_SHA (0x35) TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa) TLS_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_RC4_128_MD5 This implies that it should be very rare for a server to choose the ECDHE-RC4 cipher suite when it does support a non-RC4 cipher suite. It could happen if a transient error or MitM forces Firefox to retry with that RC4-enabled ClientHello, but that seems to be rare. Maybe a better improvement would be to patch NSS so that the priority of these two cipher suites is lowered: TLS_ECDHE_ECDSA_WITH_RC4_128_SHA TLS_ECDHE_RSA_WITH_RC4_128_SHA You can see how I modified the order in bug 936828. It should be straightforward to make a similar change to shift those two cipher suites down. If you write a patch to do so, don't forget to update the comments that document the rationale for the ordering. Also, touch security/nss/coreconf/coreconf.dep to force NSS to rebuild completely (it's build system is kinda broken).

Do you set the fallback SCSV on the fallback?

How the fallback SCSV is useful here? Our fallback order is TLS1.2-RC4, TLS1.2+RC4, TLS1.1+RC4, TLS1.0+RC4 (ignoring some corner cases for simplicity). Until TLS 1.3 is deployed, no servers will reject our TLS1.2+RC4 handshake because TLS 1.2 is the highest version the server supports. That said, we could indeed revisit the fallback logic because YouTube no longer relies upon RC4.

The clear technical consensus among the TLS WG is that RC4 MUST NOT be offered or accepted anymore. We're not talking about a mere deprecation here - which happened years ago and should have happened 10 years ago - this is a die-die-die draft about to go RFC and it needs to be disabled ASAP. One approach would be to take the RC4 ciphers out of all existing fallbacks, and offer TLS 1.0+RC4 last, presenting a red warning interstitial if that's the only one accepted, presenting SCSV on all fallbacks. That would pop up a warning if RC4 was all that's supported, which is appropriate. The user should be warned strongly not to proceed with sung a weak cipher. Treat it like you'd treat RSA-512 or DES or an EXPORT cipher?

(In reply to Alyssa Rowan from comment #6) > The clear technical consensus among the TLS WG is that RC4 MUST NOT be > offered or accepted anymore. If ignoring objections can be called a consensus, it is the consensus. Several people on the TLS WG already pointed out that people will just ignore the RFC. > presenting a red warning interstitial We can't distinguish whether the server actually required RC4 or the handshake failed for other reasons. When we disabled SSLv3, we confused users because of the wrong message ("Why Firefox still complains about the insecure protocol even when I disabled SSLv3 on my server?"). It does not solve the problem to cry out an unimplementable idea.

(In reply to Masatoshi Kimura [:emk] from comment #7) > Several people on the TLS WG already pointed out that people will just ignore the RFC. Please do not validate our cynical disillusionment about this: that isn't something to be proud of! RC4 is in *EXTREMELY* bad shape - the beginnings of a practical attack are now in public sight. Every day someone's using RC4, for any reason, they're going to regret it. The window needs to be closed ASAP. Scans indicate RC4-only usage is a tiny percentage overall; this was openly discussed by the WG with hard numbers. There was very strong technical consensus to adopt the draft regardless. > > presenting a red warning interstitial > We can't distinguish whether the server actually required RC4 or the handshake failed for other reasons. Yes you can: remove RC4 from the fallback dance and put it in as the last tango. If you *are* keeping fallback logic (and I gather from your security team that you might not?) then offer 1.2 with everything good first, then 1.1 without RC4 (w/SCSV), then 1.0 without RC4 (w/SCSV), then finally 1.0 with RC4 (w/SCSV). If the server then chooses RC4 despite every better option being placed on the table for them, present a red warning interstitial - and, perhaps, if practical, collect metrics. (Remember, if the server is even willing to *accept* RC4, it's also in contravention of this draft RFC.) That doesn't sound unimplementable to me, at all.

Here's what I suggest, in order: 1. Fix bug 1084025: Disable non-secure version fallback (the "fallback dance") 2. Fix bug 1125893: Move the TLS_ECDHE_RSA_WITH_RC4_128_SHA and TLS_ECDHE_ECDSA_WITH_RC4_128_SHA cipher suites down to be just ahead of the TLS_RSA_WITH_RC4_128_SHA cipher suite. 3. Fix bug 1124039: implement a whitelist of servers that require RC4, and disable RC4 by default except for those servers. 4. Close this bug RESOLVED INVALID.

I'll turn off all RC4 prefs at once. All four cipher suites are equally prohibited by RFC 7465.