6 ms·

RC4 is kind of broken in TLS

92 points by B-Con 14y ago

rb2k_ 14y ago
> However, recent academic work has uncovered many small but significant additional biases running throughout the first 256 bytes of RC4 output. Didn't we know about the RC4 weaknesses of the first few bytes since WEP?
- caf 14y ago
  That was the first handful of bytes. This is the first 256 bytes.
pedrocr 14y ago
>We live in a world where NIST is happy to give us a new hash function every few years. Maybe it's time we put this level of effort and funding into the protocols that use these primitives? They certainly seem to need it. This is a great point. Are there any modern reasonable alternatives to TLS to use in applications? On the one hand developers are told to not implement crypto directly and use something like TLS. Yet on the other hand it seems most TLS implementations suck (don't check the keys for example) and the standard itself has a bunch of holes.
- tptacek 14y ago
  No. Developers should continue to use TLS. If you look at the last few years of TLS --- which have been rocky, to be sure --- you have flaws that are really difficult to exploit and (usually) straightforward to mitigate. If you look at a representative sample of non-TLS transport protocols, you get clownish flaws: * Block ciphers deployed in the default mode (ECB), which allows straightforward byte-at-a-time decryption * Error-based CBC padding oracles for which off-the-shelf tools will do decryption * Unauthenticated ciphertext --- not "used a MAC in the wrong order", like Lucky 13 exploits, but "literally no integrity checks at all", so attackers can trivially rewrite packets * RSA implemented "in the raw" with no formalized padding or PKCS1.5 padding * Key exchanges with basic number theoretic flaws * Repeated IVs and nonces that allow whole message decryption by analyzing captures of just a few hundred messages The list goes on and on. Not only that: two of the recent 4 TLS problems (BEAST's chained CBC IVs and CRIME's compression side channel) are equally likely to affect custom cryptography --- they aren't the product of any weird SSL/TLS requirement. Chained CBC IVs also happened in IPSEC; compressing before encryption was IIRC an _Applied Cryptography_ recommendation. The only reason the RC4 bug is unlikely to apply is that nobody outside of TLS server operators would choose RC4. To be sure: your best options (PGP and TLS) are creaky and scary looking. But they are nowhere nearly as scary as the "New" cryptosystems people deploy. What's especially annoying about the new stuff is that they follow a release cycle that conceals how terrible they are: * Initial release with great fanfare about the new kinds of applications they'll enable, press coverage * Security researchers flag unbelievably blatant flaws in crypto constructions * Blatant flaws are fixed, cryptosystem is rereleased, now with promotional text about the external security testing it has For a cryptosystem published by someone without a citation record in cryptography, a basic crypto flaw should be considered disqualifying; it's a sign that the system was designed without an understanding of how to build sound crypto. But that's not how things actually work, because everyone wants to believe that cryptographic protection is the Internet's birthright and that we're all just a few library calls away from "host-proof" or "anonymous" communications. If you're really worried about TLS security but have the flexibility of specifying arbitrary crypto, why not use a library that does TLS with an AEAD cipher, like AES-GCM?
  - pedrocr 14y ago
    I wasn't suggesting that because TLS is as you say "creaky an scary looking" I'm going to go off and write something from scratch. I think a good job has been done of making developers fear writing their own cryptosystems. What I'm wondering is if there's any serious effort out there that could in the near future replace TLS? Like the article was saying, NIST has promoted new crypto primitives, who can be trusted to create the next generation of crypto systems?
    - tptacek 14y ago
      Browsers are going to rely on a secure transport that features a directory-style PKI and session resumption for the foreseeable future --- CA's aren't going anywhere, and handling millions of inbound connections is going to be a requirement. As long as we need a directory-based PKI and a session feature, what complexity can we really cut out of TLS? The record layer is sane and simple; it's more than HTTPS needs, but isn't hard to implement. The handshake is complicated, but it's complicated because it addresses 15+ years of downgrade attacks. After thinking about that, ask, what's the real benefit of having two (really three, including SSH) mainstream encrypted transports? No matter what happens in any other protocol, a vulnerability in the transport used by browsers is going to be a hair-on-fire emergency. So why not just have everyone use the transport the browser uses? The last point I'd make is, it's 2013. SSL 3.0 goes back to, what, 1996? The vulnerabilities we're finding in SSL are protocol flaws, and they've taken more than a decade to surface. Who feels better about new protocols?
  - ctz 14y ago
    why not use a library that does TLS with an AEAD cipher, like AES-GCM? Some possible reasons: * lack of confidence in TLS's design and designers (for example, TLS1.2 still allows compression and fails to counsel against its use). * TLS has far too many options. I want a secure channel. I don't want a secure channel toolkit. * TLS tends to be paired with a broken and discredited root-of-trust infrastructure (which often gives the misleading impression that TLS itself was broken). (nb. I don't have any evidence that the AEAD TLS1.2 ciphersuites are broken, I'm playing devil's advocate here.) Regarding your 'new cryptosystems' point: I agree, and its completely and frustratingly hopeless. But that's why the world needs a decent secure channel standard with good security bounds, and no knobs on the side which break confidentiality or integrity, and no backwards-insecurity ability.
- jessaustin 14y ago
  The NIST contests are great, but I would expect that running such a contest for a hash or a cipher is easier than doing so for most protocols. It is possible to define exactly what a cryptographic hash must do in order to be considered a cryptographic hash. I think one would have a harder time making an analogous characterization of the solution space for HTTP security. Whatever eventually replaces TLS, I doubt it will be something that could have emerged from a limited-duration contest.
  - benblack 14y ago
    NIST has weighed in on how to use TLS: http://tools.ietf.org/html/rfc6460 http://tools.ietf.org/html/rfc6460 I am not aware of any proposed attacks on the approved cipher suites that are anywhere near feasible. TLS deployment is far behind known best practice. We should do something about that.
    - jessaustin 14y ago
      For sure! I was responding more to the lament that TLS is different from e.g. SHA3. As I see it, this difference is inevitable.
- erichocean 14y ago
  > Are there any modern reasonable alternatives to TLS to use in applications? We're using NaCl, and love it. With libsodium out now, hopefully more people will give it a try.
deleted 14y ago
[deleted]
tptacek 14y ago
Attackers can use Javascript and/or browser plugins to coerce browsers into making millions of requests to (say) GMail, specifying the URL to make the session cookie line up at a specific point in the plaintext. Similar techniques animated BEAST, CRIME, and Lucky 13. Now, for sites that use RC4 (to mitigate BEAST and Lucky 13), attackers can take advantage of a flaw in RC4: RC4's keystream output has biases throughout the first 256 bytes. Over millions of trials, these biases make it possible to use basic statistics to predict cookies, from the vantage point of a passive attacker. This is one of the easier-to-understand TLS flaws of the last few years. RC4 is simple: you key it and it spools out a Hard-to-predict stream of random bytes, which are XOR'd to the plaintext. If those bytes aren't Hard to predict in some way, the attack is obvious. Now that (a) we know how to get browsers to generate millions of sessions (hello, BEAST) and (b) half the Internet is now using RC4 (thanks, BEAST), these RC4 attacks have become germane. My guess is that these attacks are (1) noisy, (2) slow, (3) unreliable, and (4) expensive --- not in a "need a grid of PS3s to exploit" kind of way, but in a "nobody will cast a broad net across the Internet with this attack" sort of way. But the vulnerability is also plainly unacceptable, in a way that I don't think is true of "Lucky 13" (which isn't intractable to fix in application code, just very annoying to fix). It looks like we're finally reaching a place where TLS compat is going to stop dictating what attacks we mitigate and how, because unless we opt to accept the risk of poor "Lucky 13" fixes, there's no compatible way out. We need a widely deployed authenticated ciphersuite.
- stcredzero 14y ago
  > unless we opt to accept the risk of poor "Lucky 13" fixes, there's no compatible way out. What particular class of fixes are you referring to by 'poor "Lucky 13" fixes'? Do you mean that getting Google, Yahoo, Facebook, Amazon, Microsoft, and Mozilla Foundation all to stop using a particular cipher is unworkable, or that TLS is just too broken and needs to be replaced, or both?
  - tptacek 14y ago
    Adam Langley does a much better job explaining this than I can: http://www.imperialviolet.org/2013/02/04/luckythirteen.html http://www.imperialviolet.org/2013/02/04/luckythirteen.html As I understand it, the AES-CBC ciphersuites in TLS are not fundamentally unworkable.
UnoriginalGuy 14y ago
As a short term work-around the client/server could randomly change the order of the request/response headers or move the cookie to near the end of the request/response (where it is harder to recover). They could also add "invalid" headers of random length to push the cookie around making it difficult to find/inconsistent. Increasing the number of request/responses that the attacker would need to sniff on in order to break it. The nice thing about this solution is that it could be done in the browser (e.g. Chrome) when it is connected to an RC4 site without any involvement of the server administrator. It is also backwards compatible. PS - Yes, I know, STOP USING IT - but in the real world if you told people today then they'll still be using it ten years from now...
- tptacek 14y ago
  The problem is the client's headers, not the server's.
  - UnoriginalGuy 14y ago
    I addressed the client's headers. Modifying the browser alters the client's headers.
    - tptacek 14y ago
      If you can modify the browser, modify it to use a ciphersuite that doesn't have these problems! As a shorthand: workarounds are only fair game if they don't require software updates by Microsoft or Mozilla. So, for instance, having Rails treat session tokens as one-time-use does mitigate this flaw (somewhat) and is fair game. But having Firefox randomize client headers is not useful, compared to getting Firefox to reliably do AES-GCM (which I think Firefox may be close to doing already).
      - UnoriginalGuy 14y ago
        And if it breaks connections to servers set up to use RC4 specifically? Sure, the browser should stop "suggesting" they use RC4. That is the browser's right. But if the server decides to use it anyway then they use it. Also you kind of break your own rule. If we cannot suggest things which Microsoft or Mozilla have to do then we cannot suggest they alter their ciphersuite either...
DDub 14y ago
Does this require the authentication cookie to be constant? If, for example, I issue a new cookie to the client every connection then this is mitigated?
- tptacek 14y ago
  That probably does mitigate the attack, with the proviso that a MITM can keep cookies from rotating by preventing requests from hitting the target.
  - jessaustin 14y ago
    If the MITM can do that, it doesn't need to attack cookies does it? It can just impersonate the remote site and steal user-entered credentials. Sharp-eyed users or up-to-date browsers might notice the lack of https for popular sites, and also 2FA, but in general e.g. a malicious WAP has many options. Or I could be very wrong about this. Please advise.
    - tptacek 14y ago
      No, the MITM can be choosy about what traffic it relays and allow the attack to run without causing any of the connections to complete. Think network-layer MITM instead of transport-layer MITM.
- X-Cubed 14y ago
  The other catch with that approach is that requests can be simultaneous, fail, and/or arrive out-of-order, so the server would need to accept any authentication cookie that it had recently sent to the client, not just the last one. Not impossible, but not easy.
- ivanr 14y ago
  No, there isn't a reason why a session cookie needs to remain constant forever. I think rotating the cookie on every request would be challenging (because, at any given time, there may be several requests active), but it's very easy to rotate the cookie every couple of minutes. Such rotation would mitigate all attacks that rely on forcing browsers to submit thousands of requests. Web applications that use HTTP Authentication cannot be fixed in this way, because you cannot change the password regularly. Other protocols that carry plain-text passwords (after SSL) may be even more vulnerable, for the same reason. For example, authenticated SMTP may be the worst case if the attacker can consistently force an automated client to reconnect and try again.
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.

92 points by B-Con 14y ago

rb2k_ 14y ago

> However, recent academic work has uncovered many small but significant additional biases running throughout the first 256 bytes of RC4 output. Didn't we know about the RC4 weaknesses of the first few bytes since WEP?

caf 14y ago
That was the first handful of bytes. This is the first 256 bytes.

pedrocr 14y ago

>We live in a world where NIST is happy to give us a new hash function every few years. Maybe it's time we put this level of effort and funding into the protocols that use these primitives? They certainly seem to need it. This is a great point. Are there any modern reasonable alternatives to TLS to use in applications? On the one hand developers are told to not implement crypto directly and use something like TLS. Yet on the other hand it seems most TLS implementations suck (don't check the keys for example) and the standard itself has a bunch of holes.

tptacek 14y ago
No. Developers should continue to use TLS. If you look at the last few years of TLS --- which have been rocky, to be sure --- you have flaws that are really difficult to exploit and (usually) straightforward to mitigate. If you look at a representative sample of non-TLS transport protocols, you get clownish flaws: * Block ciphers deployed in the default mode (ECB), which allows straightforward byte-at-a-time decryption * Error-based CBC padding oracles for which off-the-shelf tools will do decryption * Unauthenticated ciphertext --- not "used a MAC in the wrong order", like Lucky 13 exploits, but "literally no integrity checks at all", so attackers can trivially rewrite packets * RSA implemented "in the raw" with no formalized padding or PKCS1.5 padding * Key exchanges with basic number theoretic flaws * Repeated IVs and nonces that allow whole message decryption by analyzing captures of just a few hundred messages The list goes on and on. Not only that: two of the recent 4 TLS problems (BEAST's chained CBC IVs and CRIME's compression side channel) are equally likely to affect custom cryptography --- they aren't the product of any weird SSL/TLS requirement. Chained CBC IVs also happened in IPSEC; compressing before encryption was IIRC an _Applied Cryptography_ recommendation. The only reason the RC4 bug is unlikely to apply is that nobody outside of TLS server operators would choose RC4. To be sure: your best options (PGP and TLS) are creaky and scary looking. But they are nowhere nearly as scary as the "New" cryptosystems people deploy. What's especially annoying about the new stuff is that they follow a release cycle that conceals how terrible they are: * Initial release with great fanfare about the new kinds of applications they'll enable, press coverage * Security researchers flag unbelievably blatant flaws in crypto constructions * Blatant flaws are fixed, cryptosystem is rereleased, now with promotional text about the external security testing it has For a cryptosystem published by someone without a citation record in cryptography, a basic crypto flaw should be considered disqualifying; it's a sign that the system was designed without an understanding of how to build sound crypto. But that's not how things actually work, because everyone wants to believe that cryptographic protection is the Internet's birthright and that we're all just a few library calls away from "host-proof" or "anonymous" communications. If you're really worried about TLS security but have the flexibility of specifying arbitrary crypto, why not use a library that does TLS with an AEAD cipher, like AES-GCM?
- pedrocr 14y ago
  I wasn't suggesting that because TLS is as you say "creaky an scary looking" I'm going to go off and write something from scratch. I think a good job has been done of making developers fear writing their own cryptosystems. What I'm wondering is if there's any serious effort out there that could in the near future replace TLS? Like the article was saying, NIST has promoted new crypto primitives, who can be trusted to create the next generation of crypto systems?
  - tptacek 14y ago
    Browsers are going to rely on a secure transport that features a directory-style PKI and session resumption for the foreseeable future --- CA's aren't going anywhere, and handling millions of inbound connections is going to be a requirement. As long as we need a directory-based PKI and a session feature, what complexity can we really cut out of TLS? The record layer is sane and simple; it's more than HTTPS needs, but isn't hard to implement. The handshake is complicated, but it's complicated because it addresses 15+ years of downgrade attacks. After thinking about that, ask, what's the real benefit of having two (really three, including SSH) mainstream encrypted transports? No matter what happens in any other protocol, a vulnerability in the transport used by browsers is going to be a hair-on-fire emergency. So why not just have everyone use the transport the browser uses? The last point I'd make is, it's 2013. SSL 3.0 goes back to, what, 1996? The vulnerabilities we're finding in SSL are protocol flaws, and they've taken more than a decade to surface. Who feels better about new protocols?
- ctz 14y ago
  why not use a library that does TLS with an AEAD cipher, like AES-GCM? Some possible reasons: * lack of confidence in TLS's design and designers (for example, TLS1.2 still allows compression and fails to counsel against its use). * TLS has far too many options. I want a secure channel. I don't want a secure channel toolkit. * TLS tends to be paired with a broken and discredited root-of-trust infrastructure (which often gives the misleading impression that TLS itself was broken). (nb. I don't have any evidence that the AEAD TLS1.2 ciphersuites are broken, I'm playing devil's advocate here.) Regarding your 'new cryptosystems' point: I agree, and its completely and frustratingly hopeless. But that's why the world needs a decent secure channel standard with good security bounds, and no knobs on the side which break confidentiality or integrity, and no backwards-insecurity ability.
jessaustin 14y ago
The NIST contests are great, but I would expect that running such a contest for a hash or a cipher is easier than doing so for most protocols. It is possible to define exactly what a cryptographic hash must do in order to be considered a cryptographic hash. I think one would have a harder time making an analogous characterization of the solution space for HTTP security. Whatever eventually replaces TLS, I doubt it will be something that could have emerged from a limited-duration contest.
- benblack 14y ago
  NIST has weighed in on how to use TLS: http://tools.ietf.org/html/rfc6460 http://tools.ietf.org/html/rfc6460 I am not aware of any proposed attacks on the approved cipher suites that are anywhere near feasible. TLS deployment is far behind known best practice. We should do something about that.
  - jessaustin 14y ago
    For sure! I was responding more to the lament that TLS is different from e.g. SHA3. As I see it, this difference is inevitable.
erichocean 14y ago
> Are there any modern reasonable alternatives to TLS to use in applications? We're using NaCl, and love it. With libsodium out now, hopefully more people will give it a try.

deleted 14y ago

[deleted]

tptacek 14y ago

Attackers can use Javascript and/or browser plugins to coerce browsers into making millions of requests to (say) GMail, specifying the URL to make the session cookie line up at a specific point in the plaintext. Similar techniques animated BEAST, CRIME, and Lucky 13. Now, for sites that use RC4 (to mitigate BEAST and Lucky 13), attackers can take advantage of a flaw in RC4: RC4's keystream output has biases throughout the first 256 bytes. Over millions of trials, these biases make it possible to use basic statistics to predict cookies, from the vantage point of a passive attacker. This is one of the easier-to-understand TLS flaws of the last few years. RC4 is simple: you key it and it spools out a Hard-to-predict stream of random bytes, which are XOR'd to the plaintext. If those bytes aren't Hard to predict in some way, the attack is obvious. Now that (a) we know how to get browsers to generate millions of sessions (hello, BEAST) and (b) half the Internet is now using RC4 (thanks, BEAST), these RC4 attacks have become germane. My guess is that these attacks are (1) noisy, (2) slow, (3) unreliable, and (4) expensive --- not in a "need a grid of PS3s to exploit" kind of way, but in a "nobody will cast a broad net across the Internet with this attack" sort of way. But the vulnerability is also plainly unacceptable, in a way that I don't think is true of "Lucky 13" (which isn't intractable to fix in application code, just very annoying to fix). It looks like we're finally reaching a place where TLS compat is going to stop dictating what attacks we mitigate and how, because unless we opt to accept the risk of poor "Lucky 13" fixes, there's no compatible way out. We need a widely deployed authenticated ciphersuite.

stcredzero 14y ago
> unless we opt to accept the risk of poor "Lucky 13" fixes, there's no compatible way out. What particular class of fixes are you referring to by 'poor "Lucky 13" fixes'? Do you mean that getting Google, Yahoo, Facebook, Amazon, Microsoft, and Mozilla Foundation all to stop using a particular cipher is unworkable, or that TLS is just too broken and needs to be replaced, or both?
- tptacek 14y ago
  Adam Langley does a much better job explaining this than I can: http://www.imperialviolet.org/2013/02/04/luckythirteen.html http://www.imperialviolet.org/2013/02/04/luckythirteen.html As I understand it, the AES-CBC ciphersuites in TLS are not fundamentally unworkable.

UnoriginalGuy 14y ago

As a short term work-around the client/server could randomly change the order of the request/response headers or move the cookie to near the end of the request/response (where it is harder to recover). They could also add "invalid" headers of random length to push the cookie around making it difficult to find/inconsistent. Increasing the number of request/responses that the attacker would need to sniff on in order to break it. The nice thing about this solution is that it could be done in the browser (e.g. Chrome) when it is connected to an RC4 site without any involvement of the server administrator. It is also backwards compatible. PS - Yes, I know, STOP USING IT - but in the real world if you told people today then they'll still be using it ten years from now...

tptacek 14y ago
The problem is the client's headers, not the server's.
- UnoriginalGuy 14y ago
  I addressed the client's headers. Modifying the browser alters the client's headers.
  - tptacek 14y ago
    If you can modify the browser, modify it to use a ciphersuite that doesn't have these problems! As a shorthand: workarounds are only fair game if they don't require software updates by Microsoft or Mozilla. So, for instance, having Rails treat session tokens as one-time-use does mitigate this flaw (somewhat) and is fair game. But having Firefox randomize client headers is not useful, compared to getting Firefox to reliably do AES-GCM (which I think Firefox may be close to doing already).
    - UnoriginalGuy 14y ago
      And if it breaks connections to servers set up to use RC4 specifically? Sure, the browser should stop "suggesting" they use RC4. That is the browser's right. But if the server decides to use it anyway then they use it. Also you kind of break your own rule. If we cannot suggest things which Microsoft or Mozilla have to do then we cannot suggest they alter their ciphersuite either...

DDub 14y ago

Does this require the authentication cookie to be constant? If, for example, I issue a new cookie to the client every connection then this is mitigated?

tptacek 14y ago
That probably does mitigate the attack, with the proviso that a MITM can keep cookies from rotating by preventing requests from hitting the target.
- jessaustin 14y ago
  If the MITM can do that, it doesn't need to attack cookies does it? It can just impersonate the remote site and steal user-entered credentials. Sharp-eyed users or up-to-date browsers might notice the lack of https for popular sites, and also 2FA, but in general e.g. a malicious WAP has many options. Or I could be very wrong about this. Please advise.
  - tptacek 14y ago
    No, the MITM can be choosy about what traffic it relays and allow the attack to run without causing any of the connections to complete. Think network-layer MITM instead of transport-layer MITM.
X-Cubed 14y ago
The other catch with that approach is that requests can be simultaneous, fail, and/or arrive out-of-order, so the server would need to accept any authentication cookie that it had recently sent to the client, not just the last one. Not impossible, but not easy.
ivanr 14y ago
No, there isn't a reason why a session cookie needs to remain constant forever. I think rotating the cookie on every request would be challenging (because, at any given time, there may be several requests active), but it's very easy to rotate the cookie every couple of minutes. Such rotation would mitigate all attacks that rely on forcing browsers to submit thousands of requests. Web applications that use HTTP Authentication cannot be fixed in this way, because you cannot change the password regularly. Other protocols that carry plain-text passwords (after SSL) may be even more vulnerable, for the same reason. For example, authenticated SMTP may be the worst case if the attacker can consistently force an automated client to reconnect and try again.

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.