Tell HN: My Gmail connection switched from RC4 variant to AES_128_GCM today
The title about says it. As I've mentioned before, while I'm far (far) from an expert in such things, I've found it interesting over the past some years to note the changes in the certificate chains and connections that Google deploys for Gmail and its other properties. Looks like they are moving from RC4? (Sorry I don't remember the exact variant off the top of my head; I plead age.)
2 comments
Google continues to set the standard for high-security TLS connections; they are the world's biggest target, and they clearly take that seriously.
RC4 is a terribly broken cipher. It was known to be broken in the late '90s and was included in SSL more as an accident of history than anything else. Unfortunately, SSL was standardized before researchers fully understood the interactions between encryption and message authentication, and SSL botched block encryption (and thus AES). So, for the past ~4-5 years, big companies have been using RC4 as a stopgap for dealing with vulnerabilities stemming from SSL's botched AES construction.
That doesn't work anymore, because the flaws in RC4 are now known to be far more grave than they were previously though.
Add support for AES-GCM, the only rigorously secure ciphersuite available to TLS, to the laundry list of other things Google has done to improve Internet security --- forward secrecy, certificate pinning, detection of forged certificates, patching the Lucky 13 vulnerability.
RC4 is a terribly broken cipher. It was known to be broken in the late '90s and was included in SSL more as an accident of history than anything else. Unfortunately, SSL was standardized before researchers fully understood the interactions between encryption and message authentication, and SSL botched block encryption (and thus AES). So, for the past ~4-5 years, big companies have been using RC4 as a stopgap for dealing with vulnerabilities stemming from SSL's botched AES construction.
That doesn't work anymore, because the flaws in RC4 are now known to be far more grave than they were previously though.
Add support for AES-GCM, the only rigorously secure ciphersuite available to TLS, to the laundry list of other things Google has done to improve Internet security --- forward secrecy, certificate pinning, detection of forged certificates, patching the Lucky 13 vulnerability.
[replacing a somewhat rambling and distracted response with a "never mind..."
...Or not; it appears my edit to this overlapped a response, so I'm putting my rambling comment back, below]
----
Checking now, it looks as if, as of today at least, Facebook is also using/preferring AES_128_GCM. Again, I don't have a specific note-to-self to refer to, and my memory's a bit fuzzy, but I seem to recall that until recently they were using AES_128_CBC, or something else other than GCM.
If you've time to answer, are you familiar with this use and change (am I right, specifically?) and if so might I impose for a sentence or two on what improvement the change to GCM brings?
Regardless, thanks for the description and qualification in your parent comment.
P.S. Upon reflection, I think I recall Facebook using AES_128_GCM for some time now, although I seem to recall -- perhaps incorrectly -- their using something else at some point after they switched to ECDHE_RSA.
I mostly look at the certificate chains as a check against obvious man in the middle situations. Again, I'm not claiming any kind of expertise, but I do have a certain degree of curiosity.
P.P.S. So maybe I shouldn't have asked/imposed my follow-up. Or maybe a better question would be, how is Facebook doing / regarded with respect to this aspect of security, these days?
...Or not; it appears my edit to this overlapped a response, so I'm putting my rambling comment back, below]
----
Checking now, it looks as if, as of today at least, Facebook is also using/preferring AES_128_GCM. Again, I don't have a specific note-to-self to refer to, and my memory's a bit fuzzy, but I seem to recall that until recently they were using AES_128_CBC, or something else other than GCM.
If you've time to answer, are you familiar with this use and change (am I right, specifically?) and if so might I impose for a sentence or two on what improvement the change to GCM brings?
Regardless, thanks for the description and qualification in your parent comment.
P.S. Upon reflection, I think I recall Facebook using AES_128_GCM for some time now, although I seem to recall -- perhaps incorrectly -- their using something else at some point after they switched to ECDHE_RSA.
I mostly look at the certificate chains as a check against obvious man in the middle situations. Again, I'm not claiming any kind of expertise, but I do have a certain degree of curiosity.
P.P.S. So maybe I shouldn't have asked/imposed my follow-up. Or maybe a better question would be, how is Facebook doing / regarded with respect to this aspect of security, these days?
AES-GCM is quite nice. It's a "modern" construction that both runs AES in a stream cipher mode and integrates it tightly with a fast message authentication code. The "GCM" in "AES-GCM" mostly alludes to GHASH, the MAC function, which is a fast polynomial universal hashing MAC, in roughly the same family as Daniel Bernstein's Poly1305.
What's especially nice about AES-GCM is that the "mode" itself takes care of guaranteeing both message confidentiality and integrity. The TLS working group does not need to do much joinery and decisionmaking to make GCM work; the mode itself is standardized to provide those capabilities. The less you ask of the TLS working group, the more you put on the fundamental crypto, the better off you are.
(As it happens, the very little decisionmaking latitude the TLS WG actually had for AES-GCM resulted in a weakness! Though not an especially meaningful one.)
Facebook also has a good security team. Google has the advantage/beneficence of running an important browser project that is itself committed to moving the ball forward on TLS, which is an advantage Facebook lacks.
What's especially nice about AES-GCM is that the "mode" itself takes care of guaranteeing both message confidentiality and integrity. The TLS working group does not need to do much joinery and decisionmaking to make GCM work; the mode itself is standardized to provide those capabilities. The less you ask of the TLS working group, the more you put on the fundamental crypto, the better off you are.
(As it happens, the very little decisionmaking latitude the TLS WG actually had for AES-GCM resulted in a weakness! Though not an especially meaningful one.)
Facebook also has a good security team. Google has the advantage/beneficence of running an important browser project that is itself committed to moving the ball forward on TLS, which is an advantage Facebook lacks.
"Meaningful" was the wrong word here, FWIW.
What's a little surprising is that during the stopgap years, nobody adopted the bandaid of "RC4 but skip the first X bytes". That's been a known and reasonable workaround since AES was standardized.
While it is weird that nobody ever pushed for RC4-skip-1024, it wouldn't have actually fixed anything; the Fluhrer-McGrew biases recur throughout the whole keystream, have been known for many many years, and turn out to be the more efficient attack vector anyways.
Oh. I was under the impression it still made the TLS attacks harder. Not impossible, but requiring even more traffic. So you're saying no effect, as opposed to not enough effect? Just for clarity.
The attack on the RC4 biases (both kinds) is very simple: it just involves collecting samples and using basic statistics to predict the most likely keystream byte.
Because the Fluhrer-McGrew digraph biases recur through the keystream, successive samples don't require a TLS session setup and key exchange; you can reuse a single session to collect many samples. So, while the digraph biases provide a weaker signal, the attack on them actually runs faster.
Net-net, from what we know now, RC4-drop-1024 would have had no effect at all on the security of TLS. That could change, but when I look at the digraph biases, I think it's the digraph biases that are going to get more effective.
Because the Fluhrer-McGrew digraph biases recur through the keystream, successive samples don't require a TLS session setup and key exchange; you can reuse a single session to collect many samples. So, while the digraph biases provide a weaker signal, the attack on them actually runs faster.
Net-net, from what we know now, RC4-drop-1024 would have had no effect at all on the security of TLS. That could change, but when I look at the digraph biases, I think it's the digraph biases that are going to get more effective.
cool.
Might have something to do with this: http://googleonlinesecurity.blogspot.com/2013/11/out-with-ol...