Live data from Hacker News

Practical attack against TLS/SSL and RC4

rc4nomore.com

1–10 of 45 posts

Re: Practical attack against TLS/SSL and RC4

#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 potential victim that something malicious is going on?

Re: Practical attack against TLS/SSL and RC4

#5

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…

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.

Re: Practical attack against TLS/SSL and RC4

#7

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…

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

Re: Practical attack against TLS/SSL and RC4

#8

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…

How often do you leave a web page open on your computer then leave for a while, I often do. It would probably be prudent that the NSA has ways of doing this with much less effort, perhaps bringing down the number of requests needed to just a few thousand.

Re: Practical attack against TLS/SSL and RC4

#9

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…

Colleague of the author here.

I guess that 4450 requests/s to one IP, or even spread across multiple IPs, could trigger some alarms if the victim is alert. Unfortunately, I'm not that familiar with IDS/IPS's to answer that with much confidence.

In any case, an attacker has a lot of options. The requests do not need to be made sequentially, so an attacker could basically start and resume his attack whenever he wants, e.g. when the victim is away from keyboard (which he can estimate based on the network traffic someone usually generates). An attacker could also simply slow down the number of requests/s, although this results in a larger number of hours required for a successful attack.

As for energy/CPU consumption, I don't think that'd be a big concern. When the practical attack was performed, the CPU usage went up to around 75%, still allowing one to visit other websites without noticing anything. So unless one would closely monitor the CPU/network usage, I don't think the average victim would notice it.

Re: Practical attack against TLS/SSL and RC4

#10

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…

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

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

Post reply on HN