Allow RC4 only for whitelisted hosts

RESOLVED FIXED in mozilla38

Status

()

defect
RESOLVED FIXED
4 years ago
2 years ago

People

(Reporter: emk, Assigned: emk)

Tracking

({dev-doc-complete, site-compat})

unspecified
mozilla38
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(firefox38 disabled)

Details

Attachments

(3 attachments, 2 obsolete attachments)

(Assignee)

Description

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

Comment 1

4 years ago
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.
(Assignee)

Comment 2

4 years ago
If all browser vendors will turn off RC4 at once, I'll gladly just disable RC4. Otherwise users will just switch other browsers.
(Assignee)

Comment 3

4 years ago
(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.
(Assignee)

Comment 4

4 years ago
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.
Attachment #8556826 - Flags: review?(dkeeler)
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.
Flags: needinfo?(VYV03354)
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.
Attachment #8556826 - Flags: review?(dkeeler)
(Assignee)

Comment 7

4 years ago
(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.
Flags: needinfo?(VYV03354)
Summary: Add a whitelist for domains that require RC4 → Offer RC4 cipher-suites only if ClientHelloVersion is <= TLS 1.0
(Assignee)

Updated

4 years ago
Depends on: 1128763
(Assignee)

Comment 8

4 years ago
Comment on attachment 8556826 [details] [diff] [review]
Enable RC4 only if ClientHelloVersion <= TLS 1.0

Requesting review again.
Attachment #8556826 - Flags: review?(dkeeler)
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?
(Assignee)

Comment 10

4 years ago
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.
(Assignee)

Comment 12

4 years ago
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.
(Assignee)

Updated

4 years ago
Blocks: 1130670
(Assignee)

Comment 13

4 years ago
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).
Attachment #8556826 - Flags: review?(dkeeler)
(Assignee)

Comment 15

4 years ago
* 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.
Attachment #8556826 - Attachment is obsolete: true
Attachment #8560796 - Flags: review?(dkeeler)
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.
Attachment #8560796 - Flags: review?(dkeeler) → review+
(Assignee)

Comment 19

4 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/c731517a47e8
Assignee: nobody → VYV03354
Status: NEW → ASSIGNED
https://hg.mozilla.org/mozilla-central/rev/c731517a47e8
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla38
(Assignee)

Updated

4 years ago
Keywords: dev-doc-needed

Comment 21

4 years ago
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).
(Assignee)

Comment 22

4 years ago
(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.
(Assignee)

Comment 23

4 years ago
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.

Comment 24

4 years ago
(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.
Flags: sec-review?

Comment 25

4 years ago
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.
(Assignee)

Comment 26

4 years ago
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.
Flags: sec-review?

Comment 27

4 years ago
(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?
Depends on: 1133312

Comment 28

4 years ago
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
(Assignee)

Comment 29

4 years ago
(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.

Comment 30

4 years ago
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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Assignee)

Comment 33

4 years ago
(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.
(Assignee)

Comment 34

4 years ago
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.
Depends on: 1133496

Updated

4 years ago
(Assignee)

Updated

4 years ago
Depends on: 1132440
(Assignee)

Updated

4 years ago
Depends on: 1133648
(Assignee)

Updated

4 years ago
Summary: Offer RC4 cipher-suites only if ClientHelloVersion is <= TLS 1.0 → Allow RC4 only for whitelisted hosts
(Assignee)

Comment 36

4 years ago
I'll land this with the whitelist update (bug 1133187).
Attachment #8560796 - Attachment is obsolete: true
Attachment #8565390 - Flags: review?(dkeeler)
QA Contact: mwobensmith
(Assignee)

Updated

4 years ago
Depends on: 1132540
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.
Attachment #8565390 - Flags: review?(dkeeler) → review+
https://hg.mozilla.org/mozilla-central/rev/ae9cc48ed726
Status: REOPENED → RESOLVED
Last Resolved: 4 years ago4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla38
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.

Comment 43

4 years ago
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.
(Assignee)

Comment 44

4 years ago
(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.
(Assignee)

Comment 45

4 years ago
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.
Flags: needinfo?(mwobensmith)
Depends on: 1135966
(Assignee)

Updated

4 years ago
Depends on: 1136091
(Assignee)

Updated

4 years ago
Depends on: 1136376
Depends on: 1137079

Updated

4 years ago
Depends on: 1137444

Updated

4 years ago
Depends on: 1137543
(Assignee)

Updated

4 years ago
Depends on: 1112178

Updated

4 years ago
Depends on: 1138025

Updated

4 years ago
Depends on: 1135666

Updated

4 years ago
Depends on: RC4-Dependence

Comment 47

4 years ago
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.
See Also: RC4

Comment 48

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

Comment 49

4 years ago
(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.

Comment 50

4 years ago
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
(Assignee)

Comment 51

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

Comment 52

4 years ago
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.
(Assignee)

Comment 53

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

Comment 54

4 years ago
you got a url I can test with without the *? as I want to test the block still works.  thanks.
(Assignee)

Comment 55

4 years ago
Written in bug 1133496 (this is off-topic here).
See Also: → 1138613
(Assignee)

Comment 56

4 years ago
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.
Flags: needinfo?(mwobensmith)
Depends on: 1141604
No longer depends on: 1141604
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.
(Assignee)

Comment 60

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

Comment 61

4 years ago
Lets hope the new RC4 attacks like those shown at Black Hat Asia 2015 make the news.
(Assignee)

Updated

4 years ago
Depends on: 1142769
(Assignee)

Updated

4 years ago
No longer depends on: 1132440

Comment 62

4 years ago
mega.nz / mega.co.nz should no longer need RC4 whitelisting - works for me with RC4 disabled.
(Assignee)

Comment 63

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

Comment 64

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

Comment 65

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

Comment 66

4 years ago
(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.

Comment 67

4 years ago
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.

Comment 68

4 years ago
(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.
Flags: needinfo?(VYV03354)
(Assignee)

Comment 69

4 years ago
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.
Flags: needinfo?(VYV03354)
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.

Comment 71

4 years ago
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
(Assignee)

Comment 72

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

Comment 73

4 years ago
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.

Updated

4 years ago
Blocks: 1165421

Updated

4 years ago
No longer blocks: 1165421
Depends on: 1165421

Comment 75

4 years ago
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).
(Assignee)

Comment 77

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

Updated

3 years ago
Depends on: 1244935
(Assignee)

Updated

3 years ago
No longer depends on: 1244935
You need to log in before you can comment on or make changes to this bug.