Commonly reported SSL/TLS vulnerabilities

Reporters sometimes point out that the SSL/TLS configuration of one of our services is vulnerable to some of the SSL/TLS vulnerabilities disclosed in recent years. BEAST/CRIME/POODLE are often mentioned, together with the usage of the RC4 cipher. We always carefully validate each report and the above issues often turn out to be invalid. We would like to share with you some details of why this is the case.

As for CRIME, BEAST or POODLE - that's pretty unlikely, as we have various mitigations in place that are sometimes not detected by automated scanners. For example, we use so-called TLS record splitting to mitigate BEAST, and TLS fallback prevention to mitigate POODLE. In fact, all of these vulnerabilities were discovered by members of the Google Security Team - so chances are, we have gotten it right :-).

The matter is a bit more complex with the support for problematic ciphers and/or protocols in our frontend servers. Here, we rely on gradual deprecation. As described by Google Security Team member Emilia Kasper:

Google has announced a deprecation plan for SSLv3 and RC4, but it's not possible to simply switch them off overnight. Google Frontends (GFEs) have to support a wide range of clients, so big changes like this require careful roll-out. Meanwhile, GFEs continue to negotiate the most secure available TLS configuration. GFEs will never offer SSLv3 or RC4 to a client if more secure options are available.

GFEs will negotiate SSLv3 only if the client does not support any higher protocol versions. Some clients will attempt to fall back to earlier protocol versions if the initial connection fails, and an attacker could try to use this to force a client onto SSLv3. To mitigate this risk, GFEs also support TLS Fallback SCSV, a countermeasure against such downgrade attacks. For this mitigation to be effective, the client needs to support it as well; or it simply shouldn't fall back.

Similarly, GFEs will prefer RC4 over AES-CBC only for low protocol versions (SSLv3/TLSv1) because negotiating these versions with AES-CBC would leave the clients vulnerable to POODLE.

A modern client that supports at least TLSv1.1 and either doesn't do any version fallback or only does secure fallback with SCSV will never get SSLv3 or RC4 from Google, and an attacker can't force them onto these legacy configurations either. This is true even if the client and Google both support SSLv3 and RC4. For the connection between them to be secure, it's not necessary to disable SSLv3 or RC4 on either end; it's only necessary that both ends support something better. To that end, GFEs offer a range of secure alternatives: TLSv1.2 with AES-GCM and CHACHA20-Poly1305 are among our supported configurations.

Of course, if our systems are not behaving like described above or if you have reviewed the mitigations we've used and still think we've missed something then please let us know.