Bug opened further to the discussion on the TLS Working Group regarding <https://tools.ietf.org/html/draft-popov-tls-prohibiting-rc4-02> - which specifically recommends that, in light of what we now know, RC4 MUST NOT be accepted, offered, allowed or negotiated under any circumstances - and the strong consensus in the resulting discussion to adopt the draft, and the previous marking of RESOLVED WONTFIX on bug 770368 [from 2012] regarding the disabling of RC4. Since that bug, the landscape has changed. In March 2013, RC4 was further weakened, and later that year, of course, the threat posed by nation state adversaries was brought into sharper focus by the Snowden disclosures - some of which mention a 'cryptologic breakthrough' with wide applicability, which is thought by some (including Bruce Schneier) as a likely possible reference (amongst some other possibilities) to a weakness or full break in RC4. There is now clear consensus in the community that, in light of the weaknesses now known, and concern about further expected weaknesses, the use of RC4 in SSL/TLS (or any other context) is no longer considered sufficiently secure. There are indications by those with access to the Snowden data that some adversaries are likely already able to break RC4 - <https://www.ietf.org/mail-archive/web/tls/current/msg12219.html> - and may have been for some time. And of course, any break in RC4 will be retroactively applicable to data collected now. I'm mindful of wtc's comments in the historical discussion from 2012 in bug 770368 that some sites still used RC4 in preference to other ciphers a couple of years ago, particularly in light of advice given for BEAST. (CCed to him for his comments.) To some extent, that is unfortunately still the case (as discussed on the TLS WG) - it is still a prevalent cipher, and that prevalence is part of the problem. That needs to be considered. Nevertheless, the draft's recommendations are pretty clear: the window to deprecate gently has long passed, and at this point, with what we know, all continued use of RC4 must cease as soon as possible. (The only real issue is how 'soon' is 'possible'.) Notably, NSS now supports TLS v1.2 and the AES_128_GCM ciphersuites using ECDHE for perfect forward security, which are the leading ciphersuites being recommended by the UTA WG: sites affected by this change should switch to that ciphersuite forthwith. As per my messages in the working group <https://www.ietf.org/mail-archive/web/tls/current/msg12212.html> and <https://www.ietf.org/mail-archive/web/tls/current/msg12217.html>, as a transition mechanism due to the prevalence of a limited number of sites only willing to offer RC4 ciphersuites, it may be considered preferable to disable the use of RC4 but offer a fallback for a limited window of time with a visible warning to the user. If this route is taken, I strongly recommend that the user is warned (with a red interstitial warning, such as you might see if a site used a 512-bit RSA key!) that the site does not offer an appropriate level of cryptographic security, with text such as the following (feel free to use it or anything similar if you wish): ! The site uses insecure ciphers! You attempted to reach %s but the server only offered to use an insecure cipher, RC4. [RFCabcd, 2014] specifically warns that the RC4 cipher MUST NOT be used anymore, because it is dangerously weak. You should not proceed. If you proceed, an attacker could capture data that you send and read it in the future, including passwords and credit card numbers. Similar warnings/changes would be warranted in other affected applications, such as Thunderbird. As obviously the continued usage of a known weak cipher in SSL/TLS has a security impact, I've asked the security team to review this bug and provide input. Thanks.

I will not then be able to use my internet-enabled credit card that is 3DSecure protected since the sms check server uses strictly RC4 only (I already tried to disable RC4 by prefs). This is only one example, but there could be more. Having a like-cert-error page to add an exception might be good.

(In reply to Honza Bambas (:mayhemer) from comment #1) > This is only one example, but there could be more. I don't doubt that there will be hundreds. Hence my opening this bug a little early so there's time to consider the appropriate response from browser vendors. For examples of other industry stakeholders, I intend to point those who evaluate PCI/DSS security standards to the publication of the RFC (when it is finalised) as representing consensus on best industry security practice. One of the few things that would push sites like the one you indicated (and hundreds, possibly thousands of sites like it) to update is losing their PCI compliance. A warning from browsers couldn't hurt either, and given the risks, I think users need to be informed too. > Having a like-cert-error page to add an exception might be good. I'm guarded about that idea: exceptions are sticky, and risk being forgotten about. Although, I appreciate given the spread of RC4, the Mozilla community will need to discuss the appropriate response in detail. Continuing to use a weak cipher after you know it's weak is attackable by undetectable, globally pervasive, passive attackers, in retrospect, from captured traffic (and today's nation-state adversary is next year's coffeeshop WiFi). So I'd say it's higher-risk than self-signed certificates or any active attack.

According to MS folks, 3.90% of sites can not negotiate ciphers other than RC4. http://blogs.msdn.com/b/ie/archive/2013/11/12/ie11-automatically-makes-over-40-of-the-web-more-secure-while-making-sure-sites-continue-to-work.aspx At least we could stop offering RC4 for TLS1.1+ as IE11 already does.

(In reply to Masatoshi Kimura [:emk] from comment #3) > According to MS folks, 3.90% of sites can not negotiate ciphers other than RC4. Yes, there are a lot of insecure sites users need to be warned about. > At least we could stop offering RC4 for TLS1.1+ as IE11 already does. In the absence of a downgrade protection for TLS, that is somewhat dangerous. Unfortunately, it is a little on the late side for that. Consider removing the lock icon?

(In reply to Masatoshi Kimura [:emk] from comment #3) > 3.90% Reported numbers vary: 1.56% in the top one million websites <https://jve.linuxwall.info/blog/index.php?post/TLS_Survey>. Still not a low number.

(In reply to Alyssa Rowan from comment #4) > In the absence of a downgrade protection for TLS, that is somewhat > dangerous. Unfortunately, it is a little on the late side for that. Consider > removing the lock icon? Yeah, we should remove the padlock icon to avoid giving users a false sense of security.

Any progress on this? It's been three months :)

I dont think we can remove RC4 yet. From telemetry of Beta 31 (top cipher suites): Cipher Suite %of connections RSA_AES_128_CBC_SHA 38.6 ECDHE_RSA_AES_128_GCM_SHA_256 20.7 ECDHE_ECDSA_AES_128_GCM_SHA_256 14.64 RSA_RC4_SHA 12.11 DHE_RSA_AES_128_CBC_SHA 4.4 RSA_RC4_MD5 3.2 So at least 15.31% of all connections use some form of RC4... maybe we should try disabling rsa_rc4_128_MD5 first

See comment #3. Many of those sites will use a cipher suite other than RC4 if we don't offer RC4.

(In reply to Masatoshi Kimura [:emk] from comment #9) > See comment #3. Many of those sites will use a cipher suite other than RC4 > if we don't offer RC4. Prime example: https://www.ssllabs.com/ssltest/analyze.html?d=r4---sn-qu5b-q0nl.googlevideo.com YouTube ends up negotiating RC4 for video most of the time (as apposed to the site itself). The only browser that gets the good cipher is IE11 on Win 8.1. (In reply to Masatoshi Kimura [:emk] from comment #3) > At least we could stop offering RC4 for TLS1.1+ as IE11 already does. Yes please. I'd expand that to all weak ciphers and include 3des too. Would be best to have a pref named security.ssl.forbid_old_ciphers_with_new_tls or something. After this mode hits beta we could get more useful telemetry on who many connections actually require RC4, rather than just prefer and use it currently.

Small Update: The IETF TLS Working Group have now adopted Andrei's "Prohibiting RC4 Cipher Suites" draft as a TLS work item: with the strong consensus already achieved, once the ciphersuite ID numbers are added into Appendix A it is likely to progress via Last Call to a full RFC, I believe? <https://datatracker.ietf.org/doc/draft-ietf-tls-prohibiting-rc4/> As for RC4 on the YouTube video CDN backend, you should probably speak to agl at Google or the relevant people at YouTube about that. They're likely intending to phase it out in favour of the final ChaCha20-Poly1305 AEAD when finished, I'd guess. I should also make you aware that I understand that another new cryptanalytic result regarding RC4 may be in the pipeline. I don't yet know how effective the new attack will be, or really any details about it - except that it seems to require a fairly practical amount of computation, so please take this as fair warning! (Remember: results in the future may affect connections made now, or in the past!) In particular, it is too late to just gently phase out RC4. That really should have been done years ago. At this point, the strong recommendation of the draft RFC is agreeing to use it in any form is now considered harmful and it is time (perhaps overdue) to flip the switch to start warning that it is insecure and refuse to use it. You should be aware of the risks of continuing to agree to use it, so I would caution against being guided too much by telemetry on its adoption - this is an issue affecting your users' security. (I do however understand - and sympathise with - the release-engineering effect of users tending to blame the last thing that upgraded as being what 'broke' things, e.g. an end-user may tend to take away the general message that "the new Firefox won't connect to my bank: what's wrong with Firefox?" rather than the more correct "the new Firefox warns me my bank is using old broken crypto and refuses to connect: what's wrong with my bank?". So I will bow to your judgment on that one, but want to make the concern clear.) While I do applaud MS for making the first move, and an encouraging first step - please be wary of the risk of continuing to use RC4 on <=TLS 1.0 particularly where a "downgrade" attack may be possible, as the "downgrade SCSV" draft is not yet supported very many places (including by Mozilla) so there is little defence against that. That behaviour would in particular NOT be compliant with the advice in this draft RFC: that RC4 is no longer secure for use in *any version* of TLS (and indeed, it is not generally thought to be secure enough for any use whatsoever now). Regarding other ciphers, this draft RFC is specific to a warning about RC4 in particular. I don't know Mozilla's release engineering process very well, but I would advise it may be prudent to prioritise this particular warning as a higher-risk item, and deal with issues with a potentially wider scope and impact (other ciphersuites) at a lower priority. For example, although it clearly is weaker than AES, and has abysmal performance, in particular I do not think 3DES is as weak as RC4 at this time and while I would not encourage its use overall (except possibly as a last-ditch fallback where the disadvantages are understood and the alternative would be plaintext?), shifting away from it therefore is not as urgent. Thanks very much.

(confirming this bug on the basis that this will likely need to be done in some form eventually, as indicated by the pending RFC) See also bug 1042811. SSL3 is also possibly on the chopping block. (not directly related, but also applicable to the same general topic of dropping support for old known bad protocols)

Finally! Google added some more secure cipher suites to *.googlevideo.com: https://www.ssllabs.com/ssltest/analyze.html?d=r4---sn-qu5b-q0nl.googlevideo.com

See bug 1076983, where SSL 3.0 was disabled. Many RC4-only websites are using SSL 3.0. (In reply to Alyssa Rowan from comment #0) > As per my messages in the working group > <https://www.ietf.org/mail-archive/web/tls/current/msg12212.html> and > <https://www.ietf.org/mail-archive/web/tls/current/msg12217.html>, as a > transition mechanism due to the prevalence of a limited number of sites only > willing to offer RC4 ciphersuites, it may be considered preferable to > disable the use of RC4 but offer a fallback for a limited window of time > with a visible warning to the user. If this route is taken, I strongly > recommend that the user is warned (with a red interstitial warning, such as > you might see if a site used a 512-bit RSA key!) that the site does not > offer an appropriate level of cryptographic security, with text such as the > following (feel free to use it or anything similar if you wish): Please see bug 1088915 and bug 1093595, which implement a variant of your suggestions. Since that change landed, the percentage of connections that use RC4 dropped from ~28% to ~1% in Firefox Nightly 36. > Similar warnings/changes would be warranted in other affected applications, > such as Thunderbird. I recommend filing a separate bug for Thunderbird, because Thunderbird's UI is (almost) totally separate from Firefox's. See also bug 1084025, where Masatoshi is working on disabling the non-secure fallback logic completely. If that is successful, there will be even fewer connections negotiating RC4.

SSL Labs marks RC4 as weak https://www.ssllabs.com/ssltest/viewClient.html?name=Firefox&version=34&platform=OS%20X Camilo, are there already some representative data since bug 1088915 has landed? I think it's at least safe to disable both ECDHE-RC4 ciphers now.

(In reply to Camilo Viecco (:cviecco) from comment #8) > maybe we should try disabling rsa_rc4_128_MD5 first See bug 1114809.

Recently two new attacks against RC4 have been announced. Perhaps it's time to speed closing this bug up.

acs.sia.eu, which is the 3DSecure payment card sms code portal is only working with security.ssl3.rsa_rc4_128_sha enabled. If disabled, people won't be able to confirm sms codes for secured payment/credit cards, there will be no cipher overlap. I'm in process of contacting the server owner now, let's see.

https://code.google.com/p/chromium/issues/detail?id=375342#c17 has interesting information. Maybe this is the reason acs.sia.eu (and some other payment cards sites) persist only RC4.

(In reply to Masatoshi Kimura [:emk] from comment #20) > https://code.google.com/p/chromium/issues/detail?id=375342#c17 has > interesting information. Maybe this is the reason acs.sia.eu (and some other > payment cards sites) persist only RC4. BEAST is mitigated in TLS 1.1+ and modern clients. So TLS 1.0 is weak an SSL 2 and 3 are broken anyway. Modern clients and server have to prefer TLS 1.2 with GCM ciphers (or newer ones). If a server still supports weak stuff, Firefox is not affected, because we use secure alternatives. We only have a problem with servers, that support only old stuff. But they are vulnerable anyway, because RC4 and SSL is worse than TLS and CBC. IMHO security goes over compatibility and there are few servers that still requires RC4.

(In reply to sjw from comment #21) > (In reply to Masatoshi Kimura [:emk] from comment #20) > > https://code.google.com/p/chromium/issues/detail?id=375342#c17 has > > interesting information. Maybe this is the reason acs.sia.eu (and some other > > payment cards sites) persist only RC4. > > BEAST is mitigated in TLS 1.1+ and modern clients. So TLS 1.0 is weak an SSL > 2 and 3 are broken anyway. > Modern clients and server have to prefer TLS 1.2 with GCM ciphers (or newer > ones). If a server still supports weak stuff, Firefox is not affected, > because we use secure alternatives. We only have a problem with servers, > that support only old stuff. But they are vulnerable anyway, because RC4 and > SSL is worse than TLS and CBC. IMHO security goes over compatibility and > there are few servers that still requires RC4. I know. Please persuade NIST, not me.

(In reply to Masatoshi Kimura [:emk] from comment #22) > I know. Please persuade NIST, not me. The RFC is in the final stages of publication, and makes clear all by itself that RC4 is *NOT* considered to be strong cryptography in 2015 and MUST NOT be used in TLS - period. (Attacks against it just got even worse, actually, but it's a little late in the process to start adding new references, no-one wants more delay.) The appropriate response for every PCI-compliant site is to do what the PCI-DSS standard demands them to - use *strong* cryptography, i.e. not RC4. The appropriate way to do that with TLS is TLS 1.2 with AES-(128|256)-GCM, or perhaps (draft) CHACHA20-POLY1305 (the UTA WG's BCP is in draft at the moment, I believe). I would *hope* that any competent PCI compliance auditor issue an easy automatic fail for any RC4 usage with an RC4-die-die-die RFC in the wild, but bearing in mind not every auditor in the world is necessarily on the ball, it may indeed be worth speaking to NVD also to adjust CVE-2013-2566's impact score to a more appropriate level - it indeed is worse than BEAST (as was discussed on the TLS WG list)? The appropriate response for any browser, I contend, is to refuse to trust your bank details to weak crypto! (Or at least put the big fat red warning on it that it deserves if you really must, behind the fallback SCSV, if you're even keeping the fallback dance?)

I filled bug 1123932 for ECDHE-RC4 only.

As emk notes above, RFC7465 has now been formally published, and represents the near-unanimous consensus of the IETF TLS Working Group. For reference: o TLS clients MUST NOT include RC4 cipher suites in the ClientHello message. o TLS servers MUST NOT select an RC4 cipher suite when a TLS client sends such a cipher suite in the ClientHello message. o If the TLS client only offers RC4 cipher suites, the TLS server MUST terminate the handshake. The TLS server MAY send the insufficient_security fatal alert in this case. The MUST NOT language explicitly *does not* allow for whitelisting, or any remaining transition period (which really should have been in place for years already, oh well) - this was thoroughly discussed in the Working Group and is intentional. The gentle transition period is officially over - it's now a matter of security and RFC-compliance to disable RC4 *completely*, now. Any sites or software that rely on it or accept its use are now insecure and urgently need to change their practices. I look forward - hopefully, not very far - to Mozilla software becoming compliant.

(In reply to Alyssa Rowan from comment #25) > As emk notes above, RFC7465 has now been formally published, and represents > the near-unanimous consensus of the IETF TLS Working Group. For reference: > > o TLS clients MUST NOT include RC4 cipher suites in the ClientHello > message. > > o TLS servers MUST NOT select an RC4 cipher suite when a TLS client > sends such a cipher suite in the ClientHello message. > > o If the TLS client only offers RC4 cipher suites, the TLS server > MUST terminate the handshake. The TLS server MAY send the > insufficient_security fatal alert in this case. > > The MUST NOT language explicitly *does not* allow for whitelisting, or any > remaining transition period (which really should have been in place for > years already, oh well) - this was thoroughly discussed in the Working Group > and is intentional. > > The gentle transition period is officially over - it's now a matter of > security and RFC-compliance to disable RC4 *completely*, now. Any sites or > software that rely on it or accept its use are now insecure and urgently > need to change their practices. > > I look forward - hopefully, not very far - to Mozilla software becoming > compliant. I strongly agree that a whitelist should not be used. Rather, I think it is better to announce, as soon as possible, a specific date after which RC4 will be completely disabled in Mozilla software. Those RC4-only websites should update their TLS configuration before that deadline. Two reasons: 1) RC4 is absolutely insecure. There will be a presentation in Black Hat 2015, titled "Breaking SSL with 13-Year Old RC4 Weakness". The abstract says "we will show how an old vulnerability of RC4 can be used to mount a partial plaintext recovery attack on SSL-protected data, when RC4 is the chosen cipher." [1] Black Hat 2015 takes place on March 26 & 27. So it's really important that RC4 is disabled completely before March 26. 2) It is easy for RC4-only websites to enable other cipher suites. As far as I know, no server software only supports RC4. Enabling AES is just a matter of changing the server's configuration files. This is even easier to fix than Heartbleed. Given that the majority of the websites fixed Heartbleed in less than one week, I think website operators have the ability to update their systems in a timely manner. So I guess that they support RC4 only, not because there are any technical difficulties, but because they are unaware of the issue or believe this issue is not important to fix. Breaking their websites will force webmasters to fix it, which is actually beneficial for users. [1] https://www.blackhat.com/asia-15/briefings.html#bar-mitzva-attack-breaking-ssl-with-13-year-old-rc4-weakness

Please provide an idea to stop users to switch to Chrome, please. I KNOW Mozilla violates RFC 7465 and I'm anxious to kill RC4 IF we don't lose users. > 2) It is easy for RC4-only websites to enable other cipher suites. Could you please work on bug 1124039 blockers (e.g. bug 1133496) to prove that? Apparently akr is writing a comment in that bug, but I don't know the progress thereafter.

(In reply to Masatoshi Kimura [:emk] from comment #27) > Please provide an idea to stop users to switch to Chrome, please. > I KNOW Mozilla violates RFC 7465 and I'm anxious to kill RC4 IF we don't > lose users. The whole point of an IETF RFC is to force coordination in a world where vendors don't talk to each other about important things like this. Someone needs to get into direct touch with someone on the Google Chrome/Chromium team and find out what they're doing and when. If they're going to be responsible here, it's easy for Mozilla to do so at the same time. (preferably on the same day; this can easily be done in Firefox via the hotfix extension) https://code.google.com/p/chromium/issues/detail?id=375342

The obvious solution for this issue is to coordinate disabling RC4 with Google, but see https://code.google.com/p/chromium/issues/detail?id=375342#c30 for why Google hesitates. It would be great if Mozilla could work with Google to address this issue.

(In reply to Dave Garrett from comment #28) > The whole point of an IETF RFC is to force coordination in a world where > vendors don't talk to each other about important things like this. Someone > needs to get into direct touch with someone on the Google Chrome/Chromium > team and find out what they're doing and when. If they're going to be > responsible here, it's easy for Mozilla to do so at the same time. > (preferably on the same day; this can easily be done in Firefox via the > hotfix extension) I think it does not have to be exactly the same day. We have cooperated in the past at least twice (one for implementing 1/(n-1) splitting to mitigate BEAST, one for disabling SSLv3 to prevent POODLE).

(In reply to Masatoshi Kimura [:emk] from comment #30) > (In reply to Dave Garrett from comment #28) > > (preferably on the same day; this can easily be done in Firefox via the > > hotfix extension) > > I think it does not have to be exactly the same day. Of course it doesn't have to be exactly on the same day, but it would be the ideal solution. In this case it is trivial for Mozilla to roll out whenever, so it's very easy to coordinate precisely to reduce user confusion.

Here is the kill switch, by the way. I hope cooperation with Google and/or Black Hat 2015 will make it possible to land this. https://treeherder.mozilla.org/#/jobs?repo=try&revision=3202d9a45449

(In reply to Masatoshi Kimura [:emk] from comment #32) > Created attachment 8566801 [details] [diff] [review] > Disable RC4 by default > > Here is the kill switch, by the way. > I hope cooperation with Google and/or Black Hat 2015 will make it possible > to land this. > > https://treeherder.mozilla.org/#/jobs?repo=try&revision=3202d9a45449 It seems that Google plans to deal with it no sooner than version 43.[1] The current stable version is 40. I think it is too late if we wait until Google releases Chrome 43. Ideally, RC4 should be completely turned off before Black Hat 2015. [1] https://code.google.com/p/chromium/issues/detail?id=375342#c19

Another thing I want is a way to detect servers require RC4 reliably. The current message is too generic for people to think the server is broken, not the browser. We should add a dedicated error page for RC4 like we had done for SSLv3.

(In reply to Masatoshi Kimura [:emk] from comment #34) > Another thing I want is a way to detect servers require RC4 reliably. The > current message is too generic for people to think the server is broken, not > the browser. We should add a dedicated error page for RC4 like we had done > for SSLv3. To reliably detect RC4-only, you need to make two connections to the servers: the first handshake does not include any RC4 cipher suites, and if it fails (i.e. receiving a handshake_failure alert message), initiate a second handshake, which contains some RC4 ciphers. If the second succeeds, that means the servers are RC4 only. Detecting SSLv3 does not require a second handshake because ServerHello.server_version indicates the server's highest supported TLS version, but the handshake_failure alert does not indicate the server's supported cipher suites.

(In reply to fn84b from comment #35) > To reliably detect RC4-only, you need to make two connections to the > servers: the first handshake does not include any RC4 cipher suites, and if > it fails (i.e. receiving a handshake_failure alert message), initiate a > second handshake, which contains some RC4 ciphers. If the second succeeds, > that means the servers are RC4 only. Detecting SSLv3 does not require a > second handshake because ServerHello.server_version indicates the server's > highest supported TLS version, but the handshake_failure alert does not > indicate the server's supported cipher suites. Thanks, Firefox is already doing two handshakes (bug 1088915). Maybe all we have to do is fail the second handshake and display an error page instead of continuing the connection with RC4.

In my opinion Firefox should simply drop RC4 support completely once the RFC is out to be fully compatible with the standard (it prohibites RC4 after all). Maybe the support could be left in for a few versions but be disabled by default (about:config) so that people have time to switch you shouldn't defend a dead standard and leave such a support in which disables the servers choices and such a workaround would slow down the connection and bring other problems (unnecessary effort)

Then how can we prevent users from switching to Chrome? I will not jump off a cliff just because an RFC is saying to do so. A Debian developer also considers that RFC 7465 is impractical. http://www.eenyhelp.com/answer/bug-778747-openssl-rfc-7465-says-rc4-broken-never-be-used-help-215587405.html?page=2

Firefox could lead as an example here. I bet people will like it if Firefox is one of the first to respect the good decision of the ietf. (Is Chrome/Chromium going to disable RC4 btw.?) If noone will do it then the switch will never happen. The effort to switch from rc4 to something different is pretty much zero (especially since most softwares support several encryption standards) and else you can stick to an older browser version (if you really really need to keep rc4 which is unlikely) Why do you think RC4 disabling is so bad? (I mean yeah there might be servers out there that support only rc4, but the server admins of such a server live in another world and since rc4 will be "removed" from the standard his server configuration wouldn't be conform to the standard anymore so he cannot expect clients to still support it) In either way you would only wake up people by following the choice of the ietf. I'm surfing with RC4 disabled since youtube's/google's video servers support rc4 completely (it was the only site that required rc4 and was widely used I think (the servers that provide the videos and not the page itself))

DreamHost is one of the web hosting services that only supports RC4. I posted a suggestion on its discussion forum.[1] But there is no reply so far, and it is still RC4-only.[2] [1] https://discussion.dreamhost.com/thread-145343.html [2] https://www.ssllabs.com/ssltest/analyze.html?d=whatwg.org

Have they changed it tonight? Because what I am seeing is ECDHE RSA with AES 128 GCM SHA256 and PFS is turned on, the certificate is encrypted well, too -> which is the best you can get atm. (at least on their main page, but their forum supports also something better than rc4) And you linked the wrong ssllabs test (whatwg.org, which is a completely different site and it supports other encryptions than RC4) this is the right test https://www.ssllabs.com/ssltest/analyze.html?d=dreamhost.com&latest So either dreamhost received your feedback or your report is wrong. (I visited the site with rc4 turned off though so it might be the case that they prefer rc4 over other encryptions, but I was able to visit the site at all, so no problems in general)

(In reply to Djfe from comment #41) > And you linked the wrong ssllabs test (whatwg.org, which is a completely > different site and it supports other encryptions than RC4) > this is the right test > https://www.ssllabs.com/ssltest/analyze.html?d=dreamhost.com&latest Oh, I didn't mean the website dreamhost.com was RC4-only. whatwg.org is hosted by DreamHost [1]. Its server hostname is ps20323.dreamhost.com. [1] https://annevankesteren.nl/2014/09/tls-dreamhost

When I visit ps20323.dreamhost.com with http (unencrypted) it says page not found and when I visit it with https Firefox says it doesn't trust the certificate (not correctly signed or something(probably the wrong url)) about whatwg.org: yeah it uses RC4 only If dreamhost doesn't reply to your requests even (maybe you should email their support instead), then dreamhost.org shouldn't wonder when customers are leaving them as a hosting service (hopefully they will wake up then...) (I won't support such services that don't reply and use insecure technology -> it's not that hard to be up to date for server admins)

Here is affected sites in the current whitelist (171 of 666).

(In reply to Masatoshi Kimura [:emk] from comment #44) > Created attachment 8567864 [details] > rc4fallback.txt > > Here is affected sites in the current whitelist (171 of 666). There are sites on that list that are not RC4 only. e.g. https://www.ssllabs.com/ssltest/analyze.html?d=store.virginmedia.com List needs a rescan already? Could be a good sign if sites are actually updating more quickly now.

(In reply to Dave Garrett from comment #45) > (In reply to Masatoshi Kimura [:emk] from comment #44) > > Created attachment 8567864 [details] > > rc4fallback.txt > > > > Here is affected sites in the current whitelist (171 of 666). > > There are sites on that list that are not RC4 only. e.g. > https://www.ssllabs.com/ssltest/analyze.html?d=store.virginmedia.com > > List needs a rescan already? Could be a good sign if sites are actually > updating more quickly now. The attached text does not contain store.virginmedia.com, only allyours.virginmedia.com and identity.virginmedia.com. Where did it come from? Sometimes subdomains have inconsistent state each other. For example, see bug 1084025 comment #114. Another example is dom.spec.whatwg.org, which does not require (and even disallow) RC4.

(In reply to Masatoshi Kimura [:emk] from comment #46) > The attached text does not contain store.virginmedia.com, only > allyours.virginmedia.com and identity.virginmedia.com. Where did it come > from? > Sometimes subdomains have inconsistent state each other. For example, see > bug 1084025 comment #114. Another example is dom.spec.whatwg.org, which does > not require (and even disallow) RC4. Ah, I see what happened. I tested allyours.virginmedia.com (near the top) which redirects to store.virginmedia.com. I just tested that current domain, and it supports better than RC4. This is odd, because that domain doesn't seem to want to connect with HTTPS. The redirect to store.virginmedia.com works with HTTP, but not HTTPS. Sorry, their configuration is messy and I mixed them up; this list appears to be correct here.

There's also from Virgin that needs to be added: national.virginmedia.com https://www.ssllabs.com/ssltest/analyze.html?d=national.virginmedia.com&latest RC4-only, TLS 1.2 intolerant payments.virginmedia.com https://www.ssllabs.com/ssltest/analyze.html?d=payments.virginmedia.com&latest RC4-only, TLS 1.2 intolerant ebill2.virginmedia.com https://www.ssllabs.com/ssltest/analyze.html?d=ebill2.virginmedia.com&latest RC4-only, TLS 1.2 intolerant

secure3.i-doxs.net needs security.tls.unrestricted_rc4_fallback to connect on nightly.

(In reply to Patrick McManus [:mcmanus] from comment #49) > secure3.i-doxs.net needs security.tls.unrestricted_rc4_fallback to connect > on nightly. I filed Bug 1140876.

Just by way of update: RC4 being enabled is now (as it should be) an instant-fail of a PCI compliance test. That should get things moving. :-)

There's a new attack on RC4 in TLS that yields password recovery with only 2^26 ciphertext, PoC included: http://www.isg.rhul.ac.uk/tls/RC4mustdie.html This needs bumping up the agenda.

This is too early to ship with 38. The whitelist is way too big and still growing, there are some important website still being affected (bug 1138101) and not whitelisted. I would like to postpone this change to 39 (or 40) and make a coordinated move with other vendors. 38 is going to be a major release of Firefox and we don't want to ship a release breaking a bunch of website when Chrome is still supporting it. Masatoshi, could you prepare a patch to revert this change (before next monday merge)? thanks

Sylvestre, might it be better to implement an interstitial as a stopgap measure for Firefox 39 before disabling the cipher completely in a later version?

(In reply to Nick Lowe from comment #54) > Sylvestre, might it be better to implement an interstitial as a stopgap > measure for Firefox 39 before disabling the cipher completely in a later > version? If there is a way to mitigate the various websites not available with 38, sure, why not. But this would have to land by Next monday. So, for now, I would like to revert this change and see later about your proposal.

(In reply to Sylvestre Ledru [:sylvestre] from comment #53) > This is too early to ship with 38. > The whitelist is way too big and still growing, there are some important > website still being affected (bug 1138101) and not whitelisted. I would like > to postpone this change to 39 (or 40) and make a coordinated move with other > vendors. > 38 is going to be a major release of Firefox and we don't want to ship a > release breaking a bunch of website when Chrome is still supporting it. > > Masatoshi, could you prepare a patch to revert this change (before next > monday merge)? thanks It is already postponed to 39. Bug 1138882 was uplifted with the pref enabled by default on aurora (38).

What about using an alert that makes users aware of the problem: It tells you that the website is using a by now deprecated and insecure encryption technology and asks whether you want to proceed to the website. and maybe something that at least makes users aware that they shouldn't proceed if the website is something important as your bank or so, but that it doesn't matter as much for normal websites. -> we need to get the admins aware of the problem after all and complaining users are the best way something like a whitelist would just let RC4 live longer :/ (which is definitely not our aim (I guess everybody agrees on that))

I forgot to add that a whitelist is a good idea for a later phase (FF 38), but right now(FF 36/37), we should at least warn users to not trust this encryption for example in your starbucks or something.

Filed bug 1145261 to add a warning UI.

Masatoshi, thanks! :)

(In reply to Alyssa Rowan from comment #51) > Just by way of update: RC4 being enabled is now (as it should be) an > instant-fail of a PCI compliance test. > > That should get things moving. :-) This appears to have been the main thing that was holding up Google's decision making process. They are likely to be far more receptive to axing RC4 entirely now, or at least beginning a phase out. https://code.google.com/p/chromium/issues/detail?id=375342#c44 Some people with decision making power in Mozilla & Google really need to have a chat and come up with a joint game-plan.

For what it's worth, there is actually progress in getting servers upgraded to modern ciphers. Bluehost/HostMonster just fixed their RC4 dependency today (bug 1143254), affecting quite a few sites (including 4 we were tracking). Of what we're currently tracking in TE bugs, about 26% have fixed their RC4 dependence. (bug 1138101)

I rechecked an RC4-only server list from bug 1124039 comment 58. 779 of 2696 (28.9%) hosts are fixed. So 26% is not so bad approximation.

It's good to hear there is positive progress. I also agree we should reach out to Google. Release Note Request (optional, but appreciated) [Why is this notable]: This is a change that many users will notice. [Suggested wording]: Disabled use of RC4 completely [Links (documentation, blog post, etc)]: We should definitely document this. Once there is dev documentation, please needinfo or email me so I can update the release notes.

"Disabled use of RC4 completely" is misleading, unless you've decided to remove the whitelist (which I would strongly support).

David or Richard, are you ok with this moving up to aurora? Do you expect we will keep RC4 completely disabled when 39 releases in late June? Would either of you be the right people to reach out to teams working on other browsers?

Comment #65 is right. Tracking flags should move to bug 1124039.

I get that we're still whitelisting. Maybe it's better to relnote from bug 1124039, then. Or, we could remove the word "completely" from the existing note.

This is on hold until the rate of RC4 usage tails off some more. Right now, release telemetry shows it being used for ~0.12% of connections, down from ~0.18% at the beginning of April. At that rate, we should be able to look at disabling in a couple months.

I'm going to guess that the usage rate decrease will tail off until some browser (likely Firefox or Chrome) takes a stand to actually throw up a warning page as being discussed in 1145261 and 1158169. Until then, it's a completely invisible failure for many sites.

From email discussion, here is the current state of RC4 in 39 beta. The state right now is the state that will remain until RC4 usage becomes truly negligible: * Release and Beta connect just fine ** Shows warning triangle and "crypto too weak" text ** Shows dev console warning * Aurora and Nightly return ssl_error_no_cypher_overlap

The release notes don't reflect that.

Somehow the site compat note was still on the Firefox 38 page; I have just moved it to 39: https://developer.mozilla.org/en-US/Firefox/Releases/39/Site_Compatibility#Security I'm monitoring Firefox Input and several sources. The ECDHE-RC4 suites seem mostly affected: https://input.mozilla.org/en-GB/?q=ssl_error_weak_server_ephemeral_dh_key&product=Firefox&version=39.0

Even 39 still defaults security.tls.unrestricted_rc4_fallback to true.

(In reply to Kohei Yoshino [:kohei] from comment #73) > I'm monitoring Firefox Input and several sources. The ECDHE-RC4 suites seem > mostly affected: > > https://input.mozilla.org/en-GB/ > ?q=ssl_error_weak_server_ephemeral_dh_key&product=Firefox&version=39.0 Sorry, I was confused. This was due to Bug 1138554.

(In reply to Kohei Yoshino [:kohei] from comment #73) > Somehow the site compat note was still on the Firefox 38 page; I have just > moved it to 39: > > https://developer.mozilla.org/en-US/Firefox/Releases/39/ > Site_Compatibility#Security Thanks, although this isn't exactly accurate either... Post Bug 1153964, whether or not "security.tls.unrestricted_rc4_fallback" is set to false (i.e. RC4 fallback occurs only on whitelisted sites) depends on the channel, and not the exact version. As mentioned in comment 74, the pref is not set to false on the release channel version of Firefox 39. I guess you could keep bumping the relnote up a version every release cycle, just remove the note until there's been a decision to target a particular version for disabling RC4 entirely, or something else you feel is appropriate.

Resetting the relnote flag as Tim Taubert and David Keeler requested that it be removed from FF39 notes. As of now, RC4 has not been disabled for FF39 and 40.

Removed this from the 39 site compat doc.

I am assuming others have seen: https://www.rc4nomore.com/ https://www.rc4nomore.com/vanhoef-usenix2015.pdf Because of this, I think it is now time to get fallback removed on a more expedited basis. The trade off, in my opinion, no longer favours allowing RC4 to be negotiated.

I can't understand why it's still marked as "wontfix" for FF 39 and 40, with RC4 allowing secure cookies to be decoded within single days. It's not secure cipher, and it shouldn't be negotiated anymore.

http://www.oracle.com/technetwork/java/javase/8u51-relnotes-2587590.html > RC4 is now considered as a compromised cipher. RC4 cipher suites have > been removed from both client and server default enabled cipher suite > list in Oracle JSSE implementation.

@Michal it's only allowed for white-listed sites: which basically means RC4 is still preferred over http (unencrypted connections) and over not being able to connect to a page at all just wait and see, it will take it's time (a few months) and then RC4 is history (for most clients/servers anyways), you cannot force everyone that easily, that's how it is, accept it :/ all webpages that allow other encryptions (than RC4) aren't on that white-list so your connection to those servers cannot be hacked by downgrading to RC4 -> you don't need to worry

what I forgot: what you and everybody else could do to improve the situation take the initiative and write a mail to the owners of all white-listed sites and tell them how dangerous rc4 is if that doesn't work or they don't reply then you know the reason why RC4 is still implemented as a fall-back if that works then everybody here will be in your debt ^^

(In reply to Djfe from comment #82) > @Michal it's only allowed for white-listed sites: which basically means RC4 > is still preferred over http (unencrypted connections) and over not being > able to connect to a page at all Not true. The whitelist is still disabled in beta and release. We currently have unrestricted fallback to RC4. See bug 1153964.

Google, Microsoft and Mozilla will drop RC4 support: https://blogs.windows.com/msedgedev/2015/09/01/ending-support-for-the-rc4-cipher-in-microsoft-edge-and-internet-explorer-11/

https://blog.mozilla.org/security/2015/09/11/deprecating-the-rc4-cipher/ Gerv

As of a little while ago, this has been fixed by making RC4 fallback-only, then turning off fallback by default.

So that we have this in the history: RC4 was progressively disabled through a series of limitations on its use, starting in 2014. Bug 1088915 - Stop offering RC4 in the first handshakes This bug removed RC4 from the first handshake, so that RC4 would only be offered in a second "fallback" handshake if the first one failed. Bug 1114816 - Add a whitelist for domains that require non-secure TLS version fallback Bug 1201024 - Disable unrestricted RC4 fallback These bug restricted the fallback so that it would only be done for hosts on a static, compiled-in whitelist, or on a user-defined list of hosts (empty by default). For all other hosts, RC4 is not offered. Bug 1215796 - Cleanup some non-secure fallback options This bug removed the static, compiled-in whitelist. Hosts on the user-defined list are still offered RC4, but this list is empty by default. So the default behavior is that RC4 is not offered to any site.

Release Note Request (optional, but appreciated) [Why is this notable]: Some sites running on unpatched older servers may not be visible to users. [Suggested wording]: RC4 fallback is disabled [Links (documentation, blog post, etc)]: https://blog.mozilla.org/security/2015/09/11/deprecating-the-rc4-cipher/

Richard: if I understand comment 88 correctly, there is no specific things to document here (I should remove the dev-doc-needed), but I should add dev-doc-needed to bug 1215796 and indicates the removal of static, compiled-in whitelist in Fx 44 for devs. Am I correct?

Wouldn't be the next step here to disable and remove all security.ssl3.*_rc4_* prefs?

Jean-Yves: I'm honestly not sure we need any new documentation here at all. Unlike many changes we make, we know *exactly* who this is going to affect -- the 1058 sites in the static whitelist. That seems like a smaller developer population than we usually worry about :) If anything, we should just be pointing people to the existing server-side documentation (https://wiki.mozilla.org/Security/Server_Side_TLS). sjw: Removing the various prefs that control this (including the fallback prefs) would be a next step, but I don't think that's really necessary or advisable for a little while.

(In reply to Richard Barnes [:rbarnes] from comment #92) > Unlike many changes we make, we know *exactly* who this is going to affect > -- the 1058 sites in the static whitelist. Not quite so. Bug 1207257 reverted bug 1201024, so the static whitelist has never had an effect in the Release channel (unrestricted fallback is enabled by default until 43, then it will be disabled with the empty whitelist by default since 44).

Any updates here? We are about to release 46 and I came across this again while gathering up release notes. For thinking about 47 or 48, how many sites are still affected these days?

RC4 usage continues to drop: https://ipv.sx/telemetry/general-v2.html?channels=release&measure=SSL_SYMMETRIC_CIPHER_FULL&target=1 The remaining sites that require RC4 are likely to be internal sites, and we don't have great visibility on those. The good news is stable Chrome has also disabled RC4 with no option to override the error (as far as I can tell).

RC4 is already disabled since Firefox 44. Removing the obsolete relnote flag.