(No Ratings Yet)

Loading...

• Facebook
• Twitter
• LinkedIn
• Mail

September 7, 2016 Comments closed

Browser Watch: Tracking SSL Changes in Chrome 53

in Industry Lowdown

Chrome 53 sees DHE removed and Symantec CT Policy enforced.

Google Chrome 53 has hit the stable channel, which means Windows, Mac, and Linux users should be able to update to the latest version now.

With every new version of Chrome, Google’s team makes improvements to the browser’s security. It seems that this always involves at least one change to Chrome’s SSL/TLS or networking capabilities.

In Chrome 53 there were two major changes in the SSL/TLS sector:

DHE Ciphers Removed

Last year, researchers found that Diffie Hellman Ephemeral (DHE) key exchange had multiple weaknesses that made it unsuitable for encryption. The researchers demonstrated an attack based on their research known as “Logjam.” Since that research was published, browsers have been restricting the use of DHE-based ciphers.

Now, in Chrome 53, DHE is being entirely removed. This means Chrome clients will no longer be able to connect to servers that only offer DHE ciphers. An extremely small number of sites offer only DHE; most that still support DHE only prefer it , and connections will be made with another supported cipher.

The weaknesses in DHE are fixable, but it just isn’t worth the effort. To be adequately secure, DHE needs to be negotiated with 2048-bit keys. But because of the way DHE is negotiated, it’s not realistic to make that switch.[1] 2048-bit DHE is also incredibly slow – more than 10x slower than other popular key exchange methods (RSA, ECDHE).[2]

David Benjamin, a security engineer with Google, wrote “1024-bit [DHE] is insufficient for the long-term. However, metrics reported that around 95% of DHE connections seen by Chrome use 1024-bit DHE.”[3] Instead of having those servers reconfigured to support secure DHE, Google instead suggests sites move to ECDHE suites, which are widely supported by clients, offer better security, and better performance.

Chrome is following Safari’s lead, as the Apple browser was the first major browser to entirely remove DHE support.

Certificate Transparency required for Symantec certificates

Last year, Symantec was found to have mis-issued a large number of certificates as part of an error in a system meant for test certificates. In response to this incident, Google required that all of Symantec’s certificates be logged to Certificate Transparency (CT) logs, which would give the community better oversight of Symantec’s issuance practices.

This requirement applies to all Symantec certificates issued after June 1, 2016. This includes all of Symantec’s CA brands, which include GeoTrust, Thawte, and RapidSSL.

In Chrome 53 that requirement is now being enforced. Any Symantec issued certificate issued after June 1^st that is not logged will present a full-page error (with the error code NET::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED). For the most part, this should not be an issue for end users as Symantec logs all newly issued certificates by default.

Wrap Up

Chrome 53 also fixes two address bar spoofing bugs – the one discovered by researcher Rafay Baloch that we covered last month, which allowed for pretty convincing phishing, and another bug that has yet to be disclosed (it is common practice for vendors to withhold details of bugs and vulnerabilities until a majority of users have updated).

That’s it for the major changes to Chrome’s SSL/TLS capabilities and behavior in version 53! We will be covering changes to SSL/TLS capabilities and policies in for all major browsers, so make sure to check back for each release.

---

[1] In DHE negotiation, a “group” is used to generate encryption keys. The difficulty of changing the group that a given server uses is why switching to 2048-bit DHE is impractical. 2048-bit DHE support is also not available with some clients. To read more on the problems with deploying 2048-bit DHE, read Google’s intent to remove thread and the WeakDH.org.

[2] Based on data from Bulletproof SSL & TLS. Across 1000 handshakes, DHE 2048 key exchange took 10.57 seconds of CPU time on the client side and 6.89 seconds on the server. In comparison, RSA and ECDHE methods took less than 2 seconds. Figure 9.3 Performance comparison of TLS key exchange algorithms in Ristic, Ivan. Bulletproof SSL and TLS. Feisty Duck, 2014.

[3] https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/ShRaCsYx4lk/46rD81AsBwAJ

 

• #Browsers
• #Chrome 53
• #Google
• #SSL