Changes to Network and Security in Chrome 51
1 Star2 Stars3 Stars4 Stars5 Stars (No Ratings Yet)

Changes to Network and Security in Chrome 51

Here’s a comprehensive look at all the changes coming with Google Chrome 51

Chrome 51 will be hitting the stable channel by the end of May. When that happens, quite a few changes to Chrome’s SSL/TLS capabilities and behaviors will launch, as well as some improvements to Chrome’s network protocols. For those looking to get deep into the nitty-gritty, we have summarized the relevant changes.

SPDY/3.1 Removed: SPDY was Google’s intermediate replacement for HTTP/1.1. If you have ever worked with a standards group before, you know that work moves slowly, and the IETF is no exception. While HTTP/2 was still being finalized, Google designed and started using SPDY, which implemented some of the same improvements. Now that HTTP/2 is officially finished, SPDY is no longer needed.

Some webserver software supports SPDY, but has yet to support HTTP/2. So the removal of SPDY from Chrome will push some sites back to HTTP/1.1. This, in combination with the removal of the NPN protocol, will set back HTTP/2 adoption in the short term, but, overall, is prepping the web for one of its biggest updates in years.

NPN (Next Protocol Negotiation) Removed: NPN and ALPN are protocols used in negotiation during the TLS handshake. During connection negotiation, the client and server have a choice of using one of these protocols. ALPN is viewed as a superior option, but is not as widely supported by web server operating systems.

Diffe-Helman ciphers deprecated: Diffe-Helman ciphers, also known as “DHE” (Diffe-Helman Ephemeral), have quite a few problems, in both their construction and implementation. It’s serious enough that the security community no longer advises using them. In Chrome 51, a Javascript console warning will trigger when using DHE ciphers. In Chrome 52, DHE ciphers will be removed entirely. DHE is only used by 2% of connections, and most of those sites support other suites, so breakage will be minimal. For those looking for a replacement to DHE, Google recommends ECDHE.

To see what cipher suites your server is configured to use, run the free SSL Labs test, and look for the section named “Cipher Suites”.

AES_256_GCM cipher added: AES has long been supported in Chrome in both GCM and CBC modes. But until recently, if you wanted to use 256-bit keys, you were stuck with CBC. This was a problem due to the way many webservers set their cipher suite preferences.

For those very familiar with cryptography, you will know that the number of bits of security isn’t important if the algorithm or mode is weak or broken. Unfortunately, many people less familiar equate more bites to better security.

For that reason, we see a large number of servers that prioritize by bit size instead of mode, placing 256-bit ciphers over 128-bit ciphers. Servers rightly placed AES_256_GCM first, but when that was not supported by Chrome, the next option was AES_256_CBC (instead of AES_128_GCM, which would have been ideal). The CBC mode is known to be problematic, and triggers the “obsolete cryptography” warning in Chrome, and should be avoided when possible.

By adding AES_256_GCM, Chrome will join Internet Explorer and Safari, and automatically improve the connection strength for thousands of servers. Remember that GCM ciphers are only compatible with TLS 1.2.

‘SameSite’ Cookie Attribute Added: This is a new cookie attribute that can be set by the server which instructs that the cookie should only be modified by requests originating from the same domain. This helps mitigate cross-origin and cross-site attacks which attempt to induce XSS (cross-site scripting), authentication forgery, or similar attacks.

Be the first to comment

Leave a Reply

Your email address will not be published. We will only use your email address to respond to your comment and/or notify you of responses. Required fields are marked *

Captcha *