6

I read a lot of issue [1] currently stating that RC4 is broken and is at risk.

I just checked my web server (nginx) and it is using the default settings, which is

DHE-RSA-AES256-SHA

How does this Cipher compare to the RC4?

Is it slower (I think so) But it is more secure?

[1] http://blog.cryptographyengineering.com/2013/03/attack-of-week-rc4-is-kind-of-broken-in.html

Howard
  • 273
  • 1
  • 2
  • 6
  • In TLS 1.0 a CBC suite like this can be vulnerable to BEAST, but it's fixed in most browsers. – CodesInChaos Mar 22 '13 at 09:42
  • Ar you really only running a single cipher set on your server - or is that just the one which was negotiated with your browser? – symcbean Mar 22 '13 at 09:56
  • Cryptographically "broken" and just plain "broken" are different things, the former is usually taken to mean "less than brute force" (which can still be improbably expensive to achieve). – e-sushi Sep 26 '13 at 00:25

1 Answers1

6

Cryptographically "broken" and just plain "broken" are different things, the former is usually taken to mean "less than brute force" (which can still be improbably expensive to achieve).

Aside from the fact that two ciphers, AES and RC4, are different internally (CBC block cipher, and stream cipher respectively), the observable differences are that AES-256 is 256-bit, and not as fast (as you correctly suggest) as 128-bit RC4. Speed is sometimes a reason cited for Google preferring it. The "DHE" part means ephemeral Diffie–Hellman, which offers PFS, generally a good thing. Both AES and RC4 support SHA-1 and MD5 for message integrity checking, the former is preferred (one or other must be used, prior to TLSv1.2 which added more algorithms).

Thomas Pornin very neatly sums up both the RC4 and BEAST issues here:

The RC4 vulnerability allows for the most of the first 256 bytes of a connection to be accurately guessed with at least the conditions that:

  • the recoverable content must be the same for the duration of the attack
  • the attacker must capture a lot of traffic, some 224—232 of useful packets (which he can distinguish as start of a session)
  • the guessed content is still useful (i.e. HTTP session cookie) when he's done
  • the SSL session key is not recovered, only partial content

A quick back-of-the-envelope calculation indicates if you could saturate a wifi link (say 20Mbps) with ideal traffic you'd be looking at ~2 hours for the first 3-4 bytes recovered, and around 10 days for near-complete recovery of the first 256 bytes. (This is just factoring in bandwidth, the CPU requirements of the analysis are negligible.)

This issue with RC4 is quite old, it's only the quantification of the biases that is new.

I recommended AES ciphers over RC4 (BEAST is a client side issue, if the user still has a vulnerable browser at this point in time there are likely bigger problems to solve).

Although some of these issues are (IMHO) hyped a bit much, the best outcome is more progress toward uniform client and server support for TLSv1.1 and later. Around the time the BEAST was published, support was quite poor.

Community
  • 1
mr.spuratic
  • 7,937
  • 25
  • 37
  • 1
    For the ideal attack scenario, CPU will not be an issue (we can assume that all these connections will use the "abbreviated handshake" which reuses the same master key) but latency will: each new connection requires one roundtrip for the handshake, then one for the actual data. The ideal attack scenario supposes that the target opens a lot of connections in parallel, which the attacker repeatedly force-close, and the victim automatically reopens, resending the same secret data each time. – Thomas Pornin Mar 22 '13 at 11:22
  • Nitpick: although SSL/TLS architecture could support any pre-AEAD (TLS1.2) symmetric cipher with any HMAC, there are defined suites for RC4 with either MD5 or SHA1 but AES only with SHA1. AES was added by RFC3268 in 2002, and by then SHA1 was widely implemented. This doesn't affect the rest of the argument or the conclusions. – dave_thompson_085 Jul 05 '14 at 08:27