Assuming such sites are rare enough. Probably we can share the same pref as bug 1114816. Broken servers tend to have other weakness either.

No, this is more dangerous, because it's vulnerable to passive crypt attacks. The (upcoming) RFC doesn't have a SHOULD NOT, it has a MUST NOT. Any whitelist for RC4 usage should present a loud, red, warning interstitial until the whitelist is phased out completely, preferably in less than a year.

If all browser vendors will turn off RC4 at once, I'll gladly just disable RC4. Otherwise users will just switch other browsers.

(In reply to Alyssa Rowan from comment #1) > Any whitelist for RC4 usage should present a loud, red, warning interstitial And the problem is that we have no way to reliably determine if the server requires RC4 without completing the handshake. Filed bug 1124157 for this issue.

This patch will change the fallback order to TLS1.2-RC4,TLS1.1-RC4,TLS1.0+RC4. This change will automatically whitelist RC4. If sites require RC4 and TLS_FALLBACK_SCSV such as former YouTube video servers, we can no longer connect those sites. But I don't think we need to workaround those sites anymore. Note: I read and know that draft-ietf-tls-prohibiting-rc4-01 explicitly saying that it applies to all TLS versions. You don't have to remind me.

It seems that the focus of this bug has changed to only enabling RC4 cipher-suites if Firefox is attempting a handshake for <= TLS 1.0 (rather than whitelisting based on domains). If that's the case, let's change the summary.

Comment on attachment 8556826 [details] [diff] [review] Enable RC4 only if ClientHelloVersion <= TLS 1.0 Review of attachment 8556826 [details] [diff] [review]: ----------------------------------------------------------------- Looks like this patch relies on another patch as well. I need an indication of what patches rely on others in order to review them effectively.

(In reply to David Keeler [:keeler] (use needinfo?) from comment #5) > It seems that the focus of this bug has changed to only enabling RC4 > cipher-suites if Firefox is attempting a handshake for <= TLS 1.0 (rather > than whitelisting based on domains). If that's the case, let's change the > summary. Sure. (In reply to David Keeler [:keeler] (use needinfo?) from comment #6) > Looks like this patch relies on another patch as well. I need an indication > of what patches rely on others in order to review them effectively. Bug 1116891 and bug 1128763 was first applied in my patch queue. I'll request review again after those bugs.

Comment on attachment 8556826 [details] [diff] [review] Enable RC4 only if ClientHelloVersion <= TLS 1.0 Requesting review again.

Comment on attachment 8556826 [details] [diff] [review] Enable RC4 only if ClientHelloVersion <= TLS 1.0 Review of attachment 8556826 [details] [diff] [review]: ----------------------------------------------------------------- If the desired fallback is TLS 1.2 (no RC4) -> TLS1.1 (no RC4) -> TLS1.0 (RC4), I think we could simplify this code and just say if we're going to use TLS1.0, enable weak ciphersuites (and get rid of the code to track strongCipherStatus). In particular, it doesn't seem possible to reach a point where strongCiphersStatus is StrongCiphersWorked but we're still falling back to TLS1.0 (but perhaps I'm misunderstanding this patch). How does that sound?

If the server is TLS intolerant and supports RC4 but does not prefer RC4, rememberTolerantAtVersion will be called from HandshakeCallback and strongCiphersStatus will be set to StrongCiphersWorked. But yes, we don't have to hide RC4 afterwards because server did not prefer RC4. Unlike insecure fallbacks, this choice is reliable and MiTM should not be able to trick the server to connect with RC4.

Just to make sure we're on the same page, strongCiphersStatus will be set to StrongCiphersWorked only after we've negotiated a TLS1.0 handshake where we've advertised RC4 ciphersuites but the server hasn't selected one, right? If that's the case, then I don't see the benefit in keeping around the mechanism that keeps track of strongCiphersStatus (unless removing it would make uplifts difficult for this or related bugs). The fallback mechanism is complicated and a little hard to understand - simplifying it would be beneficial. If you agree, then please go ahead and make those changes. Otherwise, I'll finish reviewing this patch and we can revisit the decision later.

I'll remove the rememberStrongCipherFailed() call. I'll leave strongCiphersStatus itself atm to make the uplift easier. Although I'm not going to uplift this because it will cause even more compatibility issue, Bar-Mitzva Attack might force us to uplift the change.

File a followup bug 1130670 to track the removal of strongCipherStatus itself.

Comment on attachment 8556826 [details] [diff] [review] Enable RC4 only if ClientHelloVersion <= TLS 1.0 Review of attachment 8556826 [details] [diff] [review]: ----------------------------------------------------------------- Ok - I'll review the final patch when it's ready, then (otherwise this generally looks fine).

* Removed rememberStrongCiphersFailed and |strongCiphersStatus != StrongCiphersWorked| check. * I also removed the whitelist check for PR_CONNECT_RESET_ERROR. This should have no difference as long as "security.tls.fallback-limit" is set to 3 because RC4 is now hidden behind the TLS version fallback. But users (or hotfix addons) can disable the behavior from bug 1128763 globally in case too many sites are broken.

Comment on attachment 8560796 [details] [diff] [review] Enable RC4 only if ClientHelloVersion <= TLS 1.0, v2 Review of attachment 8560796 [details] [diff] [review]: ----------------------------------------------------------------- Great - r=me.

I'm very unhappy with this change since it's recommend to use everything else than RC4 (see also bug 1024430) and this prevent us from disabling RC4 completely (bug 999544, 1114809, 1123932).

(In reply to sjw from comment #21) > I'm very unhappy with this change since it's recommend to use everything > else than RC4 (see also bug 1024430) and this prevent us from disabling RC4 > completely (bug 999544, 1114809, 1123932). Sorry, I don't follow your logic. Why does it prevent us from disabling RC4 completely to recommend to use everything else than RC4? I also don't understand what linked bugs have to do with. If we want to disable RC4 completely, we could just flip "security.ssl3.*_rc4_*" prefs. Nothing in this bug prevent that.

To be clear, this patch will disable RC4 completely except only around 600 sites in the world. Of course it will not satisfy akr because this patch doesn't implement any warnings for those exceptions.

(In reply to Masatoshi Kimura [:emk] from comment #23) > Of course it will not satisfy akr because this patch doesn't implement any warnings for those exceptions. Of course. Which is the patch that's landing that does that? Because otherwise, this is a security release blocker: it whitelists 600 insecure sites to be marked as secure. But RC4 isn't less broken for any individual site.

Oh, from what I've read I thought that this patch support only (= require) RC4 for <= TLS 1.0. No longer accept RC4 on TLS > 1.0 is great.

Please do not play around with flags. Reverting this patch will make Firefox much more insecure because Firefox will fallback with RC4 everywhere again, even without FALLBACK_SCSV. I know you think we must disable RC4 completely without any exceptions and any other changes are unacceptable.

(In reply to Masatoshi Kimura [:emk] from comment #26) > I know you think we must disable RC4 completely without any exceptions and any other changes are unacceptable. With the greatest respect, it is *not* my individual opinion, but the *firm, nearly unanimous consensus of the IETF TLS Working Group*, that RC4 MUST NOT be negotiated or accepted, with no exceptions. (The RFC is about to be published. SSLv3 also has a die-die-die in process.) It is not that I think limiting fallback with whitelists is entirely unacceptable, at all, but it is insufficient on its own when that fallback is insecure. Without presenting a warning when negotiating an insecure ciphersuite, this patch effectively exempts sites on a list from the security provided by TLS and simply presents a green https: bar to users when they visit a set of around 600 *insecure* sites. That requires review from Mozilla Security, as it violates users' traditional security expectation that "green bar = safe" for those sites. At this point, a red bar + interstitial would seem appropriate to me, with removal of RC4 completely in maybe 6 months (as those sites will be approached). If it's to be rolled out with a security warning attached to it as well, great - where's that patch, so it can be tested?

BlackHat Asia 2015 is coming up soon anyway: https://www.blackhat.com/asia-15/briefings.html#bar-mitzva-attack-breaking-ssl-with-13-year-old-rc4-weakness Even then, I think it is better to set security.ssl3.rsa_rc4_128* to false by default

(In reply to Yuhong Bao from comment #28) > BlackHat Asia 2015 is coming up soon anyway: > https://www.blackhat.com/asia-15/briefings.html#bar-mitzva-attack-breaking- > ssl-with-13-year-old-rc4-weakness > Even then, I think it is better to set security.ssl3.rsa_rc4_128* to false > by default Please stop off-topic comments. Bug 999544 tracks that.

The point is that this bug combined with bug 1084025 will disable RC4 completely by default.

changeset: 228437:c731517a47e8 seems to have regressed something in Firefox Mobile/Android nightly. I can't get to www.popehat.com unless I back this out. I'm late to the story here, is this expected? [1] https://www.dropbox.com/s/mclp8sb73msedi1/bug1124039.png?dl=0

Re-open, unless you'd prefer a regression bug.

(In reply to Yuhong Bao from comment #30) > The point is that this bug combined with bug 1084025 will disable RC4 > completely by default. Except for whitelisted sites, as I already said in comment #23. I don't understand why everyone repeats what I already know.

I had to backout this because of bug 1133312 :( https://hg.mozilla.org/integration/mozilla-inbound/rev/ee830b93a552 Mark, this bug happened to be about to be backed out, but please do not change the bug status until the commit is actually backed out.

I'm not sure if you mean I shouldn't have reopened this before I knew you were backing out (in which case I apologize for the timing) or if you mean don't change it further, which I don't intend to.

I'll land this with the whitelist update (bug 1133187).

Hi Masatoshi, please feel free to set me as QA owner on any and all TLS-related bugs so that I can be aware of them. Thank you!

Comment on attachment 8565390 [details] [diff] [review] Allow RC4 only for whitelisted hosts Review of attachment 8565390 [details] [diff] [review]: ----------------------------------------------------------------- LGTM.

Thanks, landed: https://hg.mozilla.org/integration/mozilla-inbound/rev/ae9cc48ed726 Try run (along with other patches): https://treeherder.mozilla.org/#/jobs?repo=try&revision=476344889dbf

Where should I go to request the addition of a couple of sites to this whitelist? The online banking website for Banco do Brasil (one of the biggest banks in Brazil) is RC4-only. The hostnames I know of are www2.bancobrasil.com.br (main site) and www41.bb.com.br (auxiliary site). There's also cva.bb.com.br (homebroker), but even though Qualys says it's RC4-only, for some reason Firefox can connect to it using TLS_DHE_RSA_WITH_AES_128_CBC_SHA.

According to Qualys it does support other cipher suites now:https://www.ssllabs.com/ssltest/analyze.html?d=cva.bb.com.br(In reply to Cesar Eduardo Barros from comment #42) > Where should I go to request the addition of a couple of sites to this > whitelist? > > The online banking website for Banco do Brasil (one of the biggest banks in > Brazil) is RC4-only. The hostnames I know of are www2.bancobrasil.com.br > (main site) and www41.bb.com.br (auxiliary site). There's also cva.bb.com.br > (homebroker), but even though Qualys says it's RC4-only, for some reason > Firefox can connect to it using TLS_DHE_RSA_WITH_AES_128_CBC_SHA. Just tested it again using Qualys: https://www.ssllabs.com/ssltest/analyze.html?d=cva.bb.com.br Still uses 768-bit DHE.

(In reply to Cesar Eduardo Barros from comment #42) > Where should I go to request the addition of a couple of sites to this > whitelist? > > The online banking website for Banco do Brasil (one of the biggest banks in > Brazil) is RC4-only. The hostnames I know of are www2.bancobrasil.com.br > (main site) and www41.bb.com.br (auxiliary site). There's also cva.bb.com.br > (homebroker), but even though Qualys says it's RC4-only, for some reason > Firefox can connect to it using TLS_DHE_RSA_WITH_AES_128_CBC_SHA. Please file a bug under "Tech Evangelism" product / "Desktop" component and block this bug. I'll add the site to the whitelist if the site is not fixed until we ship this fix.

Matt, could you run a compatibility test like you did in bug 1084025? The step is: 1. Set "security.tls.version.fallback-limit" to 1 (because we will no longer fallback with RC4 if the fallback limit is 3). 2. Turn off all "security.ssl3.*_rc4_*" prefs (4 entries should be present). 3. Run the test. 4. Flip back "security.ssl3.*_rc4_*" prefs. 5. Run the test again and compare the result.

Yet another meta-bug created. The trinity of bad server tracking is now: RC4 Dependency -> bug 1138101 SSL3 Dependency -> bug 1085138 TLS Intolerance -> bug 1126620 This bug is FIXED. Please file new whitelisting bugs as blocking the relevant meta-bug. Once their numbers start to get large, it gets messy to keep TE bugs in the same dependency tree as the implementation related bugs and it avoids excess bugspam being sent to people who don't CC themselves on the meta-bug.

To clarify that RC4/SSL3/TLS intolerance are really bad, can we rename the whitelist to blacklist?

(In reply to sjw from comment #48) > To clarify that RC4/SSL3/TLS intolerance are really bad, can we rename the > whitelist to blacklist? It's just the terminology. The word doesn't change due to good/bad. It's a list of sites where something special (though bad) is allowed, not where something isn't done. Besides, this isn't really user-facing. https://en.wikipedia.org/wiki/Whitelist Feel free to call them the "Junk Server Whitelists" though.

I support a warning been show to the user, I would also support some kind of automated email sent to the webmaster email address as well, so they get bombarded with emails to update their cipher. This download site only works with RC4 and its annoying. https://mega.co.nz

Mega will be added to the whitelist soon (I even added a wildcard support to the whitelist machinery almost solely for Mega).

I am wondering if FF36 is now broken as I just noticed mega now loads even tho I blocked RC4. Also the cipherfox addon no longer displays the cipher for mega when it did on FF35. odd.

Looks like eu.static.mega.co.nz was fixed, but *.userstorage.mega.co.nz still depends on RC4.

you got a url I can test with without the *? as I want to test the block still works. thanks.

Written in bug 1133496 (this is off-topic here).

Matt, do you have any difficulty to run the compatibility test? Bug 1138101 blockers are constantly added. We definitely need a more comprehensive list of servers that depend on RC4.

Hi Masatoshi, sorry for the delay. I will run a compatibility test. I hope to have something early next week at the latest. Thank you for your patience.

This is a list of sites that appear to be broken when we disable RC4 for TLS <= 1.0 in Fx38. This was a run against the Pulse top SSL site list of approximately 211k sites. Please note that I have not manually confirmed all sites in this list. Some may be broken for other reasons, so assume a small margin of error. For this test, we break almost 2700 sites, or 1.28% breakage rate. I am happy to test this against the much larger Google CT list of 2.7 million sites, but please be advised that it may take another week to get full results there. However, I would assume a similar rate of broken sites. Let me know if I should proceed with that test.

To add to the above: If the breakage rate continues with more testing, we will see another ~35k broken sites. Just wanted to point this out, if it affects our decision to whitelist these sites.

Hm, the broken rate was much higher than I thought. I would have to delay the change.

Lets hope the new RC4 attacks like those shown at Black Hat Asia 2015 make the news.

mega.nz / mega.co.nz should no longer need RC4 whitelisting - works for me with RC4 disabled.

*.userstorage.mega.co.nz still needs RC4 and it is tracked by bug 1133496.

Is whitelisting appropriate after http://www.isg.rhul.ac.uk/tls/RC4mustdie.html ?

Doesn't seem typically practical with cookies as the password is transmitted only once on login.

(In reply to Nick Lowe from comment #64) > Is whitelisting appropriate ... Nobody here seriously thinks whitelisting RC4 is appropriate. It's a necessary evil due to lack of vendor coordination in dropping support (even with RFC 7465). What's not appropriate and is avoidable is the fact that this is being done without forcefully alerting the user with an interstitial warning explicitly saying that the website's security is incompetent and insecure. Again, fear of nobody else doing it is why we're not. That should probably be reconsidered, but in a new bug. This one is done. Bug 999544 is a better place to have new RC4 info in lieu of a new bug.

I work at a very large organisation where we have ageing hardware proxies that perform load balancing and other functions for us. They are scheduled for replacement, but in the meantime, we are stuck with them. Guess what, they still use RC4 and they still provide service to a number of our internal and external services. We can't change them at the drop of a hat. I would kindly request that the "whitelist" be user-modifiable so that we may at least add our own internal services to the list until we can get them upgraded or removed.

(In reply to twkonefal from comment #67) RC4 uses the same whitelist system as for insecure fallback, so setting the "security.tls.insecure_fallback_hosts" pref (a CSV list of domains) should be sufficient for your needs. I'm not 100% sure, though, so needinfoing the assignee to confirm this is and will continue to be the case.

Dave is correct. Adding the "security.tls.insecure_fallback_hosts" pref will work. If you have too many hosts to add this pref (a pref will have 4096 chars limit), flipping "security.tls.unrestricted_rc4_fallback" will also work. Moreover, this change was postponed to Firefox 39. So ESR 38 will not be affected.

The attached list contains sites that are broken in Fx39. They connect with RC4 cypher and only support TLS 1.0. I assume we want to whitelist these. These came from the Pulse top 200k sites list. If we need to crawl the Google CT list of almost 3 million sites to obtain more URLs for the whitelist, let me know and I can do that.

Re: comment 70 The list has 837 hosts out of 200k = 0.42%; is that really reason to delay this any more, especially past 38ESR when temporary workarounds are readily available in the browser?... I know it's late in the cycle but you really should get this in 38

This list only contains TLS 1.0 sites. TLS 1.1/1.2 sites are listed in bug 1138101 comment #7.

OK, thanks, so it's 0.81% instead... That's still very much niche and shouldn't negatively affect the security of all your users, IMHO, no matter how relatively high-profile some entries are. I think if everyone waits for everyone else to go "first", then we'll never get out of this insecure status quo where browsers remain silent about bad encryption, and there's never a pressing reason apart from being contacted by evangelists for server operators to change this. Sorry for going off-topic for this particular bug, but I do hope that it's a concern that can be given some thought.

This was effectively disabled in Firefox 38 by bug 1138882, as I understand it.

Where do I find the current list of whitelisted hosts? Is the user supposed to modify this list (i.e. add own hosts/remove whitelisted hosts)?

(In reply to Igor from comment #75) > Where do I find the current list of whitelisted hosts? https://dxr.mozilla.org/mozilla-central/source/security/manager/ssl/IntolerantFallbackList.inc (This list is shared between TLS 1.0 fallback and RC4 fallback, actually.) > Is the user supposed to modify this list (i.e. add own hosts/remove > whitelisted hosts)? Use the about:config pref security.tls.insecure_fallback_hosts (use a comma-separated list of domains).

Also note that it was indefinitely delayed to whitelist RC4 fallback. The Firefox 39 release note was wrong.