Does anyone else find it ironic that not only is this link HTTP, but HTTPS is broken for this domain? https://www.rc4nomore.com/ Hopefully the NSA MITMs it with an "RC4 is fffiiinnneee" message.
Practical attack against TLS/SSL and RC4
11–20 of 45 posts
Re: Practical attack against TLS/SSL and RC4
#12Earlier quoted context omitted.
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 runnin…
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.
Re: Practical attack against TLS/SSL and RC4
#13Earlier quoted context omitted.
> 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 runnin…
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 a…
Every non-HTTPS page can be considered malicious, if the attacker can do a MITM.
Since the attacker can capture the encrypted traffic, he most probably is in the middle and can do a MITM.
Therefore, if you are under this attack, every non-HTTPS page is malicious.
Re: Practical attack against TLS/SSL and RC4
#14Earlier quoted context omitted.
> 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 runnin…
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 a…
Re: Practical attack against TLS/SSL and RC4
#15While 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…
Re: Practical attack against TLS/SSL and RC4
#16Does anyone else find it ironic that not only is this link HTTP, but HTTPS is broken for this domain? https://www.rc4nomore.com/ Hopefully the NSA MITMs it with an "RC4 is fffiiinnneee" message.
It's not really their fault - they're hosting on Github, whose infrastructure presents a Github.com cert to HTTPS requests.
Re: Practical attack against TLS/SSL and RC4
#17While 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,…
What if this attack targeted a phone or laptop? Battery would die faster, device would get warmer, and fans spin up.
Re: Practical attack against TLS/SSL and RC4
#18While 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...
It really shouldn't have been considered a proper cryptographic cypher ever.
Re: Practical attack against TLS/SSL and RC4
#19While 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…
Re: Practical attack against TLS/SSL and RC4
#20"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.