Google Details Plans to Disable SSLv3 and RC4

As expected, Google formally announced its intent to move away from the stream cipher RC4 and the protocol SSLv3 this week, citing a long history of weaknesses in both.

As expected, Google formally announced its intent to move away from the stream cipher RC4 and the SSLv3 protocol this week, citing a long history of weaknesses in both.

Adam Langley, a security engineer for the company, announced the plans through a blog post on Thursday. While there isn’t a concrete timeline, Langely insisted that Google is looking to do away with support for RC4 and SSLv3 in all of its frontend servers, Chrome, Android, webcrawlers, and SMTP servers, in the medium term.

The fact that the company is looking cut ties with both mediums shouldn’t come as little surprise.

The Internet Engineering Task Force condemned SSLv3 in an Internet Standards Track document over the summer, calling it “not sufficiently secure,” adding that “any version of TLS is more secure than SSLv3.”

As Langely notes in the blog, RC4 is 28 years old, and while it fared well in the early goings, it’s been the target of multiple attacks over the years, including some that can lead to TLS session compromise and cookie decryption.

As part of the switch Google also announced a collection of minimum standards for TLS clients going forward. According to the post, Google will eventually require the following of devices:

  • TLS 1.2 must be supported.
  • A Server Name Indication (SNI) extension must be included in the handshake and must contain the domain that’s being connected to.
  • The cipher suite TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 must be supported with P-256 and uncompressed points.
  • At least the certificates in https://pki.google.com/roots.pem must be trusted.
  • Certificate handling must be able to support DNS Subject Alternative Names and those SANs may include a single wildcard as the left-most label in the name.

Langley notes that devices that don’t meet the requirements won’t stop working anytime soon, but acknowledges they may be affected by TLS changes later down the line, up to the year 2020.

“If your TLS client, webserver or email server requires the use of SSLv3 or RC4 then the time to update was some years ago, but better late than never. However, note that just because you might be using RC4 today doesn’t mean that your client or website will stop working: TLS can negotiate cipher suites and problems will only occur if you don’t support anything but RC4,” Langley wrote.

Langely announced cursory plans to deprecate RC4 earlier this month in a post to the security@chromium.org mailing list, confirming that the cipher would be disabled in a future Chrome build, likely stable around January or February 2016.

The company has already taken one step towards nixing SSLv3: a month after last fall’s POODLE attack it did away with support for the fallback to SSLv3 in Chrome, a move that went hand in hand with the company’s phasing out of the SHA-1 cryptographic hash algorithm.

Suggested articles