RC4 cipher considered harmful?

There is a slightly disturbing announcement of a coming talk at Blackhat Asia in March, claiming a new break in RC4-based SSL cipher suites. I’ve reproduced it here in its entirety:

BAR-MITZVA ATTACK: BREAKING SSL WITH 13-YEAR OLD RC4 WEAKNESS

RC4 is the most popular stream cipher in the world, and in particular is used to protect a significant portion of SSL/TLS sessions. In this session, we will show how an old vulnerability of RC4 can be used to mount a partial plaintext recovery attack on SSL-protected data, when RC4 is the chosen cipher. As opposed to BEAST, POODLE, CRIME, and other attacks on SSL that were published in the recent years, including the attack by Bernstein et-al on the usage of RC4, the new attack is not limited to recovery of temporal session tokens, but can be used to steal parts of permanent secret data such as account credentials when delivered as POST parameters. Furthermore, one of the variants of the new attack requires only passive eavesdropping to SSL connections, and presents the first practical attack on SSL that does not require active Main-in-the-Middle. Another unique characteristic of the new attack allows one of its variants to recover with non-negligible probability, parts of a secret that was transmitted only once over the TLS connection.

https://www.blackhat.com/asia-15/briefings.html#bar-mitzva-attack-breaking-ssl-with-13-year-old-rc4-weakness

Now, we haven’t seen the details of the vulnerability itself, but it looks like one mitigation would be to modify the web server to enable as many as possible of the preferred ciphers in each browser’s list before you get down to RC4. That way, the vast majority of browsers will negotiate a safer cipher suite, so at least an active attack would be needed to exploit it, rather than purely passive. In my limited testing, RC4 is either not in the browser’s list, or at the bottom in preference order, so enabling any of the new TLS1.2 ciphers apart from the RC4 ones should help in this regard.

However, to fix completely, you would need to disable RC4 on the server (and/or on all clients if you control them) – but this would need more testing than enabling new cipher suites.

You can check what your current browser supports here: https://cc.dcsec.uni-hannover.de/

This is the list for IE, with the most preferred (strongest) at the top:

ECDHE-RSA-AES128-SHA256
ECDHE-RSA-AES128-SHA
ECDHE-RSA-AES256-SHA384
ECDHE-RSA-AES256-SHA
ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-ECDSA-AES128-SHA256
ECDHE-ECDSA-AES128-SHA
ECDHE-ECDSA-AES256-SHA384
ECDHE-ECDSA-AES256-SHA
DHE-RSA-AES256-GCM-SHA384
DHE-RSA-AES128-GCM-SHA256
RSA-AES256-GCM-SHA384
RSA-AES128-GCM-SHA256
DH-RSA-MISTY1-SHA
DH-DSS-MISTY1-SHA
RSA-AES256-SHA
RSA-AES128-SHA
DHE-DSS-AES256-SHA256
DH-ANON-MISTY1-SHA
DHE-DSS-AES256-SHA
DHE-DSS-AES128-SHA
RSA-3DES-EDE-SHA
DHE-DSS-3DES-EDE-SHA

And for Chrome, in the same order – most preferred (stronger) first:

ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-GCM-SHA256
DHE-RSA-AES128-GCM-SHA256
ECDHE-ECDSA-CHACHA20-POLY1305-SHA256
ECDHE-RSA-CHACHA20-POLY1305-SHA256
ECDHE-ECDSA-AES256-SHA
ECDHE-ECDSA-AES128-SHA
ECDHE-RSA-AES128-SHA
ECDHE-RSA-AES256-SHA
ECDHE-ECDSA-RC4128-SHA
ECDHE-RSA-RC4128-SHA
DHE-RSA-AES128-SHA
DHE-DSS-AES128-SHA
DHE-RSA-AES256-SHA
RSA-AES128-GCM-SHA256
RSA-AES128-SHA
RSA-AES256-SHA
RSA-3DES-EDE-SHA
RSA-RC4128-SHA
RSA-RC4128-MD5

Or Qualys’ excellent test site will give you a good idea of what each browser will negotiate for a given SSL-enabled web server:

https://www.ssllabs.com/ssltest/analyze.html?d=blacktraffic.co.uk&hideResults=on&ignoreMismatch=on&latest

If we take a selection of results from the above, we find that XP-based Internet Explorer may not be able to connect to us at all, but newer version running under Windows 7 are using safe cipher suites.

The particular website is using the following configuration – note that the important bits disable SSLv2 and v3, and enable a particular set of cipher suites in a particular order. Where a suite is preceded by an exclamation mark, anything matching is disabled, so !RC4 disables all RC4 suites.

Of course, this site has no actual users, so I can get away with doing anything I like to the cipher suites. You will have to do some more testing before you disable RC4.

So, at the very least, please make sure that your supported browsers are not negotiating RC4 as far as possible. If you can, try to work towards banning RC4 entirely, however initial testing with the above web server shows that IE6/Win XP won’t connect to it.

If you disable RC4 on the client side, you may well encounter problems, but it might be worth starting to investigate that route as well. This can be done by setting the following registry entries to zero, and rebooting the machine.

• [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 128/128]
  “Enabled”=dword:00000000
• [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 40/128]
  “Enabled”=dword:00000000
• [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 56/128]
  “Enabled”=dword:00000000

See: https://support.microsoft.com/kb/2868725

It will be interesting to find out exactly what the new issue is.