New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 375342 link

Starred by 53 users

Issue metadata

Status: Fixed
Owner:
Closed: Nov 2015
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Feature

Blocked on:
issue 549366



Sign in to add a comment

Drop RC4 Support

Reported by pascal.h...@gmail.com, May 20 2014

Issue description

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
 
Labels: Cr-Internals-Network-SSL
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.
didn't know it is os independent. 

Maybe Google has any stats for websites that support only RC4.
Cc: tkonch...@chromium.org
Waiting for more inputs on this.
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 :/

@comment #4:
fortify.net uses a bad chipher order:
https://www.ssllabs.com/ssltest/analyze.html?d=fortify.net


@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...


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



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/

Comment 9 by Deleted ...@, Oct 4 2014

IMO dropping RC4 is more important than dropping SHA1, given RC4 has a demonstatatble attack and SHA1 doesnt.

Comment 10 by Deleted ...@, Oct 30 2014

Dropping RC4 support needs to happen. I run with RC4 disabled site wide already.

Comment 11 by komm...@gmail.com, Jan 8 2015

At least one could put the RC4 ciphers at the end of the preference list.

Comment 12 by komm...@gmail.com, Jan 8 2015

Then chrome would use TLS_RSA_WITH_AES_256_CBC_SHA (0x35) with Paypal I guess.
 Issue 447198  has been merged into this issue.
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).

Comment 15 Deleted

Comment 16 by Deleted ...@, Jan 9 2015

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.

Comment 17 by tfran...@gmail.com, Jan 16 2015

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...
@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
Labels: -OS-Windows OS-All Cr-Security-UX Cr-Security M-43
Owner: davidben@chromium.org
Status: Assigned
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.

Comment 20 by Deleted ...@, Feb 19 2015

@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.
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.
Cc: lgar...@chromium.org

Comment 23 by tfran...@gmail.com, Feb 19 2015

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.

Comment 24 by tfran...@gmail.com, Feb 19 2015

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? 
That work around does nothing for security, and thus is something we are unlikely to consider, except for when it benefits data collection.
@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?

Comment 27 by tfran...@gmail.com, Feb 19 2015

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.
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
In case you want to have a closer look at Mozilla's approach: https://bugzilla.mozilla.org/show_bug.cgi?id=1088915
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.
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
> 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.
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
"

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.
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."
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".
I sent the letter. I probably won't post again here unless I receive a substantial response. Good luck....
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..

Comment 39 by komm...@gmail.com, Feb 24 2015

@#38
What does Firefox do with RC4-only sites?
@#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.
#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.
> #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
> November 2012
November 2014, of course.
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.
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
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
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.
Project Member

Comment 48 by bugdroid1@chromium.org, Apr 3 2015

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

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.
Labels: -M-43 M-44 MovedFrom-43
[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
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
There are no plans for UI treatment at this time.

Comment 53 by t...@ritter.vg, May 13 2015

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

Comment 54 Deleted

Labels: -M-44 MovedFrom-44
[AUTO] This issue has already been moved once and is lower than Priority 1,therefore removing mstone.

Comment 56 Deleted

In retrospect, I would have called RC4 "obsolete" cryptography and CBC just "legacy".

Comment 58 by wfh@chromium.org, Jul 18 2015

 Issue 511609  has been merged into this issue.
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.
Labels: -MovedFrom-43 -MovedFrom-44 M-48
Per https://groups.google.com/a/chromium.org/d/msg/security-dev/kVfCywocUO8/vgi_rQuhKgAJ, this will be going away next year, which puts it at M48.
Cc: edwardjung@chromium.org
In Chrome 48 on Mac, network error pages now show a prominent "Diagnose errors..." button under details. It links to the OSX Network Diagnostic tool.

I'm guessing that a non-trivial number of OSX folks will see that button on an RC4 error page for the first time. I'm worried that it will seem to them that we are recommending OSX's network diagnostic tool for this specific error.

edwardjung@: I presume you were involved with this. Could we hide it for certain errors where the OSX diagnostic is not likely to do anything useful?
Screen Shot 2015-10-29 at 16.12.42.png
366 KB View Download
Screen Shot 2015-10-29 at 16.12.40.png
247 KB View Download
Could we split this out into a different bug? That button is useless for ERR_SSL_VERSION_OR_CIPHER_MISMATCH whether or not we turn off RC4.
Blockedon: chromium:549366
Done.
Cc: mmenke@chromium.org
Diagnose button was added by mmenke. 
Cc: -mmenke@chromium.org -edwardjung@chromium.org

Comment 66 by wyd...@gmail.com, Oct 30 2015

@davidben@chromium.org
You'll find a similar button/link appears on Windows too, not just for this scenario but for other similar SSL failure scenarios too. Again all are useless/misleading.
Project Member

Comment 67 by bugdroid1@chromium.org, Oct 30 2015

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/14b1a53362ffb727e02bdf27e24e93c5f9b2d423

commit 14b1a53362ffb727e02bdf27e24e93c5f9b2d423
Author: davidben <davidben@chromium.org>
Date: Fri Oct 30 16:01:09 2015

Remove RC4 by default.

RC4 may still be re-enabled via the RC4Enabled administrative policy, until
sometime around September. Also control it via a field trial so we still have
an escape hatch should something catastrophic happen.

Keep the deprecated cipher suite fallback around (rename the parameter since I
got the naming convention wrong) since it's still got the IIS AES-GCM
workaround in it, and it will be used in not too long for DHE_RSA instead.

BUG= 375342 
TEST=Loading https://rc4.badssl.com/ fails with ERR_SSL_VERSION_OR_CIPHER_MISMATCH
     Relaunching Chrome with --force-fieldtrials=RC4Ciphers/Enabled/ makes that page succeed.
     Relaunching Chrome after setting the RC4Enabled polcy to true makes that page succeed.
     (Note: press refresh when loading the site to make sure it's not cached.)

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

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

[modify] http://crrev.com/14b1a53362ffb727e02bdf27e24e93c5f9b2d423/chrome/app/generated_resources.grd
[modify] http://crrev.com/14b1a53362ffb727e02bdf27e24e93c5f9b2d423/chrome/browser/policy/configuration_policy_handler_list_factory.cc
[modify] http://crrev.com/14b1a53362ffb727e02bdf27e24e93c5f9b2d423/chrome/test/data/policy/policy_test_cases.json
[modify] http://crrev.com/14b1a53362ffb727e02bdf27e24e93c5f9b2d423/components/policy/resources/policy_templates.json
[modify] http://crrev.com/14b1a53362ffb727e02bdf27e24e93c5f9b2d423/components/ssl_config/ssl_config_prefs.cc
[modify] http://crrev.com/14b1a53362ffb727e02bdf27e24e93c5f9b2d423/components/ssl_config/ssl_config_prefs.h
[modify] http://crrev.com/14b1a53362ffb727e02bdf27e24e93c5f9b2d423/components/ssl_config/ssl_config_service_manager_pref.cc
[modify] http://crrev.com/14b1a53362ffb727e02bdf27e24e93c5f9b2d423/net/http/http_network_transaction.cc
[modify] http://crrev.com/14b1a53362ffb727e02bdf27e24e93c5f9b2d423/net/socket/client_socket_pool_manager.cc
[modify] http://crrev.com/14b1a53362ffb727e02bdf27e24e93c5f9b2d423/net/socket/ssl_client_socket_nss.cc
[modify] http://crrev.com/14b1a53362ffb727e02bdf27e24e93c5f9b2d423/net/socket/ssl_client_socket_openssl.cc
[modify] http://crrev.com/14b1a53362ffb727e02bdf27e24e93c5f9b2d423/net/socket/ssl_client_socket_unittest.cc
[modify] http://crrev.com/14b1a53362ffb727e02bdf27e24e93c5f9b2d423/net/ssl/ssl_config.cc
[modify] http://crrev.com/14b1a53362ffb727e02bdf27e24e93c5f9b2d423/net/ssl/ssl_config.h
[modify] http://crrev.com/14b1a53362ffb727e02bdf27e24e93c5f9b2d423/net/url_request/url_request_unittest.cc
[modify] http://crrev.com/14b1a53362ffb727e02bdf27e24e93c5f9b2d423/tools/metrics/histograms/histograms.xml

Status: Fixed
Please, add ability to restore the support of RC4 via flags.
Some important sites, such as banks or credit companies are still using RC4 and after its deprecation in Chrome I can't use these sites, I got «ERR_SSL_VERSION_OR_CIPHER_MISMATCH» error.

Please, let re-enable this functionality at least for a couple of months, until all major websites will migrate to a newer standard.
#69: Banks *should not* use RC4 for years. When I changed my bank the first thing was to check the TLS stats of the connection. I found out they used RC4, and I mailed them asking to change it. They moved to AES after I said other banks uses AES. :)
Btw, I'm against RC4, because it's considered weak, and obsoleted years ago. My crypto library at my company does not include the RC4 at all.
#69 They've had, for example, 2 years from Microsoft's advisory to make this change. If they haven't by now, they won't until it breaks.

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

Comment 72 Deleted

OK, thanks for the comments, it's very interesting to hear that, because major finance players on Israel market are not updated and still use the outdated security standards.

Here is the list of companies and sites, which still use the RC4 protocol:
— Bank Hapoalim, https://www.bankhapoalim.co.il/
— FIBI, https://new.fibi-online.co.il/
— Isracard, https://www.isracard.co.il/
— American Express Israel, https://www.americanexpress.co.il/
#73 They'll be forced to do something about it when it breaks in all the major browsers.

Comment 75 by komm...@gmail.com, Nov 10 2015

#73:
Only the first two sites in your list support ONLY RC4. The last two don't even support RC4 at all.

Comment 76 Deleted

#75:

Regarding to «the last two don't even support RC4 at all», so why I began to receive the «ERR_SSL_VERSION_OR_CIPHER_MISMATCH» error exactly when RC4 support has been dropped in Chrome?

Comment 78 by komm...@gmail.com, Nov 10 2015

I don't know why you get this error but I'm pretty sure it has nothing to do with RC4.
I can connect to both sites with latest Chrome (on Linux) with AES cipher suites.

According to the sslLabs test they don't offer RC4 cipher suites:
https://www.ssllabs.com/ssltest/analyze.html?d=https%3A%2F%2Fdigital.isracard.co.il%2F
https://www.ssllabs.com/ssltest/analyze.html?d=https%3A%2F%2Fhe.americanexpress.co.il%2F
I receive this error since the build:

Google Chrome	48.0.2552.0 (Official Build) dev-m (64-bit)
Revision	cd60d52ce5a94f47e966744245c3ca1567d49d85-refs/heads/master@{#357293}
OS		Windows 
Blink		537.36 (@cd60d52ce5a94f47e966744245c3ca1567d49d85)
JavaScript	V8 4.8.193
Flash		19.0.0.245
User Agent	Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2552.0 Safari/537.36

No flags are enabled, Windows 10 x64.
No additional security software installed.

Can it be related to IE/Windows settings?

Comment 80 by komm...@gmail.com, Nov 10 2015

Ok, I can reproduce your problems with the unstable version of Chrome. But I don't know where the problem is since these servers support a lot of cipher suites. None of them uses RC4 as I can see?!
#78

https://www.ssllabs.com/ssltest/analyze.html?d=isracard.co.il
https://www.ssllabs.com/ssltest/analyze.html?d=americanexpress.co.il

you tested subdomains and not the linked pages of #73
both are using RC4 only

Comment 82 by komm...@gmail.com, Nov 10 2015

Thanks for pointing this out!
I got redirected and didn't notice.
michel.budnyatsky: It's not scheduled to go away until around January or February of next year, when Chrome 48 reaches the stable channel. You're currently on the Dev channel release which is our development channel where we test things out early. You can switch back to the Stable channel for it to be disabled later.
https://www.google.com/intl/en/chrome/browser/desktop/index.html

Thanks for the list of sites though! We'll try to reach out to them.
#83:
Yes, I know the purpose and the meaning of Dev vs. Stable branches. I just wanted to clarify the situation.

Regarding sites, here are the list of additional «broken» sites:
— Bank Masad, https://online.bankmassad.co.il/wps/portal
— Bank Otsar Ha Hayal, https://online.bankotsar.co.il/wps/portal/
— Bank Pagi, https://online.pagi.co.il/wps/portal
— U-Bank, https://online.u-bank.net/wps/portal/

All these four organizations are actually sub-companies of the «First International Bank of Israel» (aka FIBI) https://new.fibi-online.co.il/, which is also broken. I suppose, all these five sites are based on the same software platform.
Project Member

Comment 85 by bugdroid1@chromium.org, Nov 11 2015

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/faaa27cb63e432633cc8f62b7326bc3e7dc7181d

commit faaa27cb63e432633cc8f62b7326bc3e7dc7181d
Author: davidben <davidben@chromium.org>
Date: Wed Nov 11 03:53:38 2015

Revise the ERR_SSL_VERSION_OR_CIPHER_MISMATCH string slightly.

BUG= 375342 

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

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

[modify] http://crrev.com/faaa27cb63e432633cc8f62b7326bc3e7dc7181d/chrome/app/generated_resources.grd

Project Member

Comment 86 by bugdroid1@chromium.org, Mar 7 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/7cc4af24b0eed5e453a3ea5555beb4b65a8f86b5

commit 7cc4af24b0eed5e453a3ea5555beb4b65a8f86b5
Author: davidben <davidben@chromium.org>
Date: Mon Mar 07 20:17:19 2016

Remove the RC4 field trial.

The removal has survived a release cycle without needing the field trial. This
can probably be removed now. The rc4_enabled field in SSLConfig still needs to
remain for a little while longer; the admin policy has a few more release
cycles on it.

BUG= 375342 

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

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

[modify] https://crrev.com/7cc4af24b0eed5e453a3ea5555beb4b65a8f86b5/components/ssl_config/ssl_config_service_manager_pref.cc

Project Member

Comment 87 by bugdroid1@chromium.org, Jun 6 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/6a260681b771e1042386d09d0fc4b31148030640

commit 6a260681b771e1042386d09d0fc4b31148030640
Author: davidben <davidben@chromium.org>
Date: Mon Jun 06 16:24:44 2016

Remove the last vestiges of RC4.

We've branched for 53 now, so the admin policy for enabling RC4 has
expired. Remove it completely.

Farewell, RC4. There was a time when you saved us from the beast and
rabid poodles. By luck, you didn't have triskaidekaphobia, unlike our
other friends who chained blocks together. (Boy are they annoying.
It'd be wonderful if we could ditch them someday.)

But you always had your biases, which made it hard to trust you with
secrets. Now we have new friends who do the cha-cha twenty times a
day and learned counting from some French mathematician. We just
don't have room for you anymore.

BUG= 375342 

Review-Url: https://codereview.chromium.org/2030263002
Cr-Commit-Position: refs/heads/master@{#398044}

[modify] https://crrev.com/6a260681b771e1042386d09d0fc4b31148030640/chrome/browser/policy/configuration_policy_handler_list_factory.cc
[modify] https://crrev.com/6a260681b771e1042386d09d0fc4b31148030640/chrome/test/data/policy/policy_test_cases.json
[modify] https://crrev.com/6a260681b771e1042386d09d0fc4b31148030640/components/error_page_strings.grdp
[modify] https://crrev.com/6a260681b771e1042386d09d0fc4b31148030640/components/ssl_config/ssl_config_prefs.cc
[modify] https://crrev.com/6a260681b771e1042386d09d0fc4b31148030640/components/ssl_config/ssl_config_prefs.h
[modify] https://crrev.com/6a260681b771e1042386d09d0fc4b31148030640/components/ssl_config/ssl_config_service_manager_pref.cc
[modify] https://crrev.com/6a260681b771e1042386d09d0fc4b31148030640/net/socket/ssl_client_socket_impl.cc
[modify] https://crrev.com/6a260681b771e1042386d09d0fc4b31148030640/net/socket/ssl_client_socket_unittest.cc
[modify] https://crrev.com/6a260681b771e1042386d09d0fc4b31148030640/net/ssl/ssl_config.cc
[modify] https://crrev.com/6a260681b771e1042386d09d0fc4b31148030640/net/ssl/ssl_config.h

Components: -Security>UX
Labels: Team-Security-UX
Security>UX component is deprecated in favor of the Team-Security-UX label

Sign in to add a comment