X
Tech

Google advances SSL with new Chrome versions

The latest stable version of Chrome removes the source of the POODLE bug and SSLv3 support will be out altogether over time. The Canary version disparages implementations not up to standards.
Written by Larry Seltzer, Contributor

The latest versions of Google Chrome show the company moving aggressively past older, insecure versions of SSL and giving more information about the versions in use.

Much of this is fallout from the discovery of the POODLE bug last month, but problems with older versions of SSL and TLS have been well-known for some time. Google's Adam Langley said in an October blog, "... everything less than TLS 1.2 with an AEAD mode is cryptographically broken."

It was in that same blog that Langley announced accelerated plans for Google's SSL/TLS support. He immediately created a Chrome patch to remove support for fallback to SSLv3, the enabler of the POODLE bug. That patch became effective in the new version 39 of Chrome which went out yesterday on the Stable Channel. (Oddly, the change was not noted in any announcement or even the changelog, but Langley announced it in a tweet.)

Langley also announced that version 40 will disable default support for SSLv3 and that, "... [i]n time, SSLv3 client support will be removed from the code".

Chrome 39 also rolls out "BoringSSL," Langley's name for their own fork of SSL/TLS code. They will continue to contribute to, take code from and share information with OpenSSL and LibreSSL. The point is to give them more control over which features go into Chrome. Langley plans eventually for BoringSSL to be used in Android and internal projects.

Hat tip to Dennis Fisher on ThreatPost, especially for pointing to the Adam Langley tweet.

The Canary version (41) of Chrome introduces some interesting cosmetic changes. Canary is, by definition, an experimental version, so this language could change or disappear altogether when this version hits the Stable Channel.

In the Canary build Google has begun using the words "obsolete" and "modern" to describe implementations of SSL/TLS. The image below shows two examples:

TLSCanary-messages

This language only appears when the user investigates connection properties of an SSL/TLS site, so it's nothing the average user would see, but it could eventually translate into more conspicuous visual cues.

Hat tip to Michael Reschly on Twitter

Editorial standards