Tell me more ×
Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.
up vote 15 down vote favorite
3

Why is Google using RC4 for their HTTPS/SSL?

$ openssl s_client -connect www.google.com:443 | grep "Cipher is"
New, TLSv1/SSLv3, Cipher is RC4-SHA

Isn't RC4 unsafe to use?

share|improve this question
1  
RC4 is safe for use in SSL/TSL. See here Many banks still use it including Citibank and Capital One. – David Schwartz Sep 29 '11 at 9:37
3  
@David Schwartz: things changed. – fgrieu Mar 19 at 8:45

4 Answers

up vote 1 down vote

Got news: http://en.wikipedia.org/wiki/Transport_Layer_Security#RC4_attack

It's not very practical yet (at least 224 ciphertexts), but attacks can only get better, not worse. Remember how it was with WEP cracking.

share|improve this answer
up vote 18 down vote

Academically speaking, RC4 is terrible; it has easy distinguishers ("easy" means "can really be demonstrated in lab conditions"). It is also hard to use properly. However, SSL/TLS uses RC4 correctly, and in practice the shortcomings of RC4 have no real importance.

The power-that-be at Google decided to switch to RC4 by default because of the recent "BEAST" attack, which demonstrates (again, in lab conditions) a compromise of a Paypal cookie. There is no such dramatic demonstration for an attack on RC4 as used in SSL, so it was estimated that using AES-CBC with SSL/TLS 1.0 was "more risky" than using RC4.

The academically "right thing" to do would be to use AES-CBC with TLS 1.1 (or any ulterior version), which has no problem with BEAST and none of the RC4-related weaknesses either. However, Google makes money in the real world, and, as such, they cannot enforce a configuration which would prevent a third of their user base from connecting.

share|improve this answer
2  
Google was using RC4 by default before BEAST, simply because it's the lowest CPU burden to implement and they were leading the way in SSL-by-default, so at their scale this really mattered. – Phil P May 23 '12 at 15:37
4  
@PhilP: actually, with a recent enough x86 CPU (one with the AES-NI instructions), AES is vastly less expensive than RC4. Anyway, encryption speed is non-negligible only when doing bulk data transfer, which is not typical of what Google does. Most of what Google does is CPU-heavy and encryption cost is quite dwarfed by it. – Thomas Pornin May 23 '12 at 21:53
1  
Google has a lot of machines, replacing all of the CPUs to get a CPU with the latest feature is the sort of event which would turn shareholders white. No doubt at some point they'll have enough front-end boxes with AES-NI, and knowing Google it will be sooner than I might expect. – Phil P May 25 '12 at 13:57
This answer is completely and utterly wrong. At FSE '13 Bernstein presented a passive attack that requires intercepting 2^32 sessions where the same secrets are encrypted. That sounds like a lot, but if an application automatically restarts a connection it is very possible. – Watson Ladd Mar 19 at 7:00
1  
Indeed, there's new stuff; see this and this. The attack seems to recover part of a message repeated in multiple TLS sessions (for some bytes, it starts working at $2^{24}$ repeats). Attacks only get better; they never get worse. – fgrieu Mar 19 at 7:56
show 1 more comment
up vote 9 down vote

Wikipedia has a decent writeup on the known attacks on RC4. Most of them are from biases of the output. To give you an idea of the severity of the attacks see the following quotes from the Wikipedia page:

The best such attack is due to Itsik Mantin and Adi Shamir who showed that the second output byte of the cipher was biased toward zero with probability 1/128 (instead of 1/256).

There is also this:

Souradyuti Paul and Bart Preneel of COSIC showed that the first and the second bytes of the RC4 were also biased. The number of required samples to detect this bias is $2^{25}$ bytes.

The following bias in RC4 was used to attack WEP:

...over all possible RC4 keys, the statistics for the first few bytes of output keystream are strongly non-random, leaking information about the key. If the long-term key and nonce are simply concatenated to generate the RC4 key, this long-term key can be discovered by analysing a large number of messages encrypted with this key.

As far as I know, however, SSL/TLS does not use a long-term key with a nonce. It establishes a new key every connection (and even refreshes the key after some period of time).

The take away point is, RC4 has shown some weaknesses that have actually been exploited to attack real-world system under certain configurations. But, no one has shown if/how these weaknesses affect SSL/TLS. If you are worried about it, however, I believe SSL/TLS has a cipher negotiation phase, so there is probably a way to force connections to not be able to use RC4. This could open you up to other attacks though.

Update

There was also a pretty good disussion on this a while back on sci.crypt that is pretty good.

share|improve this answer
up vote 4 down vote

RC4 is a stream cipher and can be easy to misuse. E.g. Microsoft had problems with it to protect password and office documents. However its use is, afaik, correct inside the SSL/TLS specification.

Like often in cryptography things are easier to misuse than to use ;-)

share|improve this answer
1  
RC4 is easier to misuse than an ideal stream cipher. In particular its related key vulnerabilities make it easy to make a mistake while adding an IV. – CodesInChaos May 30 '12 at 10:21

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.