5 ms·

Five researchers deal SSL/TLS a biggish blow

69 points by danielhunt 14y ago

darklajid 14y ago
Same thing as [1] (4 days ago), for all I can tell? 1: https://news.ycombinator.com/item?id=5364807 https://news.ycombinator.com/item?id=5364807
- tptacek 14y ago
  Different article, different (somewhat more detailed) explanation.
powertower 14y ago
Does not seem like a big deal to me; because it's unlikely to work outside a lab environment, nor passed the first 256 bytes (without a truly massive amount of connections at least). And all that work for what - to sniff out your own cookie? I mean, what is this good for, it's not a man-in-the-middle attack, it's not a spoofing attack, etc? *Though it's really good work on the researchers part, and the author of the article explained it all in an excellent way.
- tptacek 14y ago
  No, I think you've misunderstood this attack at multiple points. The attack gives the researchers the ability to use any HTML page on the Internet to trick your browser into launching an attack on your Paypal cookie. Once they have that cookie, they don't care about MITM attacks; they'll just impersonate you. The attack is very time-consuming, though, so you're right that it's not a particularly urgent real-world threat at the moment.
  - powertower 14y ago
    You're right, that's kind of what I got from it by reading the other thread after posting... You'd need to visit a page that exploits JS to make those connections to get that cookie. Afterwards, I guess it depends.
btian 14y ago
Link bait title. It doesn't work in general as reported in the article.
- deleted 14y ago
  [deleted]
- Joeri 14y ago
  Betteridge's law of headlines told us this without reading the article.
rem1313 14y ago
Although sensationalist title, always good to remember that attacks only get better - some angle might show up that changes this to be practical in some special circumstance. The takeaway here is to plan moving away from RC4 and there is still time to do this in orderly fashion
serialx 14y ago
Interesting.. It has more practical application to IMAP or POP3. http://crypto.stackexchange.com/questions/3451/is-rc4-a-problem-for-password-based-authentication http://crypto.stackexchange.com/questions/3451/is-rc4-a-prob...
- tptacek 14y ago
  It does apply to those protocols, except that it's much harder to coerce a victim into making hundreds of millions of connections to an IMAP server. On the other hand, those questions are based on the logic that only the first few bytes of the connection are exposed to the attack. That turns out not to be true. There are biases hundreds of bytes into the keystream. The earlier biases seem to be easier to detect, which might make an attack somewhat faster against a protocol where the secret was exchanged earlier than HTTPS.
ck2 14y ago
We can stop using RC4 http://dl.dropbox.com/u/24257718/cipher_chart.png http://dl.dropbox.com/u/24257718/cipher_chart.png Virtually all server side hardware can do AES-NI instructions in hardware now (unless you are using ATOM cpu for ssl connections?) and most non-mobile hardware clients can do AESNI too for AES-128
- otterley 14y ago
  A lot of sites are on hardware that's older than two years old (AES-NI didn't show up till Westmere), or an OS that's more than two years old (Ubuntu Lucid, for example, ships with OpenSSL 0.9.8). Upgrading takes time.
  - deleted 14y ago
    [deleted]
- tptacek 14y ago
  The problem with AES isn't performance. Sites have been using AES ciphersuites in TLS for many years. The problem is that the widely-deployed AES ciphersuite, like the ciphersuites for triple DES and IDEA, uses a construction from the '90s that is itself insecure. It's based on CBC mode (which is fine) in a MAC-then-encrypt configuration (which is not), which lead to the Lucky 13 attack, and which until TLS 1.1 didn't properly set up the IVs for each record, which lead to BEAST. No major site used RC4 because it was more performant. They used it as a workaround to Lucky 13 and BEAST, because they couldn't count on browsers fixing those problems fast enough.
  - gingerlime 14y ago
    True, but at least BEAST is probably not that much of a concern[1], not sure about the state of Lucky 13 in the grand scheme of things. [1] http://security.stackexchange.com/questions/17080/is-there-a-way-to-mitigate-beast-without-disabling-aes-completely/24489#24489 http://security.stackexchange.com/questions/17080/is-there-a...
    - 14y ago
gingerlime 14y ago
I've also tried to post a couple of links discussing these attacks in practice, and comparing the risks from BEAST/Lucky 13 to these... * https://news.ycombinator.com/item?id=5367805 https://news.ycombinator.com/item?id=5367805 - links to a very interesting answer on security stackexchange that puts things into pretty good perspective. * https://news.ycombinator.com/item?id=5368610 https://news.ycombinator.com/item?id=5368610 - links to an interesting possible browser workaround to these attacks. (disclaimer: I'm the one who posted both the questions on security stackexchange and HN posts. I'm not trying to be a karma whore, just hoping to get some discussion going on around those... both went under the radar)
- tptacek 14y ago
  The first article ignores the decrypt-then-verify timing leak in the TLS CBC modes ("Lucky 13") when it suggests you might just switch back to AES-CBC because BEAST is hard to exploit. The second article is based on the assumption that you can reliably pad the headers between the request and the cookie in a browser on every vector an attacker has to coerce a browser into making connections. People seem to be thinking about serverside fixes; this is a clientside problem.
  - gingerlime 14y ago
    would be interesting if you can share those thoughts on security stackexchange. Guys like Thomas Pornin seem very knowledgeable and I'd be curious to hear his take on this.
denibee 14y ago
But doesn't this attack only reveal the second byte of the RC4 cipher? If I got it right it is some kind of frequency analysis that doesn't reveal the entire key (cipher), or at least with high probability (higher than 1)..

69 points by danielhunt 14y ago

Same thing as [1] (4 days ago), for all I can tell? 1: https://news.ycombinator.com/item?id=5364807 https://news.ycombinator.com/item?id=5364807

tptacek 14y ago
Different article, different (somewhat more detailed) explanation.

powertower 14y ago

Does not seem like a big deal to me; because it's unlikely to work outside a lab environment, nor passed the first 256 bytes (without a truly massive amount of connections at least). And all that work for what - to sniff out your own cookie? I mean, what is this good for, it's not a man-in-the-middle attack, it's not a spoofing attack, etc? *Though it's really good work on the researchers part, and the author of the article explained it all in an excellent way.

tptacek 14y ago
No, I think you've misunderstood this attack at multiple points. The attack gives the researchers the ability to use any HTML page on the Internet to trick your browser into launching an attack on your Paypal cookie. Once they have that cookie, they don't care about MITM attacks; they'll just impersonate you. The attack is very time-consuming, though, so you're right that it's not a particularly urgent real-world threat at the moment.
- powertower 14y ago
  You're right, that's kind of what I got from it by reading the other thread after posting... You'd need to visit a page that exploits JS to make those connections to get that cookie. Afterwards, I guess it depends.

btian 14y ago

Link bait title. It doesn't work in general as reported in the article.

deleted 14y ago
[deleted]
Joeri 14y ago
Betteridge's law of headlines told us this without reading the article.

rem1313 14y ago

Although sensationalist title, always good to remember that attacks only get better - some angle might show up that changes this to be practical in some special circumstance. The takeaway here is to plan moving away from RC4 and there is still time to do this in orderly fashion

serialx 14y ago

Interesting.. It has more practical application to IMAP or POP3. http://crypto.stackexchange.com/questions/3451/is-rc4-a-problem-for-password-based-authentication http://crypto.stackexchange.com/questions/3451/is-rc4-a-prob...

tptacek 14y ago
It does apply to those protocols, except that it's much harder to coerce a victim into making hundreds of millions of connections to an IMAP server. On the other hand, those questions are based on the logic that only the first few bytes of the connection are exposed to the attack. That turns out not to be true. There are biases hundreds of bytes into the keystream. The earlier biases seem to be easier to detect, which might make an attack somewhat faster against a protocol where the secret was exchanged earlier than HTTPS.

ck2 14y ago

We can stop using RC4 http://dl.dropbox.com/u/24257718/cipher_chart.png http://dl.dropbox.com/u/24257718/cipher_chart.png Virtually all server side hardware can do AES-NI instructions in hardware now (unless you are using ATOM cpu for ssl connections?) and most non-mobile hardware clients can do AESNI too for AES-128

otterley 14y ago
A lot of sites are on hardware that's older than two years old (AES-NI didn't show up till Westmere), or an OS that's more than two years old (Ubuntu Lucid, for example, ships with OpenSSL 0.9.8). Upgrading takes time.
- deleted 14y ago
  [deleted]
tptacek 14y ago
The problem with AES isn't performance. Sites have been using AES ciphersuites in TLS for many years. The problem is that the widely-deployed AES ciphersuite, like the ciphersuites for triple DES and IDEA, uses a construction from the '90s that is itself insecure. It's based on CBC mode (which is fine) in a MAC-then-encrypt configuration (which is not), which lead to the Lucky 13 attack, and which until TLS 1.1 didn't properly set up the IVs for each record, which lead to BEAST. No major site used RC4 because it was more performant. They used it as a workaround to Lucky 13 and BEAST, because they couldn't count on browsers fixing those problems fast enough.
- gingerlime 14y ago
  True, but at least BEAST is probably not that much of a concern[1], not sure about the state of Lucky 13 in the grand scheme of things. [1] http://security.stackexchange.com/questions/17080/is-there-a-way-to-mitigate-beast-without-disabling-aes-completely/24489#24489 http://security.stackexchange.com/questions/17080/is-there-a...
  - 14y ago

gingerlime 14y ago

I've also tried to post a couple of links discussing these attacks in practice, and comparing the risks from BEAST/Lucky 13 to these... * https://news.ycombinator.com/item?id=5367805 https://news.ycombinator.com/item?id=5367805 - links to a very interesting answer on security stackexchange that puts things into pretty good perspective. * https://news.ycombinator.com/item?id=5368610 https://news.ycombinator.com/item?id=5368610 - links to an interesting possible browser workaround to these attacks. (disclaimer: I'm the one who posted both the questions on security stackexchange and HN posts. I'm not trying to be a karma whore, just hoping to get some discussion going on around those... both went under the radar)

tptacek 14y ago
The first article ignores the decrypt-then-verify timing leak in the TLS CBC modes ("Lucky 13") when it suggests you might just switch back to AES-CBC because BEAST is hard to exploit. The second article is based on the assumption that you can reliably pad the headers between the request and the cookie in a browser on every vector an attacker has to coerce a browser into making connections. People seem to be thinking about serverside fixes; this is a clientside problem.
- gingerlime 14y ago
  would be interesting if you can share those thoughts on security stackexchange. Guys like Thomas Pornin seem very knowledgeable and I'd be curious to hear his take on this.

denibee 14y ago

But doesn't this attack only reveal the second byte of the RC4 cipher? If I got it right it is some kind of frequency analysis that doesn't reveal the entire key (cipher), or at least with high probability (higher than 1)..