SSL Labs RC4 Deprecation Plan

Ivan Ristic

Last updated on: September 6, 2020

Nobody wants to use RC4. This well known stream cipher would have been retired long time ago if it weren’t for several critical problems in SSL and TLS, problems that affect block ciphers only–for example, BEAST, Lucky 13, and POODLE. So RC4 ended up being the lesser evil.

Take BEAST, for example. There are mitigations for it (the so-called 1/n-1 split) in all major browsers, but there’s also potentially a large number of users who are not updating their browsers (or operating systems). For POODLE, on the other hand, we don’t have a workaround. Those who can disable SSLv3 are lucky, because they don’t have to worry about this problem. Anecdotally, there are still many companies that can’t do that. Small sites usually don’t have to worry about these problems, but, for large companies, the worry is about the long tail of vulnerable clients.

So it seems that we have two large groups: in one corner are users with modern software. They support TLS 1.2 and modern cipher suites. They are safe. In the other corner we have those with old SSL/TLS stacks, who support TLS 1.0 at best; some of them might be vulnerable to the BEAST attack, and most of them to POODLE as well. At SSL Labs, we want to fully deprecate RC4, but we don’t want to penalize those who continue to need this cipher to support old clients. After all, there are no publicly-known feasible attacks against RC4, but there are such attacks for BEAST and POODLE.

At the moment, when a server offers RC4, we cap the grade at B, because we deem that the server supports an undesirable encryption algorithm. Although it might be all right to continue to use RC4 in some cases, it’s only fair to give a better grade to those servers that do not use it.

In the future, we’re going to start differentiating between servers that use RC4 with everyone and those that use it only with older clients. If you’re using RC4 only with SSL 3 and TLS 1.0, your grade will continue to be capped at B. However, if you’re using RC4 with TLS 1.1 or a better protocol, the penalty will be harsher.

In order to give time to server operators to act, we will increase the penalty in two steps. The first change will be in May, about one month from now, when we will start penalising servers that use RC4 with modern clients. They will be capped at C (now B). Several months after that (tentatively September), we will increase the penalty to F.

To sum up:

  1. If you want the best grade, don’t use RC4. This is the only recommended option.
  2. If you feel that you need to continue to use RC4 for older clients, you’ll get a B if you properly configure your systems.
  3. Otherwise, the penalty for using RC4 with modern clients (TLS 1.1+) will increase to a C in about one month, and then an F in a couple of months after that.
Show Comments (8)

Comments

Your email address will not be published. Required fields are marked *

  1. will there be any additional penalty for RC4-only servers, or will servers that don’t support anything but TLS 1.0 and RC4 still get a B? if they do still get a B, that might encourage people to disable TLS 1.1 and 1.2 completely to go from C or F to B (or from F to C with SSL 3 enabled), which is not good…

  2. It would be worth mentioning that 3DES can replace RC4 to support legacy (pre-AES) clients.  It suffers from the same CBC related issues as AES, and it’s also very slow, but if the goal is backwards compatibility, 3DES should still be a better choice than RC4?

    Or do you think TLSv1.2-only GCM ciphers followed by RC4 is still a better choice?

      1. and, after a bit of experimenting:

        SSL Server Test: thinkindifferent.net (Powered by Qualys SSL Labs)

        A+, but IE on XP ends up using RC4.*

        edit: actually, is possible to make IE on XP just negotiate RC4 directly, while having RC4 disabled for any clients that support SNI.


        *

        it’s actually a bit more complicated:

        • IE connects and offers RC4 and 3DES
        • server chooses 3DES
        • IE sends 3DES-encrypted HTTP request
        • server initiates renegotiation and chooses RC4
        • server sends RC4-encrypted HTTP response

        this is terrible. don’t do this.

  3. Server for testing whether a client support RC4 — rc4.serverhello.com

    Tracking RC4-only case treatment:

    Production — SSL Server Test: rc4.serverhello.com (Powered by Qualys SSL Labs)

    Development — SSL Server Test: rc4.serverhello.com (Powered by Qualys SSL Labs)

    SNI is required, so obsolete clients will get fatal alert, but those users have bigger problems to worry about anyway.

    Chrome 42:

    rc4-chrome42

    Firefox 37, fallback:

    rc4-firefox37

    Firefox 40 (development):

    rc4-nightly40

    Internet Explorer 11 on Windows 10 Technical Preview (NT 6.4 build 9841), supports as a fallback and even downgrades to TLS 1.0:

    Windows 10 64-bit-2015-04-24-00-00-46

    Same for NT 10.0 build 10041:

    Windows 10 64-bit-2015-04-24-01-39-28

  4. > The penalty for using RC4 with modern clients will increase to a C in about one month, and *then an F in a couple of months after that*.

    This hasn’t happened.