I was reading about Google's usage of RC4 and an answer on stackexchange website stated the following:
I know Google uses RC4 for most of its services, and this is the reason one shouldn't keep gmail opened all the time ;-)
Is this true? What sort of attacks can be done if we're exchanging information for too long using RC4? and how long(or how much of data) is too long?
There are known biases in RC4 output, especially in the first bytes of the stream. In the "Gmail scenario", the client (Web browser) regularly connects to the server to poll for new incoming messages. Each connection implies encrypting the request data with a fresh RC4 stream; and all the requests will contain the same secret value at the same place in the stream (the HTTP cookie). Over time, an attacker observing the streams may do statistics to work out the data bytes of the said secret. See this blog post for some explanations.
Note, though, that in practice it does not work (yet). The attack is cryptographically real; however, the "Gmail scenario" does not do enough connections to allow the biases to become really dangerous. The safety margin is small (uncomfortably small), but it is there. Namely, it takes millions of connections for the biases to begin to show up, and, moreover, the "interesting bytes" for the attacker are a bit too far down the stream (a HTTP request will begin by the "verb + path" string, then other headers, the cookie coming only after a few hundred bytes; the biases are biggest at the beginning, but the farther the secret is, the less efficient the attack becomes). Assuming a connection every minute (Gmail does not do connections that often) it would still take 30 years of continuous observations to begin obtaining actual secret bytes, even if the cookie appears "early" in the HTTP header.
So while these biases ring as a warning bell, telling us that RC4 is flaky and we should be wary of using it, they do not mean that RC4-protected SSL can be routinely broken through. Google uses RC4 (that is, they support RC4 and they configured their servers to prefer RC4 whenever possible) because of all the noise which was made about the BEAST attack on block ciphers which use CBC. The BEAST attack setup is heavy and was demonstrated in lab conditions only; never spotted in the wild; and Web browsers promptly included countermeasures so the attack does not actually work in practice. So, in effect, Google has to choose between two attacks which do not work, and do things which will disable one or the other (although in practice neither works). This is not a cryptographic issue; this is a public relations problem. Right now, Google prefers RC4 because they consider that, in the view of the general public, BEAST is "scarier" (maybe because the BEAST was presented as a Youtube video whereas the RC4 biases were first publicized as a 335-slides technical presentation; it is no wonder that the former better took to the public eye than the latter).
In any case, Google can switch its server configuration at any time. As long as they keep track of advances in cryptology (they do), things will be fine.
Youtube was working fine with RC4/RSA blacklisted in the browser, and all of a sudden today I get this server https://r4---sn-2apm-f5f6.googlevideo.com
It doesnt want to go higher than TLS_RSA_WITH_RC4_128_SHA
For all intents and purposes it looks like they DOWNGRADED their content servers :o
