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?

  • 1
    $\begingroup$ RC4 is safe for use in SSL/TSL. See here Many banks still use it including Citibank and Capital One. $\endgroup$ Commented Sep 29, 2011 at 9:37
  • 6
    $\begingroup$ @David Schwartz: things changed. $\endgroup$
    – fgrieu
    Commented Mar 19, 2013 at 8:45
  • 2
    $\begingroup$ Microsoft is using MD5. $\endgroup$
    – Qiu
    Commented Oct 19, 2013 at 20:55
  • $\begingroup$ Servers support many cipher suites, which gets used depends on your browser. I think Google keep SSL 3 and RC4 available to support IE 6 on Windows XP. See the handshake simulation section here ssllabs.com/ssltest/analyze.html?d=mail.google.com $\endgroup$ Commented Jun 28, 2015 at 17:24

7 Answers 7


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.

  • 4
    $\begingroup$ 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. $\endgroup$
    – Phil P
    Commented May 23, 2012 at 15:37
  • 5
    $\begingroup$ @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. $\endgroup$ Commented May 23, 2012 at 21:53
  • 3
    $\begingroup$ 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. $\endgroup$
    – fgrieu
    Commented Mar 19, 2013 at 7:56
  • 4
    $\begingroup$ @WatsonLadd I think it's somewhat unfair to attack an answer that, at this point, is 2 years old and make it appear as if it was "completely and utterly wrong" to begin with - especially when it isn't! Yes, new evidence has come to light about the security of RC4 when used with TLS/SSL and a comment noting that (very important) fact should be made. Yes, the answer could, possibly, be updated to account for the new information. $\endgroup$ Commented Mar 20, 2013 at 1:26
  • 3
    $\begingroup$ Actually the answer still fits. An attack which requires spying on 16 millions of successive connections is still not practical: it can be demonstrated in lab conditions, but not in the field. Though the "security margin" is indeed not very large. $\endgroup$ Commented Nov 15, 2013 at 11:49

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.


I do think that in the fullness of time the choice to forcibly migrate people to RC4 will be considered a folly.

We recently had a PCI auditor command that we use RC4 to avoid the BEAST attack. We had no option but to comply or face losing our PCI certification. Across the industry, people are fleeing from AES-CBC in response to this attack. Yet in my opinion using RC4 in TLS is much, much worse than incorrectly using CBC.

Why you ask?

Let's say that Alice and Bob disagree about the security of RC4. Alice thinks RC4 is completely fine for TLS, Bob disagrees.

They decide to set up a little game. In each round of the game, Bob will submit two messages to Alice, m0 and m1. Alice will then choose an RC4 key at random, encrypt one of the messages and send it back to Bob. She always chooses the same message to encrypt for all the rounds in a specific game: either she always encrypts m0 or she always encrypts m1. Bob can have as many rounds as he likes, but at the end his goal is to tell which of the two messages he is getting back in each round.

Now for any secure cipher, Bob wouldn't be able to do this with a probability greater than 50%. However, for RC4 he can do this trivially by requesting the encryption of pairs of two byte messages.

Here's how it works. He sets M0 to 0xFFFF and he sets M1 to 0x0000. The second byte of an RC4 key stream as about twice the likelihood of being zero as it should do: $2\over256$. His strategy is to just submit these messages again and again and again and again. He then records how often he sees 0xFF in the second byte versus how often he see 0x00. He can use this to distinguish whether he's getting M0s or M1s.

This isn't some academic attack either, you can actually implement it in a few lines of Python and it runs in a handful of seconds. See here for some working code I've knocked together that demonstrates this attack. I've set the default number of trials to 2000. It occasional gets it wrong on this setting but most of the time the challenger and attacker agree.

Worse, this game isn't all that academic either. It is often the case that with TLS that same payload is encrypted under multiple keys.

Suppose we use TLS to secure POP or IMAP sessions. The initial phase of the protocol are identical for all users. Worse, it often the case the actual user passwords are transmitted over the TLS.

An attacker might be able to use the biases in the first few hundred bytes of RC4 to significantly reduce an exhaustive search of a user password. He just sits there waiting for the user to connect to their POP server and records each session's bytes. People often configure their e-mail client to do this every few minutes. We're not expecting the user to do anything out of the ordinary!

He then analyses these bytes with respect to already known biases to prioritise a brute-force search of the password space.

I don't even think any new cryptanalysis is required to mount this attack. It simply a question of developing a clever heuristic algorithm that uses the biases already known to significantly reduce the search space. It's just a matter of time until someone does this!

In summary, I think RC4 is as close to broken as you can get without being able to recover arbitrary plaintext. It should be retired urgently and nobody should be using it. Least of all Google.


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 ;-)

  • 3
    $\begingroup$ 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. $\endgroup$ Commented May 30, 2012 at 10:21

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.


Note that the above discussion may be out of date after the Snowden revelations. For example, see the "Hardening Internet Infrastructure" panel at IETF88 where Schneier speculates that the NSA expects to be able to break RC4 and is recruiting staff to do so.

In the black budget that was released, DNI, James Clapper has a quote. He said, "We are investing in ground-breaking cryptographic capabilities to defeat adversarial cryptography and exploit Internet traffic."

That doesn't sound like we're hiring a bunch of mathematicians and hope we get lucky. All right? That sounds like we have something at the edge of practicality and we're investing to make it practical.

We don't know what that is. We're likely not to. I mean, I have a few guesses. First one is elliptic curves. It's perfectly reasonable that they have some advances that we don't in elliptic curve cryptography, either generic techniques to break it quicker or classes of curves that they know about that if they can steer us to use, they have an advantage.

The second are general factoring and discrete log advances. We in the academic community get advances every few years. Assume they're a decade or so ahead.

The third is a practical attack against RC4. And my ordering of these changes depending on what day it is. But those are my guesses. A long shot of something (indiscernible) ES. I really doubt it, but you know, I wouldn't put it beyond possibility.

  • $\begingroup$ Hello and welcome to Crypto.SE. Please consider adding a link to the document you mention, as well as quoting the relevant passages. If the information you mention makes RC4 substantially insecure, do include it here as it's directly relevant. Cheers $\endgroup$
    – rath
    Commented Nov 15, 2013 at 3:15

A major problem we still face is fazing out old encryption standards with vulnerabilities, without breaking web access to many sites and services for machines or networks running older software like WinXP and IE8, or that may have a high upgrade cost. I think we should just start forcing the issue however by announcing a timeline in which any vulnerable standards should be removed.

In the leaked Snowden documents released so far there are references to the NSA already using very powerful super computers to try and exploit crypto as large as 2048-bit RSA keys as well as targeting others like AES. Comments alluded to such enormous breakthroughs that only the chairman and vice chairman and the two staff directors of each intelligence committee were told about it

From Bruce Shneier's blog

We’re already trying to phase out 1024-bit RSA keys in favor of 2048-bit keys. Perhaps we need to jump even further ahead and consider 3072-bit keys.

He later published a new public key of length 4096.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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