Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I know that the RC4 cipher when used with SSL is vulnerable to certain attacks, which in the worst case scenario could result in authentication tokens being stolen. But RC4 is also recommended as a cipher to mitigate the BEAST attack.

Is it a better strategic decision, to disable RC4 and perhaps be vulnerable to BEAST, or protect against BEAST and protect against the attack RC4 is vulnerable to?

share|improve this question
Most modern browsers have BEAST mitigation built in, so I'd prefer AES-CBC over RC4. –  CodesInChaos Dec 14 '13 at 14:59
Use TLS 1.1 and above and you should be safe to choose any ciphers. –  jingyang Dec 14 '13 at 16:50
add comment

3 Answers

BEAST vulnerability has been worked out client-side, so it's no longer an issue with modern browsers.

RC4 is a weaker cipher than others since it's been shown to have a slight bias, but if used carefully and appropriately, there are no successful attacks against it.

You can't get any safer than safe; if your encryption can't be broken, then it doesn't really matter how much more it can't be broken. So in that sense, there's no compelling reason to avoid the cipher.

That said, there's no sense using a biased cipher when others are available. So going forward, you might as well prefer something else. The primary reason why RC4 is so persistent is that it's the last true stream cipher in use, making it useful for people who want to avoid thinking about block chaining. Secure block ciphers are hard enough to invent; but stream ciphers are on a whole new level, so it's not likely we'll see another.

Most likely RC4 will continue to stick around; there is no compelling direct replacement. I wouldn't prefer it, but I would expect to continue to see it.

share|improve this answer
Isn't ChaCha20 a stream cipher? And more secure than RC4 at that? –  cnst Dec 25 '13 at 1:55
@cnst I meant in mainstream usage, not simply in whitepapers. Few of DJB's inventions have gotten much traction; this is no exception. –  tylerl Dec 25 '13 at 7:04
@tyleri: Google would like to use ChaCha, see http://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-00. Overall, ChaCha seems like it is possibly replacing some uses of RC4. The problem with true stream ciphers is that they are rarely able to offer significant advantage over AES-CTR. –  user4982 Jan 25 at 11:10
add comment

In any case, the client suggests but the server chooses. On the client side, you can specify that you prefer to use AES if possible, but if the client supports RC4 and the server wants to use RC4 if possible, then RC4 it will be. This implies that you cannot really "use RC4 as a last resort" (unless the client code does some trickery, which I don't believe mainstream SSL clients implement; namely not announcing RC4 support, unless previous connection attempts with other cipher suites have failed).

One way to look at it is that RC4-protected SSL is way better than no SSL at all. Another way is that whatever you do on the client, the server cannot be abstracted away; you are entrusting the server with your confidential data. The choice of the cipher suite is the server's responsibility, and if the server does not apply appropriate cipher suites (from your point of view) then maybe you should not send the data at all to such a careless server...

Known weaknesses of AES-CBC (the BEAST attack) don't work anymore if your client (Web browser) is up-to-date (and it really should !). Known weaknesses of RC4 don't seem to work in a Web context (because weakness exploitation requires millions of connections, and that takes time -- moreover, the first few hundred bytes of each request contain HTTP headers which are mostly uninteresting to the attacker). So it can be said that: RC4 or not RC4, that is not the question. Whether you disable or enable RC4, this is very unlikely to be the biggest security vulnerability, or even a significant vulnerability.

However, it may make sense to disable RC4, or to disable AES-CBC, in order to comply with some inflexible regulations, or to increase some (very artificial) "security mark" that some auditors seem very fond of, for reasons which have more to do with psychology than cryptography.

share|improve this answer
add comment

A lot of the people recommending RC4 to prevent BEAST have recanted because of the attacks on it; the correct and forward-looking solution is updating your software to the TLS 1.1 spec.

Strategically, your options depend on your abilities. If you are allowed to dictate the user agents connecting to your service, or willing to accept that your user agent might be unable to connect to some services if that makes it more secure, require TLS 1.2 support.

There is very little that can meaningfully be done to protect users who use outdated software with known vulnerabilities. This includes people running user agents still capable of no better than SSLv3 and without support for GCM modes.

Cipher suites are negotiated in a priority order. Since some people might still be following the old advice to prefer RC4 in order to mitigate BEAST, it's likely a good choice to disable RC4, especially if your (or your users') user agents are up to date.

Given that practical attacks have been demonstrated with similar prerequisites both for BEAST and RC4, the choice is otherwise equal.

share|improve this answer
add comment

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.