My favorites | Sign in
Project Home Downloads Wiki Issues Code Search
New issue   Search
for
  Advanced search   Search tips   Subscriptions
Issue 375342: Drop RC4 Support
50 people starred this issue and may be notified of changes. Back to list
 
Reported by pascal.h...@gmail.com, May 20, 2014
UserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.114 Safari/537.36

Steps to reproduce the problem:
1. 
2. 
3. 

What is the expected behavior?

What went wrong?
I suggest to drop RC4 support at least on everything not windows XP. 

https://www.howsmyssl.com/

tells me that ciphers:
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_RC4_128_SHA
TLS_ECDHE_RSA_WITH_RC4_128_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_DSS_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_RC4_128_MD5

RC4 is insecure. 

Did this work before? N/A 

Chrome version: 35.0.1916.114  Channel: beta
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
Flash Version: Shockwave Flash 13.0 r0
May 20, 2014
#1 rsleevi@chromium.org
Chrome's support for cryptographic algorithms is independent of the OS. There is no reason to keep it enabled specifically for XP.

Note that there are still a number of sites that only have RC4 enabled.
Labels: Cr-Internals-Network-SSL
May 20, 2014
#2 pascal.h...@gmail.com
didn't know it is os independent. 

Maybe Google has any stats for websites that support only RC4.
May 21, 2014
#3 tkonch...@chromium.org
Waiting for more inputs on this.
Cc: tkonch...@chromium.org
Jun 1, 2014
#4 John.Wel...@gmail.com
I personally have a big issue with chrome still supporting RC4 as it uses it by default on many websites (paypal, etc...) and probably any websites that still support it instead of stronger ciphers. The only way to fix this is by adding --cipher-suite-blacklist=0x0004,0x0005,0xc011,0xc007 to the command line...

Simple way to test:
https://www.fortify.net/sslcheck.html

(I just tested on chromium 37.0.2026.0 (274154) on windows 7 x64 and chrome-dev and cannary with the same result on three different computers)

Since the NSA is reportedly able to decipher RC4 on the fly RC4 should be removed. Websites that only support RC4 are not worth connecting to anyway.

This really sounds like a backdoor :/

Jun 1, 2014
#5 pascal.h...@gmail.com
@comment #4:
fortify.net uses a bad chipher order:
https://www.ssllabs.com/ssltest/analyze.html?d=fortify.net


Jun 2, 2014
#6 John.Wel...@gmail.com
@comment #5:
So does www.paypal.com and a few other banking websites: https://www.ssllabs.com/ssltest/analyze.html?d=paypal.com&s=184.28.252.234

Unfortunately RC4 seems to be the first preferred cipher in many server default configurations (such as apache2.2) probably because it was the fastest secure cipher a few years ago...


Jun 5, 2014
#7 LEOXD.m...@gmail.com
Basically, everyone recommends to not use RC4 (or even prohibits using it inside their sphere of control). 

According to Microsoft, about 4% of all web servers require RC4* while 39% use RC4 by default [1]. I don't know whether chromium can afford to drop these 4%, but it will build up pressure for website owners

A possible implementation while preserving legacy support would be to block RC4 by default, but show a message that allows the user to enable RC4 for just that domain.  


*strangely enough, YouTube's video servers (e.g. https://r3---sn-uqj-caal.googlevideo.com) do require it. This has been escalated in the GPF, but I don't know whether somebody at Google is working on it.


[1] Microsoft: http://blogs.technet.com/b/srd/archive/2013/11/12/security-advisory-2868725-recommendation-to-disable-rc4.aspx

IETF/Microsoft: http://tools.ietf.org/html/draft-popov-tls-prohibiting-rc4-02

BSI (German Federal Office for Information Security): https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102-2_pdf.pdf?__blob=publicationFile [German]

ENISA: http://www.enisa.europa.eu/activities/identity-and-trust/library/deliverables/algorithms-key-sizes-and-parameters-report



Sep 10, 2014
#8 LEOXD.m...@gmail.com
Also:

Attack that can decrypt limited amounts of plaintext out of RC4 encrypted connections while being anywhere between client and server: http://www.isg.rhul.ac.uk/tls/

Oct 4, 2014
#9 enyo.m...@gmail.com
IMO dropping RC4 is more important than dropping SHA1, given RC4 has a demonstatatble attack and SHA1 doesnt.
Oct 30, 2014
#10 darren.p...@gmail.com
Dropping RC4 support needs to happen. I run with RC4 disabled site wide already.
Jan 8, 2015
#11 komm...@googlemail.com
At least one could put the RC4 ciphers at the end of the preference list.
Jan 8, 2015
#12 komm...@googlemail.com
Then chrome would use TLS_RSA_WITH_AES_256_CBC_SHA (0x35) with Paypal I guess.
Jan 9, 2015
#13 rsleevi@chromium.org
 Issue 447198  has been merged into this issue.
Jan 9, 2015
#14 hotaru@thinkindifferent.net
RC4 should be removed as soon as possible:
https://datatracker.ietf.org/doc/draft-ietf-tls-prohibiting-rc4/

> Then chrome would use TLS_RSA_WITH_AES_256_CBC_SHA (0x35) with Paypal I guess.
unless AES-256-CBC modes are disabled per issue 442572, in which case it will use TLS_RSA_WITH_AES_128_CBC_SHA (0x2f)... unless paypal decides they actually care about security and adds support for a sensible ciphersuite (with forward secrecy and authenticated encryption).
Jan 9, 2015
#16 darren.p...@gmail.com
There are working attacks on RC4 with time and data complexities practical for commodity hardware on a moderate budget.  AES-256 also has attacks, but the time and data complexities are presently viewed as beyond all but the heaviest attackers.  RC4 needs to go away--it is no better than export-grade DES.  Even with its flaws, AES-256-CBC it's still vastly stronger than RC4.  The decision is not individual merit, but which of these two to have enabled by default and we MUST enable at least one.  Thus I don't even see a question of it: disable RC4 by default and enable AES-256-CBC by default.

No, we don't get ideal crypto, but that's only because there is no such thing.  It's an arms race.  We get to be happy today because we can do something that makes life a bit harder for our enemies.
Jan 16, 2015
#17 tfran...@gmail.com
I have been tearing my hair out with this of late. I think the core problem may be a bit more 'politically challenging' than we think. It centres around PCI compliance and the CVSS rating of the BEAST attack...

The problem is that PCI scans report the usage of CBC ciphers in TLS1 as a PCI failure. This is not a fault of the PCI scanner vendors, but of the NIST as they maintain the CVSS score of CVE-2011-3389 at 4.3, even though the issue has been mostly mitigated in the wild.

In contrast, the CVE for RC4 (CVE-2013-2566) only has a score of 2.9.

In a PCI scan, any vulnerabilities with a CVSS score of 4 or higher result in an automatic fail. This means that to resolve this, companies choose RC4 over CBC, or disable CBC altogether. I have seen lots of big banks with this set-up :(

Essentially, if your company wishes to process details on payment cards, you need to be PCI compliant. The result of this - all PCI compliant companies will only use RC4 for TLS1.

This is just so broken.

This needs to be fixed at the NIST level - they need to lower the CVSS score for BEAST and then the companies can start having sane TLS cipher suite configurations. I can't see this happening.

Much as I hate to say it, if we disable RC4 in browsers right now, we will be forcing payment processing companies and banks to lose customers(by ignoring browsers with no RC4 or by turning off TLS1) or break their PCI compliance which may not be an option, despite how much the engineers disagree...
Feb 18, 2015
#18 ImFaster...@gmail.com
@comment #17:
But I think what you said is exactly why disabling RC4 on client side is important. Suppose a bank's website supports both RC4 and CBC, and prefers RC4 over CBC. If the browsers don't offer RC4 in ClientHello, then CBC will be used without any problem. The only problem here is that RC4-only websites will no longer work, but NIST doesn't prohibit websites from supporting better cipher suites such as TLS 1.2 with AES-GCM. So they can fix it without breaking their PCI compliance.

By the way, "prohibiting RC4 cipher suites" has been published as RFC 7465. https://tools.ietf.org/html/rfc7465
Feb 18, 2015
#19 rsleevi@chromium.org
I think you underestimate the challenges that may exist for site operators to upgrade to TLS 1.2 with AES-GCM (despite it being the sensible/responsible thing to do).

Regardless, David's been working on the BoringSSL cleanup bits, I'm kicking this over to him to drive for 43 to see what we can (responsibly) do here.
Status: Assigned
Owner: davidben@chromium.org
Labels: -OS-Windows OS-All Cr-Security-UX Cr-Security M-43
Feb 18, 2015
#20 darren.p...@gmail.com
@comment #19:
Sorry, but no, it's not hard at all.  Yes, I've rolled out that change at enterprise scale.  The hardest part was regression testing clients because, at the time, TLSv1.1 and TLSv1.2 support was mixed.  That's not the case anymore, you can safely enable it with minimal testing.
Feb 18, 2015
#21 rsleevi@chromium.org
I'm glad it was not hard for you. Unfortunately, one anecdote doesn't make for good data. We have a great deal of first hand and second hand experience that suggests otherwise, and we are continuing to work out the best plan.
Feb 18, 2015
#22 lgar...@chromium.org
(No comment was entered for this change.)
Cc: lgar...@chromium.org
Feb 18, 2015
#23 tfran...@gmail.com
It's more than hard if you use, say, Oracle iPlanet. It is in fact impossible as it does not support TLS 1.1 or 1.2.

To work around this, we need to re-engineer our front end. Possible, but hard to achieve in certain environments. iPlanet is not the only web server with this issue.
Feb 18, 2015
#24 tfran...@gmail.com
I have to add that, much as I hate to say it, IE has a nice way of dealing with this now (or next version, I forget where I read it). Basically it does not offer RC4 in the handshake. If there are no supported ciphers, then it does a second handshake, this time including RC4. Could this kind of workaround be included in Chrome? 
Feb 18, 2015
#25 rsleevi@chromium.org
That work around does nothing for security, and thus is something we are unlikely to consider, except for when it benefits data collection.
Feb 18, 2015
#26 ImFaster...@gmail.com
@comment #24:
The problem with the IE's approach is that an active man-in-the-middle can reset the first handshake and force it to reconnect to the servers using TLS 1.0 + RC4. It does prevent passive MITM though, but I do not think it is secure enough.

Mozilla is going to include a preloaded whitelist which contains RC4-only and TLS 1.2 intolerant servers. If a website is not on the whitelist, Firefox will not downgrade to TLS 1.0 or to include RC4.

If it is hard to support TLS 1.2, how about enabling both CBC and RC4, so that even though you are required to prioritize RC4, disabling RC4 on client side won't break your website?
Feb 18, 2015
#27 tfran...@gmail.com
Understood on the IE thing... Thought it was too good to be true lol.

In our case, I am pushing to keep CBC and drop RC4. However, sometimes it can be hard getting 'infosec' teams to read beyond the output of a compliance scan. I don't think our company is PCI compliant so we should be able to go the CBC-only route (I hope).

However, companies that do need PCI compliance (See post 17), and for whatever reason cannot disable TLSv1, will be stuck with RC4 only if they are to satisfy their audits.

Whitelist is nice. Annoying for users, but better than no access.

By the way, I love the push against RC4, and would love it if we had to re-engineer our systems to be, well, sane. My hesitation is simply due to that damn thing called reality and politics, lol. Le Sigh. I'm sure i'm not the only one.
Feb 18, 2015
#28 ImFaster...@gmail.com
I find this on NIST website [1]:
"I would like to dispute the score of a vulnerability. What should I do?

"If you believe a score should be changed based on publicly available information that may not have been available at the time of the scoring please email including the CVE ID and a description of the issue with supporting public information and the NVD analysts will review the score and respond appropriately."

So it seems possible to ask NIST to update the scores of BEAST and RC4 attack vulnerabilities.

[1] https://nvd.nist.gov/faq#440bb045-9d20-4e17-b463-8d45ff555ef1
Feb 18, 2015
#29 LEOXD.m...@gmail.com
In case you want to have a closer look at Mozilla's approach: https://bugzilla.mozilla.org/show_bug.cgi?id=1088915
Feb 19, 2015
#30 mike.cat...@gmail.com
OK, good find. I am planning to send the following email to NVD:

"Hi,

I believe that the CVSS score for CVE-2011-3389 relative to the score for CVE-2013-2566 is harming efforts to implement RFC 7465 [3], harming the overall security of the TLS ecosystem. The issue is described succinctly at [4]: PCI-compliant servers may not enable CBC-based ciphersuites because CVE-2011-3389 has a base score of 4.3, which means RC4 is the only possible ciphersuite to use for the server to use for TLS 1.0 and TLS 1.1. CVE-2013-2566, the RC4 vulnerability mitigated by RFC 7465, has a lower score. However, CVE-2013-2566 is a much more serious issue in practice, because CVE-2011-3389 has been mitigated on the client side in all major browsers without disabling the ciphersuites, whereas no mitigation for CVE-2013-2566 is available short of disabling RC4.

Please reconsider the ratings for these vulnerabilities to allow PCI-compliant servers to disable RC4-based ciphersuites instead of CBC-based ciphersuites, so that browser vendors can more comfortably disable support for RC4 [4] [5] [6].

Thank you,

Michael Catanzaro

[1] https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-3389
[2] https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-2566
[3] http://www.rfc-editor.org/rfc/rfc7465.txt
[4] https://code.google.com/p/chromium/issues/detail?id=375342#c17
[5] https://bugzilla.mozilla.org/show_bug.cgi?id=999544
[6] https://bugs.webkit.org/show_bug.cgi?id=140014
"

Are there any flaws in the email, before I send it? Alternatively, an email signed by Google and Mozilla might be more effective. It would be great if your companies could meet to discuss this. Mozilla is naturally afraid of turning off RC4 before Chrome.
Feb 19, 2015
#31 mike.cat...@gmail.com
A small revision:

"However, CVE-2013-2566 is a much more serious issue in practice, because CVE-2011-3389 has been long-since mitigated on the client side in all major browsers using the 1/n-1 split technique [7], which allows CBC-based ciphersuites to be used safely."

[7] https://bugzilla.mozilla.org/show_bug.cgi?id=665814#c59
Feb 19, 2015
#32 VYV03...@nifty.ne.jp
> PCI-compliant servers may not enable CBC-based ciphersuites because CVE-2011-3389 has a base score of 4.3, which means RC4 is the only possible ciphersuite to use for the server to use for TLS 1.0 and TLS 1.1.

TLS 1.1 is not vulnerable to CVE-2011-3389 due to explicit IV. Only TLS 1.0 has no choice other than RC4.
Feb 19, 2015
#33 mike.cat...@gmail.com
Thank you; good thing I posted this for review before sending. Revised email:

"Hi,

I believe that the CVSS score for CVE-2011-3389 relative to the score for CVE-2013-2566 is harming efforts to implement RFC 7465 [3], harming the overall security of the TLS ecosystem. The issue is described succinctly at [4]: PCI-compliant servers may not enable CBC-based ciphersuites because CVE-2011-3389 has a base score of 4.3, which means RC4 is the only possible ciphersuite for the server to use with TLS 1.0. CVE-2013-2566, the RC4 vulnerability mitigated by RFC 7465, has a lower score. However, CVE-2013-2566 is a much more serious issue in practice, because CVE-2011-3389 has been long-since mitigated on the client side in all major browsers using the 1/n-1 split technique [5], which allows CBC-based ciphersuites to be used safely, whereas no mitigation for CVE-2013-2566 is available short of disabling RC4.

Please reconsider the ratings for these vulnerabilities to allow PCI-compliant servers to disable RC4-based ciphersuites instead of CBC-based ciphersuites, so that browser vendors can more comfortably disable support for RC4 [4] [6] [7].

Thank you,

Michael Catanzaro

[1] https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-3389
[2] https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-2566
[3] http://www.rfc-editor.org/rfc/rfc7465.txt
[4] https://code.google.com/p/chromium/issues/detail?id=375342#c17
[5] https://bugzilla.mozilla.org/show_bug.cgi?id=665814#c59
[6] https://bugzilla.mozilla.org/show_bug.cgi?id=999544
[7] https://bugs.webkit.org/show_bug.cgi?id=140014
"

Feb 19, 2015
#34 davidben@chromium.org
To avoid giving the wrong idea, the CBC mode construction used in TLS is pretty awful too (mac-then-encrypt instead of encrypt-then-mac). We keep finding more and more creative ways to mess it up. *Anything* that's not a TLS 1.2 AEAD---so AES-GCM and, after it makes its way through the IETF, CHACHA20-POLY1305---should be considered cryptographically broken at this point. Though what can be responsibly done in light of that is another question.

Also note that, to server already not using RC4 or whatever else, removing a weak cipher on the client doesn't do much. TLS's cipher suite negotiation is secure, so an attacker already cannot force a connection to RC4 when the server is reasonable enough to support and prefer AES-GCM. The benefits are more in trying to push the ecosystem forward.
Feb 19, 2015
#35 mike.cat...@gmail.com
At the same time, we're both aware that cryptographically broken does not mean it's unacceptable to use in practice. Anyway, we can tack on one more sentence after the last paragraph: "Note that increasing the CVSS rating of CVE-2013-2566 rather than reducing the rating of CVE-2011-3389 would encourage servers to implement newer versions of TLS and do more to push the ecosystem forward, although either approach would address the immediate issue."
Feb 20, 2015
#36 VYV03...@nifty.ne.jp
Sorry about forgetting to say that CBC mode cipher suites (and hence TLS 1.1) are inherently fragile because of the MtE structure. My comment concentrated on CVE-2011-3389 because it was the only thing that matters "politically".
Feb 20, 2015
#37 mike.cat...@gmail.com
I sent the letter. I probably won't post again here unless I receive a substantial response. Good luck....
Feb 24, 2015
#38 clemens...@gmail.com
It's ridiculous that Google and the Chromium team still have RC4 in the cipher suite list when at the same time they are very thoughtful when it comes to certificates (e.g. SHA1, SHA2) and other default settings.
I choose Chrome because it is "secure by default", sandboxed and is in general very secure. But why do we have to --cipher-suite-blacklist=bla when it is common knowledge that RC4 should be avoided at all costs. It's trivial to break and in my opinion as big of a problem as still having only SHA1 hashes in your certificates.
Today, even Firefox removed RC4..
Feb 24, 2015
#39 komm...@googlemail.com
@#38
What does Firefox do with RC4-only sites?
Feb 24, 2015
#40 ImFaster...@gmail.com
@#39

Actually Firefox just removes RC4 from the initial handshake, like IE 11. If the first handshake fails, it will add RC4 in the second handshake and try again.
Feb 24, 2015
#41 hotaru@thinkindifferent.net
#39: it tries to connect without RC4, and if that fails (unreliable or slow network connection, active MITM attack, RC4-only server, etc.), it tries again with RC4.

#38: google is afraid of breaking too many sites (~1.4% of https sites), and would rather leave people vulnerable to MITM attacks (against ~23.3% of https sites). that's why firefox and IE have implemented their obviously insecure fallback for RC4-only sites... they don't want to break those few RC4-only sites, but they still want to look like they're doing *something*. if you're really concerned about security, you should disable AES-256-CBC (issue 442572) and DHE (chrome accepts ridiculously weak DH parameters such as https://hotaru.thinkindifferent.net/dh_bad.pem without even a warning). maybe RSA key exchange (to require forward secrecy), too, if you don't mind not being able to access most banking sites (including paypal and pretty much every major bank in the US). unfortunately, there's currently no way to completely disable SHA-1 certificates, and a lot of sites (including google!) still use SHA-1 certificates.
Feb 25, 2015
#42 VYV03...@nifty.ne.jp
> #38: google is afraid of breaking too many sites (~1.4% of https sites),

According to Mozilla's statistics as of November 2012 [1], it is only ~0.3% (although it is still 10 times higher than the 0.03% threshold). The number should be even lower for Chrome because Chrome offers more cipher suites than Firefox.
Firefox introduced the RC4 fallback to gather the statistics, not for security. Yes, it is vulnerable to the active MiTM.

[1] https://tools.ietf.org/agenda/91/slides/slides-91-saag-3.pdf#page=12
Feb 25, 2015
#43 VYV03...@nifty.ne.jp
> November 2012
November 2014, of course.
Mar 12, 2015
#44 mike.cat...@gmail.com
Hi, I received this response from NIST:

"After significant discussions with multiple parties including authors of CVSS v2 and the current members of the CVSS-SIG, it has been determined that the CVSS v2 score for CVE-2011-3389 is correct and the score for CVE-2013-2566 should be adjusted to be equal to it.  It was determined that Access Complexity for both should be Medium, as the actions required for success are not particularly difficult to achieve, nor uncommon. It was agreed that the attacks could take a potentially long time to complete, but this is not considered a factor of changing the value to High. This decision is in line with the scoring guidance provided in the CVSS v2 specification."

So I guess now you will fail your audit if your server supports RC4, and since you already fail for supporting CBC in TLS 1.0 you will need to cut off support for TLS 1.0 clients entirely.
Mar 12, 2015
#45 ImFaster...@gmail.com
Great job! It is so interesting that now both BEAST and RC4 have scores higher than 4.0. As comment #44 suggests, now PCI compliant companies have no cipher suites to use with TLS 1.0. Is it going to happen soon that these companies will cut off TLS 1.0? After all, doing so means Android 4.3-, IE 10-, Java 7-, and Safari on OS X 10.8- users can no longer visit their websites [1]. Are PCI scanner vendors aware of this score change?

[1] https://www.ssllabs.com/ssltest/clients.html
Mar 16, 2015
#46 mike.cat...@gmail.com
That seems to be the only possible consequence of the score change, based on the information you provided above. I note that one of the first sites I checked, amazon.com, supports AES with TLS 1.0, which I would not have expected if that would cause them to fail an audit.

Not sure if PCI scanner vendors are aware. But the NVD web site has been updated: https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-2566
Mar 17, 2015
#47 nick.l...@gmail.com
After http://www.isg.rhul.ac.uk/tls/RC4mustdie.html , it would seem expedient and pertinent to now either drop RC4 completely or to not include RC4 in the initial Client Hello and add an interstitial warning after a fallback handshake completes which includes RC4-based cipher suites in a second Client Hello.

By offering RC4-based cipher suites only in a fallback handshake, this would ensure that that servers that are misconfigured to prefer a RC4-based cipher suite but do offer other secure alternatives remain accessible without warning. (This misconfiguration is common after BEAST. It's unnecessary in Chrome though due to 1/n-1 record splitting.)

Firefox are keen to add in an interstitial before RC4 is used but are concerned about the potential impact that it may have on their market share if they do it in advance of Chrome and Internet Explorer. It would be good to get some collaboration.

Both Firefox and IE presently only include RC4 cipher suites in a second, fallback Client Hello.
Apr 3, 2015
#48 bugdroid1@chromium.org
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/a4c9d060fa6e74b6513b198064cfe7b06482d404

commit a4c9d060fa6e74b6513b198064cfe7b06482d404
Author: davidben <davidben@chromium.org>
Date: Fri Apr 03 22:34:25 2015

Move RC4 behind a fallback.

This is to start gathering better metrics on which servers require RC4. Many
servers which prefer RC4 will still accept another cipher suite. Moving it
behind a fallback will make our cipher suite metrics reflect roughly servers
which require it and not only those which prefer it.

Note that this sort of fallback provides NO security benefit. If a server
prefers a non-RC4 cipher, they already securely negotiate it whether or not the
client offers RC4. If a server prefers RC4, this kind of fallback does nothing
to prevent an attacker from switching the connection to RC4. This is purely for
measurement.

BUG=375342

Review URL: https://codereview.chromium.org/1052743003

Cr-Commit-Position: refs/heads/master@{#323837}

[modify] http://crrev.com/a4c9d060fa6e74b6513b198064cfe7b06482d404/net/http/http_network_transaction.cc
[modify] http://crrev.com/a4c9d060fa6e74b6513b198064cfe7b06482d404/net/http/http_stream_factory_impl_job.cc
[modify] http://crrev.com/a4c9d060fa6e74b6513b198064cfe7b06482d404/net/log/net_log_event_type_list.h
[modify] http://crrev.com/a4c9d060fa6e74b6513b198064cfe7b06482d404/net/socket/client_socket_pool_manager.cc
[modify] http://crrev.com/a4c9d060fa6e74b6513b198064cfe7b06482d404/net/socket/ssl_client_socket_nss.cc
[modify] http://crrev.com/a4c9d060fa6e74b6513b198064cfe7b06482d404/net/socket/ssl_client_socket_openssl.cc
[modify] http://crrev.com/a4c9d060fa6e74b6513b198064cfe7b06482d404/net/socket/ssl_client_socket_unittest.cc
[modify] http://crrev.com/a4c9d060fa6e74b6513b198064cfe7b06482d404/net/ssl/ssl_config.cc
[modify] http://crrev.com/a4c9d060fa6e74b6513b198064cfe7b06482d404/net/ssl/ssl_config.h
[modify] http://crrev.com/a4c9d060fa6e74b6513b198064cfe7b06482d404/net/url_request/url_request_unittest.cc
[modify] http://crrev.com/a4c9d060fa6e74b6513b198064cfe7b06482d404/tools/metrics/histograms/histograms.xml

Apr 11, 2015
#49 hotaru@thinkindifferent.net
now there's a second CVE with a CVSS score of 4.3 for RC4: https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-2808
if PCI scanner vendors weren't aware of the score change for that other one, they should be aware of this new one.
Apr 14, 2015
#50 penny...@google.com
[AUTO] Moving all non essential bugs to the next Milestone.  (This decision is based on the labels attached to your ticket.)


Ref: https://sites.google.com/a/chromium.org/dev/developers/ticket-milestone-punting-1
Labels: -M-43 M-44 MovedFrom-43
Apr 26, 2015
#51 chrodev2015@gmail.com
Noticed that RC4-only sites still get a green lock with "Your connection to this site is private". Example: https://rc4.serverhello.com/

@davidben, shouldn't Chrome UI mention RC4 fallback?

Proposal:
— Gray lock with yellow triangle
— This site uses a weak security configuration (RC4 cipher), so your connection may not be private.
— The connection had to be retried using a weak encryption algorithm. This typically means that the server is misconfigured and may have other security issues.
rc4-chrome44.png
39.3 KB   View   Download
Apr 26, 2015
#52 rsleevi@chromium.org
There are no plans for UI treatment at this time.
May 13, 2015
#53 t...@ritter.vg
On the topic of PCI and CVSS scores, I talked with a QSA.  Because of the 4.3 scores and general badness, PCI 3.1 was released recently and marks TLS 1.0 and below as unacceptable.  Anyone wanting to use it must document a Risk Mitigation and Migration Plan.  Which people do by saying "We have clients who haven't upgraded."  But in newly deployed infrastructure the PCI Council is actually saying that they can't deploy TLS 1.0 or below at all, and to strand any older clients.

I don't imagine this significantly affects opinions on UI treatment (including keeping the EV badging), but wanted to add some context I learned today.

See also: https://www.pcisecuritystandards.org/documents/Migrating_from_SSL_Early_TLS_Information_Supplement_v1.pdf
May 21, 2015
#55 penny...@google.com
[AUTO] This issue has already been moved once and is lower than Priority 1,therefore removing mstone.
Labels: -M-44 MovedFrom-44
Jun 19, 2015
#57 yuhongba...@hotmail.com
In retrospect, I would have called RC4 "obsolete" cryptography and CBC just "legacy".
Jul 18, 2015
#58 wfh@chromium.org
 Issue 511609  has been merged into this issue.
Jul 18, 2015
#59 hotaru@thinkindifferent.net
attacks against RC4 in TLS are now practical: http://www.rc4nomore.com/

these attacks will continue to get better as more analysis of the biases in RC4 is done.
Sign in to add a comment

Powered by Google Project Hosting