5 ms·

I had assumed that TLS didn't use plain RC4, but rather a variant of RC4 that discards the first several hundred bytes of the keystream to avoid this problem.

by agwa 14y ago

I had assumed that TLS didn't use plain RC4, but rather a variant of RC4 that discards the first several hundred bytes of the keystream to avoid this problem. But I just checked and apparently TLS uses straight-up RC4. Sigh... I'm not sure why people so fervently recommend disabling AES-CBC (and SSLLabs knocks you a whole letter grade if you haven't) when modern browsers and TLS clients work around BEAST with "1/n-1" record splitting [1]. I figure out-of-date browsers are probably vulnerable to something that lets you hijack sessions without needing BEAST anyways. [1] http://www.imperialviolet.org/2012/01/15/beastfollowup.html http://www.imperialviolet.org/2012/01/15/beastfollowup.html

tptacek 14y ago
First, the record split problems caused compat issues. Second, even with the record splitting fix, you still have Lucky 13, which is really annoying to fix completely, and people are wary of deploying a crypto fix to their SSL library that in 5 years we'll just find out was window dressing.
- agl 14y ago
  > First, the record split problems caused compat issues. It did, but I think we're through it now. IE, Firefox and Chrome have all had it on for a while.
  - tptacek 14y ago
    What scares you more: AES-CBC with best-effort fixes for Lucky 13, or RC4?
    - agl 14y ago
      CBC at the moment I think. There's still the possibility of clients without record splitting, there's timing issues in AES itself, there's lots of possibilities for bad server padding implementations. I have TLS 1.2 and AES-GCM working in NSS on my desktop, but we don't currently have the NSS reviewer time to get it landed. We also have to deal with the issue that an active attacker can trigger a version downgrade somehow. (I don't love AES-GCM either, but it's the nearest port in this storm.) In the mean time, I'll probably tweak RC4 in NSS to send one byte records at the beginning of the connection and thus burn off the first 256 bytes of keystream by encrypting MACs. That still leaves a handful of bytes vulnerable, but half of them will be "GET ". But I doubt that's fully sufficient so AES-GCM is the medium term goal.
      - tptacek 14y ago
        Whoah, neat. I didn't realize the RC4 workaround was that straightforward. Easy to forget you still have the record layer when you're using a stream cipher. Thanks, this was an excellent comment.
      - harshreality 14y ago
        Is this what web security is reduced to? On one hand, openssl not releasing TLS 1.2 support for over 3 years until a semi-panic over BEAST generated enough interest to get it done? On the other, major browser vendors not implementing TLS 1.2 (okay, MS did, but disabled by default) for even longer because lack of server support, compatibility issues, or fear of protocol downgrade attacks made it an uninteresting or risky proposition? Nobody was interested enough to say screw chicken-and-egg and simply get it done, on either side? OS maintainers aren't helping either. RHEL/CentOS 6.4, just released, is still stuck with openssl 1.0.0, which doesn't support TLS 1.1 or 1.2, so there's another few years of webservers running an "enterprise" OS not having TLS 1.2 support. But hey, OpenSSL 1.0.0 is "stable"! I guess there's not much hope of getting Salsa20 or ChaCha, and better curves like curve25519 (I see a draft proposing some Brainpool curves), into TLS 1.2? (with the intent of discouraging many of the less desirable ciphersuites after a few years... not adding more ciphersuites just to add more ciphersuites.)
        tptacek 14y ago
        What is the advantage of getting Salsa20 or curve25519 into TLS 1.2?
        aidenn0 14y ago
        djb says they're awesome! But more seriously, salsa is very efficient, so if rc4 is still being used for performance reasons, rather than security reasons, then it would seem to be to be a decent replacement.
        tptacek 14y ago
        RC4 is fast, but it's being used because Google was forced by circumstance to use it.
- agwa 14y ago
  Apparently the compat issues with record splitting have been resolved sufficiently well that all the major browsers have turned it on. Yeah, there's Lucky 13 but you said above that this RC4 vulnerability is unacceptable in a way that Lucky 13 isn't. Basically I'm wondering what the point is in fervently recommending RC4 over AES-CBC when they both suck.
ivanr 14y ago
[I am the author of SSL Labs.] Not all major browsers implement 1/n-1 record splitting. In particular, the last time I checked, Apple did not in Safari and the iOS devices. In that light, downgrading the grade to a B is a reasonable way to indicate that your configuration is not secure for a potentially large portion of the user base. The 1/n-1 split is the main reason that the grade is just reduced and sites are not simply failed (as is the case with insecure renegotiation, for example). The other reason is that the BEAST attack is not exactly easy to execute.
- agwa 14y ago
  Wow, thanks for this reply (esp the info about Safari/iOS). What are your thoughts on the RC4 attack? Do you plan to take it into account in the SSL Labs test?
  - ivanr 14y ago
    Knowing what we know today, attacks against RC4 are not yet practical, and thus there is no reason to panic. But we must act now. Given the huge incentive for researchers to continue to break RC4, it's reasonable to expect that the attacks will continue to improve. Yes, SSL Labs will start to penalize RC4 at some point, but not just yet. Later today we will start warning people about the problems. I've just published the recommendations here: RC4 in TLS is Broken: Now What? https://community.qualys.com/blogs/securitylabs/2013/03/19/rc4-in-tls-is-broken-now-what https://community.qualys.com/blogs/securitylabs/2013/03/19/r...

by agwa 14y ago

tptacek 14y ago

First, the record split problems caused compat issues. Second, even with the record splitting fix, you still have Lucky 13, which is really annoying to fix completely, and people are wary of deploying a crypto fix to their SSL library that in 5 years we'll just find out was window dressing.

agl 14y ago
> First, the record split problems caused compat issues. It did, but I think we're through it now. IE, Firefox and Chrome have all had it on for a while.
- tptacek 14y ago
  What scares you more: AES-CBC with best-effort fixes for Lucky 13, or RC4?
  - agl 14y ago
    CBC at the moment I think. There's still the possibility of clients without record splitting, there's timing issues in AES itself, there's lots of possibilities for bad server padding implementations. I have TLS 1.2 and AES-GCM working in NSS on my desktop, but we don't currently have the NSS reviewer time to get it landed. We also have to deal with the issue that an active attacker can trigger a version downgrade somehow. (I don't love AES-GCM either, but it's the nearest port in this storm.) In the mean time, I'll probably tweak RC4 in NSS to send one byte records at the beginning of the connection and thus burn off the first 256 bytes of keystream by encrypting MACs. That still leaves a handful of bytes vulnerable, but half of them will be "GET ". But I doubt that's fully sufficient so AES-GCM is the medium term goal.
    - tptacek 14y ago
      Whoah, neat. I didn't realize the RC4 workaround was that straightforward. Easy to forget you still have the record layer when you're using a stream cipher. Thanks, this was an excellent comment.
    - harshreality 14y ago
      Is this what web security is reduced to? On one hand, openssl not releasing TLS 1.2 support for over 3 years until a semi-panic over BEAST generated enough interest to get it done? On the other, major browser vendors not implementing TLS 1.2 (okay, MS did, but disabled by default) for even longer because lack of server support, compatibility issues, or fear of protocol downgrade attacks made it an uninteresting or risky proposition? Nobody was interested enough to say screw chicken-and-egg and simply get it done, on either side? OS maintainers aren't helping either. RHEL/CentOS 6.4, just released, is still stuck with openssl 1.0.0, which doesn't support TLS 1.1 or 1.2, so there's another few years of webservers running an "enterprise" OS not having TLS 1.2 support. But hey, OpenSSL 1.0.0 is "stable"! I guess there's not much hope of getting Salsa20 or ChaCha, and better curves like curve25519 (I see a draft proposing some Brainpool curves), into TLS 1.2? (with the intent of discouraging many of the less desirable ciphersuites after a few years... not adding more ciphersuites just to add more ciphersuites.)
      - tptacek 14y ago
        What is the advantage of getting Salsa20 or curve25519 into TLS 1.2?
        aidenn0 14y ago
        djb says they're awesome! But more seriously, salsa is very efficient, so if rc4 is still being used for performance reasons, rather than security reasons, then it would seem to be to be a decent replacement.
        tptacek 14y ago
        RC4 is fast, but it's being used because Google was forced by circumstance to use it.
agwa 14y ago
Apparently the compat issues with record splitting have been resolved sufficiently well that all the major browsers have turned it on. Yeah, there's Lucky 13 but you said above that this RC4 vulnerability is unacceptable in a way that Lucky 13 isn't. Basically I'm wondering what the point is in fervently recommending RC4 over AES-CBC when they both suck.

ivanr 14y ago

[I am the author of SSL Labs.] Not all major browsers implement 1/n-1 record splitting. In particular, the last time I checked, Apple did not in Safari and the iOS devices. In that light, downgrading the grade to a B is a reasonable way to indicate that your configuration is not secure for a potentially large portion of the user base. The 1/n-1 split is the main reason that the grade is just reduced and sites are not simply failed (as is the case with insecure renegotiation, for example). The other reason is that the BEAST attack is not exactly easy to execute.

agwa 14y ago
Wow, thanks for this reply (esp the info about Safari/iOS). What are your thoughts on the RC4 attack? Do you plan to take it into account in the SSL Labs test?
- ivanr 14y ago
  Knowing what we know today, attacks against RC4 are not yet practical, and thus there is no reason to panic. But we must act now. Given the huge incentive for researchers to continue to break RC4, it's reasonable to expect that the attacks will continue to improve. Yes, SSL Labs will start to penalize RC4 at some point, but not just yet. Later today we will start warning people about the problems. I've just published the recommendations here: RC4 in TLS is Broken: Now What? https://community.qualys.com/blogs/securitylabs/2013/03/19/rc4-in-tls-is-broken-now-what https://community.qualys.com/blogs/securitylabs/2013/03/19/r...