
Practical attack against TLS/SSL and RC4 - tomvangoethem
http://www.rc4nomore.com/?hn
======
api
It's fairly likely that rumors of the NSA's ability to 'decrypt SSL' refers to
RC4 vulnerabilities.

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

------
theandrewbailey
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?

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

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

~~~
the8472
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?

~~~
theandrewbailey
It's not a line of defense. I'm thinking about less computer literate people.
Do you know a friend or family member that would call you and say "My laptop's
really hot, loud, and slow, but it's not doing anything!" and ask for advice?

~~~
the8472
Do you really think they're the kind of people who'll be targeted by this
attack instead of some refined version in the future?

Do you really think this scenario is realistic and worthy of consideration at
all?

------
vishwajeetv
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/evaluati...](https://www.ics.uci.edu/~fielding/pubs/dissertation/evaluation.htm)
Section 6.3.4.2

------
schmichael
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
It's not really their fault - they're hosting on Github, whose infrastructure
presents a Github.com cert to HTTPS requests.

~~~
mbrubeck
[https://vanhoefm.github.io/rc4nomore/](https://vanhoefm.github.io/rc4nomore/)
is a valid HTTPS address for the site.

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

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

~~~
yuhong
The attack numbers are under artificially generated network traffic.

~~~
gipsies
Yes, but we present several techniques on how to generate these amounts of
data. For TLS and HTTPS you can use JavaScript. For WPA-TKIP you need control
of one TCP connection, and that is enough to generate the data. We're not
saying it's a point and click attack, but it's a very good reason to start
worrying :)

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

