SSL Labs RC4 Deprecation Plan
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:
- If you want the best grade, don’t use RC4. This is the only recommended option.
- 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.
- 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.
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…
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?
Indeed! And there are many servers that support 3DES after RC4.
SSL Server Test: seal.qualys.com (Powered by Qualys SSL Labs)
SSL Server Test: browsercheck.qualys.com (Powered by Qualys SSL Labs)
SSL Server Test: cbs.com (Powered by Qualys SSL Labs)
Here is the irony: after disabling the fastest cipher, I use the slowest one. Now let the DoS begin, muhahaha!
you can also just support 3DES at the top level and then switch to RC4 for a subdirectory… for example, https://hotaru.thinkindifferent.net/downgrade downgrades to RC4 if possible.
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:
this is terrible. don’t do this.
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.
Firefox 37, fallback:
Firefox 40 (development):
Internet Explorer 11 on Windows 10 Technical Preview (NT 6.4 build 9841), supports as a fallback and even downgrades to TLS 1.0:
Same for NT 10.0 build 10041:
> 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.
You are right, it hasn’t. The explanation is here: https://blog.qualys.com/ssllabs/2015/09/11/new-penalty-for-rc4-only-servers-in-october-2015