31–40 of 45 posts
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.
Earlier quoted context omitted.
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,…
> As for energy/CPU consumption, I don't think that'd be a big concern. What if this attack targeted a phone or laptop? Battery would die faster, device would get warmer, and fans spin up.
Why even bring it up?
Earlier quoted context omitted.
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?
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.
Earlier quoted context omitted.
> ...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.
It's fairly likely that rumors of the NSA's ability to 'decrypt SSL' refers to RC4 vulnerabilities.
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.
It's fairly likely that rumors of the NSA's ability to 'decrypt SSL' refers to RC4 vulnerabilities.
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.
Also, 16 characters seems awfully short for a cookie, especially one meant for authentication purposes.
Earlier quoted context omitted.
> As for energy/CPU consumption, I don't think that'd be a big concern. What if this attack targeted a phone or laptop? Battery would die faster, device would get warmer, and fans spin up.
If your last line of defense in encryption/network security is noticing that the fan spins up more often then you already lost the game. Why even bring it up?
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.
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