Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Practical attack against TLS/SSL and RC4

rc4nomore.com

Post reply on HN
Print view View original

21–30 of 45 posts

Re: Practical attack against TLS/SSL and RC4

#21

Post by thefreeman »

theandrewbailey wrote: post #3

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…

4450 requests per second seems like it would only be possible in an intranet setting where the requests resolve basically instantly. I believe browsers are restricted to 8 active XHR per domain which makes it seem even less likely you could achieve this kind of throughput on an actual website with any kind of latency at all.

Re: Practical attack against TLS/SSL and RC4

#22

Post by derefr »

cyphar wrote: post #20

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.

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".

Re: Practical attack against TLS/SSL and RC4

#23

Post by derefr »

thefreeman wrote: post #21
theandrewbailey wrote: post #3

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…

4450 requests per second seems like it would only be possible in an intranet setting where the requests resolve basically instantly. I believe browsers are restricted to 8 active XHR per domain which makes it seem even less likely you could achieve this kind of throughput on an actual website with any kind of latency at all.

Do you know if the per-domain concurrent request limit is actually a request limit, or just a socket limit? That is, does it still apply if you're making all those requests using one HTTP/2 carrier socket?

Re: Practical attack against TLS/SSL and RC4

#24

Post by baby »

derefr wrote: post #22
cyphar wrote: post #20

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.

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 gett…

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.

Re: Practical attack against TLS/SSL and RC4

#25

Post by dlitz »

cyphar wrote: post #20

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.

> ...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.

Re: Practical attack against TLS/SSL and RC4

#26

Post by dlitz »

rogerbinns wrote: post #15
theandrewbailey wrote: post #3

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…

This is how these attacks work. Someone comes up with numbers like the above and publish. Others improve on it and the amount of work needed reduces. You can see it happen with hash functions as Valerie Aurora shows (also see the reactions table): http://valerieaurora.org/hash.htm

Broken link?

Re: Practical attack against TLS/SSL and RC4

#27

Post by rogerbinns »

dlitz wrote: post #26
rogerbinns wrote: post #15

Earlier quoted context omitted.

This is how these attacks work. Someone comes up with numbers like the above and publish. Others improve on it and the amount of work needed reduces. You can see it happen with hash functions as Valerie Aurora shows (also see the reactions table): http://valerieaurora.org/hash.htm

Broken link?

Sorry. There should be a trailing 'l' that got dropped when I copy pasted.

Re: Practical attack against TLS/SSL and RC4

#29

Post by yuhong »

valarauca1 wrote: post #18
X-Istence wrote: post #7

Earlier quoted context omitted.

Impractical or not, this is still showing a possible attack. Let's say the client leaves their computer on at work over a long weekend ... The collision attacks against MD5 were at first also claimed to be impractical...

rc4 has been cryptographically broken before its specification has been public. Its first reference on usenet was a discussion of how to break it. Which OP's attack is fundamentally the same. It really shouldn't have been considered a proper cryptographic cypher ever.

Yea, I like to mention how it was considered a trade secret of RSA Security.

Re: Practical attack against TLS/SSL and RC4

#30

Post by yuhong »

dlitz wrote: post #25
cyphar wrote: post #20

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.

> ...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 sufficien…

The attack numbers are under artificially generated network traffic.
Post reply on HN