Qualys Community

Ivan Ristic

RC4 in TLS is Broken: Now What?

RC4 has long been considered problematic, but until very recently there was no known way to exploit the weaknesses. After the BEAST attack was disclosed in 2011, we—grudgingly—started using RC4 in order to avoid the vulnerable CBC suites in TLS 1.0 and earlier. This caused the usage of RC4 to increase, and some say that it now accounts for about 50% of all TLS traffic.

Last week, a group of researchers (Nadhem AlFardan, Dan Bernstein, Kenny Paterson, Bertram Poettering and Jacob Schuldt) announced significant advancements in the attacks against RC4, unveiling new weaknesses as well as new methods to exploit them. Matthew Green has a great overview on his blog, and here are the slides from the talk where the new issues were announced.

At the moment, the attack is not yet practical because it requires access to millions and possibly billions of copies of the same data encrypted using different keys. A browser would have to make that many connections to a server to give the attacker enough data. A possible exploitation path is to somehow instrument the browser to make a large number of connections, while a man in the middle is observing and recording the traffic.

We are still safe at the moment, but there is a tremendous incentive for researchers to improve the attacks on RC4, which means that we need to act swiftly.

What We (SSL Labs) Will Do

  • Start warning our users about RC4 weaknesses. RC4 is demonstrably broken and unsafe to use in TLS as currently implemented. The difficulty is that, for public web sites that need to support a wide user base, there is practically nothing 100% secure they can use to replace RC4. We now have no choice but to accept that, no matter what settings we use, some segment of the user base will be at risk.
  • If Apple were to implement 1/n-1 record splitting in their stacks (the only major browser vendor that hasn’t done that yet*), we’d likely consider BEAST sufficiently mitigated client-side, and that would allow us to start recommending CBC suites over RC4. Update: Apple implemented BEAST mitigations in OS X Mavericks in October 2013. This means that BEAST can generally be considered mitigated. Fore information, read the follow-up blog post.
  • Start recommending the use of GCM suites. Browsers will no doubt provide better support for TLS 1.2 and GCM suites at an accelerated schedule, and site operators should be ready to take advantage of that.
  • Update SSL/TLS Deployment Best Practices with new information.
  • At some point in the near future, update the rating algorithm to take the RC4 weaknesses into account.

Recommendations

SSL/TLS Library developers

  • Harden the stack against the Lucky 13 attack.
  • Support TLS 1.2 and GCM suites as soon as possible.

Browser vendors

  • Support TLS 1.2 and GCM suites as soon as possible.
  • Implement 1/n-1 record splitting to make CBC suites safe in TLS 1.0 and earlier. As far as we are aware, Apple is the only remaining vendor that has not patched their browsers, either on OSX or iOS.

System administrators

  • Disable TLS compression. This attack is similar in nature to the recent RC4 attacks, but practical.
  • Support TLS 1.2 and GCM as soon as possible.

TLS Working Group

  • Restore algorithm agility and diversity in TLS. AES GCM suites are now the only truly secure option in TLS, but we shouldn’t count on them to stay like that forever.
  • Consider introducing other stream ciphers to the standard. Algorithm agility, which TLS already provides, is not sufficient if there is only one choice for a component.
  • Consider changing how CBC is implemented in order to address the timing issues.

Application developers

  • Harden session management to support reliable and frequent rotation of session cookies, triggered by elapsed time or the number of requests observed. Recent years have seen a rise in attacks that require attackers to control the client end of a TLS connection in some fashion. Most such attacks focus on extracting small bits of information, typically credentials. Session cookies are now the most popular target. Given how many requests are needed for the best attacks to succeed, rotating session cookies frequently is a good defense in depth measure.

38 responses to “RC4 in TLS is Broken: Now What?”

  1. Hello Ivan,

    I have been doing some tests with apache 2.2.24 and openssl 1.0.1e

    What I found is that if I use this configuration as recommended in previous blog entries:

    SSLEngine on

    SSLProtocol -ALL +SSLv3 +TLSv1 +TLSv1.1 +TLSv1.2

    SSLHonorCipherOrder On

    SSLCipherSuite ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:RC4:HIGH:!MD5:!aNULL:!EDH

    SSLCompression off

    my sites gets an A rating but it states This server uses RC4, which has recently been found to be weak.

    If I use this configuration disabling RC4 as show below:

    SSLEngine on

    SSLProtocol -ALL +SSLv3 +TLSv1 +TLSv1.1 +TLSv1.2

    SSLHonorCipherOrder On

    SSLCipherSuite ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:HIGH:!MD5:!aNULL:!EDH:!RC4

    SSLCompression off

    Then I get capped at B because it says it is affected by BEAST.

    What to do ?

    • Sebastian,

      At this point, the RC4 warning is only for you to be aware of the potential issues with RC4. If you’re already deploying GCM suites, then you’re doing everything you can. We need to see how the situation will develop in the following months.

  2. which means that we need to act swiftly

    Well, there is your problem, it has been all the time. Deployment of new protocols/software is slow, really slow. And unless anything industry wide happends like with the DNS Kaminsky Attack I doubt a lot will happen or change.

    At least with the quick fox for the Kaminsky Attack it could be deployed on the server. With this, you probably need to update the client. If you start rallying the troops now, there might still be a chance of something ever getting deployed in time.

  3. Ivan,

    As you correctly noted, we need to choose between addressing BEAST or disabling RC4. I read that the balance for you tips to addressing beast currently, which is surely defendable, but a fair point can be made the other way, to give maximum protection to those with modern clients at the cost of small exposure for older Apple platforms.

    In any case, I believe that in the SSL Server Test, the current grade capping in  to "B" when your server is beast-vulnerable is not fair anymore – there are good reasons nowadays to disable RC4, and while the test should obviously warn against both RC4 and beast, capping the grade to B for beast seems overly discouraging for migrating away from RC4 at this point. Would you consider to remove that?

    Cheers,

    Thijs

    • Thijs,

      It’s a close call, but largely because neither BEAST nor RC4 issues are likely to be exploited. I prefer to make decisions based on available data. At the moment, for example, 18% of (unique) connections made to SSL Labs are vulnerable to BEAST. I think that’s a fairly large number of genuinely vulnerable clients.

      Forgetting RC4 for a moment, do you think a site that does not mitigate a vulnerability against a large chunk of the user base deserves an A? I don’t. (Of course, exploiting BEAST is difficult, which is why we’re probably not going to see any attacks.)

      On the other hand — and as far as we know — RC4 is still secure in practice. So why the desire to get rid of it, when the only way to do it is to introduce some other vulnerability?

      I think your concerns regarding the use of RC4 will ease as more browsers start to use TLS 1.2. I understand that both Chrome and Firefox have been working on this for some time now.

      Personally, I am looking forward to the day that we’ll retire BEAST as a problem.

      • I know, it’s been quite a while, but…

        Using Debian 7.1/Apache 2.2, I cannot manage to get rid of BEAST-vulnerability AND use Forward Secrecy (FS) in Handshake Simulation.

        When I use

        SSLHonorCipherOrder On
        SSLCipherSuite RC4-SHA:HIGH:!ADH

        or

        SSLCipherSuite DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:RC4:HIGH:!MD5:!aNULL:!ADH

        there is no BEAST-vulnerability – but also no FS during Handshake.

        When I use

        SSLCipherSuite HIGH:MEDIUM:!MD5:!aNULL:!ADH

        there is FS but also BEAST-vulnerability.

        Ivan Ristic schrieb:

                               

        So why the desire to get rid of it, when the only way to do it is to introduce some other vulnerability?

        So it is not possible to get both working?

        Thanks,

        Hein

    • icnseo,

      You can configure your site to be the same as paranoidsecurity.nl by doing supporting only TLS 1.2 in your server (and using the same cipher suite configuration). However, do note that most browsers then won’t be able to connect to your site (because they don’t yet support TLS 1.2).

  4. Ivan,

    On the issue of BEAST.

    You don’t think by the time the improvements finally have been deployed it will be vulnerable to other attacks again shortly after ?

    I guess the root problem is that we need frequent updates.

    For example take the large number of people still running IE on Windows XP it is stagering, this is especially true in businesses. I see figures like more than 20% to 30% of IE users are still on Windows XP. Which means no updates. More than 10% of that share is also still not using IE8.

    I do see more and more higher-profile sites starting to deploy SNI that is at least a start.

    • The configurable nature of SSL/TLS is quite powerful, but it obviously does not work as intended/desired across a large and diverse user base. I think software vendors should have actively managed SSL configurations from the start (e.g., by default, your operating system controls your configuration, but you can opt-out if you wish to manage it yourself.) But that’s probably a responsibility vendors don’t want to take on themselves.

      With that in mind, perhaps a better protocol design is to allow a limited set of features, with limited ability for tweaking. With that approach, flaws could be addressed by patching (which is well understood).

  5. I don’t think it’s the protocol design, I think it is more likely library/API design.

    If the API is highlevel/small (very few functions) than the library can be updates frequently without breaking the applications that use it.

  6. Hi Ivan,

    I would like to know if you have any Idea about the relationship between weak certificate "weak KeyExchange and Cipher stregnth" and communication between two Federated servers on Lync .

    I happen to notice that I usually have problems communicating with partners who only have weak certificates after scanning them on your site.

    could this be related?

    Usually the error messages that’s shown when diagnosting the problem shows "Failed to complete TLS negotiation with a federated peer server sip.domain.com

    Would appreciate your participation.

    • It would be helpful to see a couple of examples. It’s pretty rare to see servers that have only weak ciphers enabled. But, in general, if the two parties cannot agree on a cipher suite to use, the communication will fail.

      Some of the reasons could be: 1) no overlapping cipher suites or 2) suites whose DH parameters are weak (this cannot be determined ahead of time)

      It’s hard to say without lots of troubleshooting, though. The message you provided does not point to the root cause; only the outcome.

  7. Thanks for your reply Ivan,

    Most of the message that I can see either in Wireshark or in Lync Logs are indicating failure of TLS negotiation between both servers, so I’m thinking of importing the root Certificate Authority of Global sign as my partners certificate was generated from GS.

    I have seen some stories similar to mine where the problem was solved after the partner import the faulty partner’s Root CA in his edge server.

    I hope this solve the case.

    M

  8. So, first and foremost, I’m not a crazy huge crypto guy, and I definitely lack the math skills to fully understand the full scope of cryptography. So, I take advice from trusted sources.

    I subscribe to Matthew Green’s blog, as he is one of those trusted sources.

    I’ve been reading for a while, and he has long stated that no one should have ever tried to use RC4 as an alternative to the BEAST attack 

  9. Found that the configuration below (on Apache 2.4.4 / OpenSSL 1.0.1e) gives you the following results:

    BEAST attack Not vulnerable
    Compression No
    RC4 Yes   PROBLEMATIC (more info)
    Forward Secrecy Yes (more info)

    SSLCipherSuite AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-RC4-SHA:ECDHE-RSA-AES128-SHA:RC4:HIGH:!MD5:!aNULL:!EDH

    SSLHonorCipherOrder On

    Must say that I find it strange to see BEAST at not vulnerable:

    Internet Explorer 10 TLS 1.0 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)  Forward Secrecy 128

    is coming back under Handshake simulation.

    • Well, you could say that it is a flaw in how we test for the BEAST vulnerability. When the test was originally designed, people rarely prioritized for forward secrecy and the goal of the test was only to determine if RC4 is prioritized. To do this, we have a basket of cipher suites that we test with, and we put RC4 at the end of the list. When a server negotiates RC4, we know it likes RC4.

      These days people are prioritizing for both forward secrecy and RC4, whch means that the _exact_ suites supported by a particular browser matter. With the handshake simulator, we can test for BEAST vulnerability with specific browsers, and we may move to that, but we’re not there just yet.

      And, as you say in the second message, IE implemented the 1/n-1 split so, technically, it is not vulnerable to BEAST.

      • That would then mean that the BEAST vulnerability is a scoring system, checking which major browsers are available and what their status is instead of just a Yes / No question?

        Reading all the above (and more) would BTW implicate that if there would be a "one-size-fits-all" solution you would need to enforce it on the server end as browsers will always have a huge set of supported protocols and all, but on that end it would be almost impossible to deny usage of what the browser offers. On the server end you have more ways to configure in a proper way.

        Think that the biggest issue to abandon usage of RC4-128 is the face that WinXP is still used. And only when that OS is combined with IE. It does however cripple rollout strategies as WinXP will be supported from Microsoft through 2014. Taking XP out of the equasion would get you forward with supporting forward secrecy.

  10. Possibly thought of the solution already, which is what the article itself is about: 1/n-1 record splitting

    Initially I had the following config:

    SSLCipherSuite AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-RSA-RC4-SHA:RC4:HIGH:!MD5:!aNULL:!EDH

    SSLHonorCipherOrder On

    Bold items were switched compared to the config I posted earlier. Now this of course meant that all browsers, including Safari and iOS browsers were using TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA as handshake. As Apple browsers still have no record splitting implemented, suddenly the marker for BEAST was vulnerable.

    So effectively I am currently using protocols that are vulnerable to BEAST, but as IE10 is using record splitting the overall result seems to be not vulnerable.

    All in all I think the earlier posted config gives one of the best possible results in the SSLLabs scan. Used protocols are all very secure and still in the 128-bit class, leaving enough room for computations. Scores do 100 / 90 / 90 / 90, resulting in A.

    EDIT: Config is based on Apache 2.4.4 / OpenSSL 1.0.1e and results with above config will vary per version.

    For functional reasons we are required to still use SSLv3 (as there are still WinXP users that have the default IE config with only SSLv2 / SSLv3 enabled and TLSv1 disabled), but that problem will resolve over time.

    Now of to remove older ciphers, like RC4-128 and see what will happen. WinXP should be able to connect via at least 3DES. Need to have a handshake simulator myself to properly work this one out.

  11. Hello

    My site get an A rating but it states This server uses RC4, which has recently been found to be weak.

    I try  disable RC4 but after scan i get rating B because it is affected by BEAST.

    Anyonw know what is right configuration to avoid A and B?

    Thanks

    • Today, it’s not possible to configure your SSL/TLS server in such a way to avoid all the problematic ciphers. Once client-side support of TLS 1.2 improves, supporting TLS 1.2 on the server with GCM suites should be the right way. But even then you might still need to support RC4 for SSL 3.0 and TLS 1.0.

  12. Hi there,

    I am gonna go mad. I´ve done all the things what is telling here. But I can´t get my apache2.2.14 (ubuntu 10.04 lts) running with forward secrecy. I have been rated as "A" (100-90-90-90). Maybe the reason is that I can´t run my apache with TLS 1.1/TLS 1.2 ?

    Right now I am using

    SSLProtocol -ALL +TLSv1

              SSLCipherSuite AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-RC4-SHA:ECDHE-RSA-AES128-SHA:RC4:HIGH:!MD5:!aNULL:!EDH

              SSLHonorCipherOrder On

    SSLCompression is set off in httpd.conf.

    Any expert around to give me an advice ?

    Thanks

    Oliver

    • Many have run into the same problem, which is that Apache 2.2.x does not support ECDHE suites. (I am talking about stock Apache; there’s a small chance that Ubuntu’s had been patched to add the support, but I don’t think that’s likely.)

      To support ECDHE suites, which are practically required for forward secrecy, you need to upgrade to Apache 2.4.x. In your case, that might require compiling Apache from source.

      • Ubuntu has indeed not patched their Apache 2.2 for ECDHE.

        I’ve been pushing a bit to get ECDHE also applied at Apache upstream’s 2.2.x branch. It hasn’t happened yet, though.

        Good news is that as of today Apache 2.4 is in Debian testing, making it available to a significantly larger user base than before.

  13. So,

    All the major browsers have mitigations, since most website still use TLS 1.0, and many will

    priorities AES ciphers. So there is no problem with this anymore?

    • There’s nothing ironic about it. It’s configured like that in order to mitigate the BEAST attack. Given that BEAST is on the way out and RC4 on the way in, however, the configuration is likely to change soon.

  14. I’ve tried repeatedly to disable RC4 ciphers in my Apache configuration, but the SSL test is still saying "This server accepts the RC4 cipher, which is weak. Grade capped to B." It lists these ciphers specifically:

    • TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011)
    • TLS_RSA_WITH_RC4_128_SHA (0x5)
    • TLS_RSA_WITH_RC4_128_MD5 (0x4)

    I’ve disabled SSLv3 (and 2, of course). And here are my cipher suites in Apache config:

    SSLCipherSuite "ECDH+AESGCM DH+AESGCM ECDH+AES256 DH+AES256 ECDH+AES128 DH+AES ECDH+3DES DH+3DES RSA+AESGCM RSA+AES RSA+3DES !aNULL !MD5 !DSS !RC4"

    Any ideas on why the test insists RC4 is enabled?

  15. I’ve disabled RC4 and continue to get the "server accepts the RC4 cipher" message as well.

    SSLCipherSuite ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4

  16. Success!  I just received an A+ (100, 95, 90, 90) with the following configuration:

    Debian 7, 64-bit, Apache2 (2.4.10), Openssl (1.0.1i).  Then, following guidance at:

      Configuring Apache, Nginx, and OpenSSL for Forward Secrecy

    I used that configuration but removed RC4 to yield:

    SSLProtocol all -SSLv2 -SSLv3

    SSLHonorCipherOrder on

    SSLCipherSuite "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM \

                    EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 \

                    EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 \

                    EECDH EDH+aRSA \

                    !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS !RC4"

    If you’re still running Apache 2.2 and an old Openssl you’re not in the ball game!

    Thanks to Ivan’s suggestions in his books for statically linking openssl with apache, I will always keep Apache and Openssl very current and always build from the latest source (I’m in the process of upgrading now on a new server).  I’m happy to provide my Apache and Openssl configure scripts.

Leave a Reply