What is the impact of removing TLS_RSA_WITH_RC4_128_SHA from my server's cipher suite?

Question

I run a website that supports many clients via webservices. I'm setting up some new certificates and load balancers and when doing ssllabs's server test, it's flagging all my ciphers as OK except TLS_RSA_WITH_RC4_128_SHA. What would be the impact of removing this cipher? In other words, what clients might have issues connecting without it? I still have clients running some older stacks like WebSphere and Java 1.6.

Answer 1

The overall cipher suite determines compatibility, not the presence or absence of one cipher. You'll need to test different configurations to find out.

If you're already doing SSL Lab's server test, then that's your best resource for determining the impact of the change. When you say you're

setting up some new certificates and load balancers

that suggests that you can experiment with changes to these systems because they aren't in production use yet. So remove TLS_RSA_WITH_RC4_128_SHA and re-run the SSL Server Test and pay attention to the Handshake Simulation section of the results. That will tell you which clients will have problems, like the following config where IE 6 on XP is unable to work with my cipher suite:

Now, that server has RC4 completely disabled, and the only two clients that are incompatible are IE 6 on XP and Java 6u45 - but Java failed because "Client does not support DH parameters > 1024 bits", not "Protocol or cipher suite mismatch" which is what I'd expect to see if the lack of RC4 was the problem.

SSL Labs is an awesome tool because it allows you to play with different configurations to get the balance of security and compatibility you need. Based on my results, I suspect you can get by without RC4 (my server's increased DH requirements are relatively new to Apache, for example). But this is really a case of YMMV. You might want to use cipherli.st to guide you in trying out new configs.

Answer 2

cipher suites have well understood security properties such as TLS RSA WITH RC4 128 SHA that uses RSA for key exchange, 128-bit RC4 for bulk encryption, and SHA for hashing.

on the other hand:

The BEAST attack is an old academic weaknesses which has recently been demonstrated to be applicable in practice. It requires that the attacker spies on the link and runs hostile code on the client (and that code must communicate with the external spying system); the BEAST authors have managed to run it when the hostile internal code uses Java or Javascript. The generic solution is to switch to TLS 1.1 or 1.2, which are immune. Also, this concerns only block ciphers in CBC mode.

If the BEAST attack may apply to your users don't remove it but it is better that use another strong cipher suite because :

RC4 as a stream cipher is immune to BEAST attack. Therefore, RC4 was widely used as a way to mitigate BEAST attack on the server side. However, in 2013, researchers found more weaknesses in RC4. Thereafter enabling RC4 on server side was no longer recommended.

Answer 3

AIUI if you want to support IE 6 then you basically have to support at least one of TLS_RSA_WITH_RC4_128_SHA or TLS_RSA_WITH_3DES_EDE_CBC_SHA .

Both have their problems. RC4 has severe keystream bias issues. CBC has been hit by padding and IV related attacks (BEAST, POODLE etc).

The general consensus at the moment seems to be that if you need to support IE 6 then TLS_RSA_WITH_3DES_EDE_CBC_SHA is a lesser evil than TLS_RSA_WITH_RC4_128_SHA