6 ms·

Practical attack against TLS/SSL and RC4

111 points by tomvangoethem 11y ago

api 11y ago
It's fairly likely that rumors of the NSA's ability to 'decrypt SSL' refers to RC4 vulnerabilities.
- throwaway507 11y ago
  Are you sure about that? This attack requires a js exec in browser to generate lots of traffic containing the cookie. It's a little impractical to use in a SIGINT capacity. My bet is still on precalculated DH like logjam attack. Still the quote from @ioerror is: "RC4 is broken in real time" so that's either hyperbole or there is an attack better than 75 hours still out there.
  - netheril96 11y ago
    NSA has been ahead of the state of art in cryptography, as the past has shown. So perhaps they already have an even more practical attack on RC4 for a long time.
  - dadrian 11y ago
    I'd also lean toward Logjam, but I'm biased. :)
theandrewbailey 11y ago
While I agree that RC4 should die in a fire, this attack seems impractical to me. > To successfully decrypt a 16-character cookie with a success probability of 94%, roughly 9x2^27 encryptions of the cookie need to be captured. Since we can make the client transmit 4450 requests per seconds, this amount can be collected in merely 75 hours. How likely would that amount of network traffic and energy consumption cue the potential victim that something malicious is going on?
- therusher 11y ago
  Honestly, the vast majority of people will not notice an increase in traffic, no matter how big it is (this is what, a 285kb/s increase in net traffic?). I think the bigger issue with this exploit is just the fact that so many submissions need to be sent. I don't really see someone sitting there for 75 hours while this takes place without closing the browser/window/tab. EDIT: If you're already injecting JS, you're probably better off just phishing the user for their credentials. Faster, easier, and will work more often than relying on the user staying active enough to send traffic for the next 75h. EDIT 2: Not saying this isn't a valid vulnerability, just not one that can be practically executed currently without much simpler alternatives.
  - gipsies 11y ago
    > I don't really see someone sitting there for 75 hours while this takes place without closing the browser/window/tab. But that's not a problem. If the user closes the browser or tab, the attack can continue at a later point in time. It doesn't need to be collected all at once. As a concrete example, if you leave your computer at work running during the weekend, the attacker has enough time. Or if you leave it running during the night, the attack can be spread out over a few nights. I'm sure there are even more scenarios than just these two examples: there's room for quite some flexibility when performing the attack.
    - therusher 11y ago
      Correct me if I'm wrong here, but: That's assuming the attacker regains control, so you'd have to visit a malicious page every time the attack needs to be re-initiated. EDIT: I'm dumb, somehow I managed to forget mid conversation that this was assuming MitM and not a compromised site. Disregard this point. Also, while this method can be used for other, static data, pretty much all of the stuff you would want / have access to through doing this will be time-sensitive. Even a straight 72h most "secure" things such as cookies will be changed, forcing a restart of this process. Extending this even longer just gives a bigger window for the cookie/whatever to timeout. EDIT: though I guess if the cookie you're trying to crack doesn't expire, then this could be an issue. I still think there are vastly easier methods if you can arbitrarily inject into http pages though.
schmichael 11y ago
Does anyone else find it ironic that not only is this link HTTP, but HTTPS is broken for this domain? https://www.rc4nomore.com/ https://www.rc4nomore.com/ Hopefully the NSA MITMs it with an "RC4 is fffiiinnneee" message.
- ceejayoz 11y ago
  It's not really their fault - they're hosting on Github, whose infrastructure presents a Github.com cert to HTTPS requests.
  - mbrubeck 11y ago
    https://vanhoefm.github.io/rc4nomore/ https://vanhoefm.github.io/rc4nomore/ is a valid HTTPS address for the site.
- schmichael 11y ago
  They fixed it.
deleted 11y ago
[deleted]
cyphar 11y ago
I feel "practical" is too strong of a word here. It's probably a more practical attack than previous attacks, but that doesn't make it practical by a long stretch. "Only" 75 hours, where you have to force the victim to do make a very large number of encrypted messages. IMO, this wouldn't work when trying to break someone's SSL connection at the local Starbucks.
- derefr 11y ago
  I feel like we need a richer vocabulary for the security status of given crypto algorithms/implementations. It's great to be conservative and call everything that isn't perfect "broken", but it'd be nice to have an urgency coefficient to know whether "broken" means "someone will exploit this in a few years" or "the government could attack you with a $50mm cluster" or "your machine could be exploited while you're getting coffee" or even "there's a worm in the wild right now that uses this to spread".
  - baby 11y ago
    It's hard to predict how crypto can handle against powerful adversaries or in time. But if a couple guys can break something in 75 hours, knowing crypto attacks only get better, you can already consider this broken.
- dlitz 11y ago
  > ...but that doesn't make it practical... If I had a dime for every penny of damage caused when people downplay the practicality of attacks against deployed crypto... 75 hours is enough time to attack a laptop left plugged in at the office over a 3-day weekend, and there's no reason why you'd have to attack only one laptop at a time. The paper also says, "capturing traffic for 52 hours already proved to be sufficient", so it's not like 75 hours is some hard minimum. Also: "Our attack is not limited to decrypting cookies. Any data or information that is repeatedly encrypted can be recovered." "We can break a WPA-TKIP network within an hour." RC4 is dead, dead, dead. As with MD5, the writing's been on the wall for a while now, and attacks are only going to get better.
  - 11y ago
userbinator 11y ago
The keys they used were only 128 bits, whereas RC4 actually supports up to 2048 bits. I wonder how much that affects their results. (AFAIK the 128 bits is an export restriction thing, upgraded from the previous trivially-breakable 40 bits.) Also, 16 characters seems awfully short for a cookie, especially one meant for authentication purposes.
- xyzzy123 11y ago
  I don't think SSL/TLS allow key lengths > 128 bits with RC4. Export is 40 or 56 bits. You can see most supported ciphers here: https://www.openssl.org/docs/apps/ciphers.html https://www.openssl.org/docs/apps/ciphers.html e.g: TLS_RSA_WITH_RC4_128_MD5 RC4-MD5 TLS_RSA_WITH_RC4_128_SHA RC4-SHA TLS_ECDH_RSA_WITH_RC4_128_SHA ECDH-RSA-RC4-SHA TLS_ECDH_ECDSA_WITH_RC4_128_SHA ECDH-ECDSA-RC4-SHA
- yuhong 11y ago
  AFAIK one description of RC4 always expand the key to a 256 byte array by repeating the key. It would be interesting to run keystream bias tests against this full array.
vishwajeetv 11y ago
As Roy T. Fieldings once said in his research paper, "Cookie-based applications on the Web will never be reliable!" https://www.ics.uci.edu/~fielding/pubs/dissertation/evaluation.htm https://www.ics.uci.edu/~fielding/pubs/dissertation/evaluati... Section 6.3.4.2

111 points by tomvangoethem 11y ago

api 11y ago

It's fairly likely that rumors of the NSA's ability to 'decrypt SSL' refers to RC4 vulnerabilities.

throwaway507 11y ago
Are you sure about that? This attack requires a js exec in browser to generate lots of traffic containing the cookie. It's a little impractical to use in a SIGINT capacity. My bet is still on precalculated DH like logjam attack. Still the quote from @ioerror is: "RC4 is broken in real time" so that's either hyperbole or there is an attack better than 75 hours still out there.
- netheril96 11y ago
  NSA has been ahead of the state of art in cryptography, as the past has shown. So perhaps they already have an even more practical attack on RC4 for a long time.
- dadrian 11y ago
  I'd also lean toward Logjam, but I'm biased. :)

theandrewbailey 11y ago

While I agree that RC4 should die in a fire, this attack seems impractical to me. > To successfully decrypt a 16-character cookie with a success probability of 94%, roughly 9x2^27 encryptions of the cookie need to be captured. Since we can make the client transmit 4450 requests per seconds, this amount can be collected in merely 75 hours. How likely would that amount of network traffic and energy consumption cue the potential victim that something malicious is going on?

therusher 11y ago
Honestly, the vast majority of people will not notice an increase in traffic, no matter how big it is (this is what, a 285kb/s increase in net traffic?). I think the bigger issue with this exploit is just the fact that so many submissions need to be sent. I don't really see someone sitting there for 75 hours while this takes place without closing the browser/window/tab. EDIT: If you're already injecting JS, you're probably better off just phishing the user for their credentials. Faster, easier, and will work more often than relying on the user staying active enough to send traffic for the next 75h. EDIT 2: Not saying this isn't a valid vulnerability, just not one that can be practically executed currently without much simpler alternatives.
- gipsies 11y ago
  > I don't really see someone sitting there for 75 hours while this takes place without closing the browser/window/tab. But that's not a problem. If the user closes the browser or tab, the attack can continue at a later point in time. It doesn't need to be collected all at once. As a concrete example, if you leave your computer at work running during the weekend, the attacker has enough time. Or if you leave it running during the night, the attack can be spread out over a few nights. I'm sure there are even more scenarios than just these two examples: there's room for quite some flexibility when performing the attack.
  - therusher 11y ago
    Correct me if I'm wrong here, but: That's assuming the attacker regains control, so you'd have to visit a malicious page every time the attack needs to be re-initiated. EDIT: I'm dumb, somehow I managed to forget mid conversation that this was assuming MitM and not a compromised site. Disregard this point. Also, while this method can be used for other, static data, pretty much all of the stuff you would want / have access to through doing this will be time-sensitive. Even a straight 72h most "secure" things such as cookies will be changed, forcing a restart of this process. Extending this even longer just gives a bigger window for the cookie/whatever to timeout. EDIT: though I guess if the cookie you're trying to crack doesn't expire, then this could be an issue. I still think there are vastly easier methods if you can arbitrarily inject into http pages though.

schmichael 11y ago

Does anyone else find it ironic that not only is this link HTTP, but HTTPS is broken for this domain? https://www.rc4nomore.com/ https://www.rc4nomore.com/ Hopefully the NSA MITMs it with an "RC4 is fffiiinnneee" message.

ceejayoz 11y ago
It's not really their fault - they're hosting on Github, whose infrastructure presents a Github.com cert to HTTPS requests.
- mbrubeck 11y ago
  https://vanhoefm.github.io/rc4nomore/ https://vanhoefm.github.io/rc4nomore/ is a valid HTTPS address for the site.
schmichael 11y ago
They fixed it.

deleted 11y ago

[deleted]

cyphar 11y ago

I feel "practical" is too strong of a word here. It's probably a more practical attack than previous attacks, but that doesn't make it practical by a long stretch. "Only" 75 hours, where you have to force the victim to do make a very large number of encrypted messages. IMO, this wouldn't work when trying to break someone's SSL connection at the local Starbucks.

derefr 11y ago
I feel like we need a richer vocabulary for the security status of given crypto algorithms/implementations. It's great to be conservative and call everything that isn't perfect "broken", but it'd be nice to have an urgency coefficient to know whether "broken" means "someone will exploit this in a few years" or "the government could attack you with a $50mm cluster" or "your machine could be exploited while you're getting coffee" or even "there's a worm in the wild right now that uses this to spread".
- baby 11y ago
  It's hard to predict how crypto can handle against powerful adversaries or in time. But if a couple guys can break something in 75 hours, knowing crypto attacks only get better, you can already consider this broken.
dlitz 11y ago
> ...but that doesn't make it practical... If I had a dime for every penny of damage caused when people downplay the practicality of attacks against deployed crypto... 75 hours is enough time to attack a laptop left plugged in at the office over a 3-day weekend, and there's no reason why you'd have to attack only one laptop at a time. The paper also says, "capturing traffic for 52 hours already proved to be sufficient", so it's not like 75 hours is some hard minimum. Also: "Our attack is not limited to decrypting cookies. Any data or information that is repeatedly encrypted can be recovered." "We can break a WPA-TKIP network within an hour." RC4 is dead, dead, dead. As with MD5, the writing's been on the wall for a while now, and attacks are only going to get better.
- 11y ago

userbinator 11y ago

The keys they used were only 128 bits, whereas RC4 actually supports up to 2048 bits. I wonder how much that affects their results. (AFAIK the 128 bits is an export restriction thing, upgraded from the previous trivially-breakable 40 bits.) Also, 16 characters seems awfully short for a cookie, especially one meant for authentication purposes.

xyzzy123 11y ago
I don't think SSL/TLS allow key lengths > 128 bits with RC4. Export is 40 or 56 bits. You can see most supported ciphers here: https://www.openssl.org/docs/apps/ciphers.html https://www.openssl.org/docs/apps/ciphers.html e.g: TLS_RSA_WITH_RC4_128_MD5 RC4-MD5 TLS_RSA_WITH_RC4_128_SHA RC4-SHA TLS_ECDH_RSA_WITH_RC4_128_SHA ECDH-RSA-RC4-SHA TLS_ECDH_ECDSA_WITH_RC4_128_SHA ECDH-ECDSA-RC4-SHA
yuhong 11y ago
AFAIK one description of RC4 always expand the key to a 256 byte array by repeating the key. It would be interesting to run keystream bias tests against this full array.

vishwajeetv 11y ago

As Roy T. Fieldings once said in his research paper, "Cookie-based applications on the Web will never be reliable!" https://www.ics.uci.edu/~fielding/pubs/dissertation/evaluation.htm https://www.ics.uci.edu/~fielding/pubs/dissertation/evaluati... Section 6.3.4.2