Bringing Modern Transport Security to Google Cloud with TLS 1.3

We spend a lot of time thinking about how to improve internet protocols at Google—both for our Google Cloud customers and for our own properties. From our work developing SPDY into HTTP/2 and QUIC into HTTP/3, we know that improving the protocols we use across the Internet is critical to improving user experience.

Transport Layer Security, or TLS, is a family of internet protocols that Google has played an important role in developing. Formerly known as SSL, TLS is the main method of securing internet connections between servers and their clients. We first enabled TLS 1.3 in Chrome in October 2018, at the same time as Mozilla brought it to Firefox. Today, the majority of modern clients support TLS 1.3, including recent versions of Android, Apple’s iOS and Microsoft’s Edge browser, as well as BoringSSL, OpenSSL and libcurl. Support for TLS 1.3 is wide-ranging, and brings performance and security benefits to a large part of the Internet.

Given this, we recently rolled out TLS 1.3 as the default for all new and existing Cloud CDN and Global Load Balancing customers. TLS 1.3 is already used in more than half of TLS connections across Google Cloud, nearly on-par with Google at large.

To gain confidence that we could do this safely and without negatively impacting end users, we previously enabled TLS 1.3 across Search, Gmail, YouTube and numerous other Google services. We also monitored the feedback we received when we rolled out TLS 1.3 in Chrome. This prior experience showed that we could safely enable TLS 1.3 in Google Cloud by default, without requiring customers to update their configurations manually.

What is TLS 1.3, and what does it bring?

TLS 1.3 is the latest version of the TLS protocol and brings notable security improvements to you and your users, aligned with our goal of securing the Internet.

Specifically, TLS 1.3 provides:

• Modern ciphers and key-exchange algorithms, with forward secrecy as a baseline.

• Removal of older, less-secure ciphers and key exchange methods, as well as an overall reduction in the complexity of the protocol.

• Low handshake latency (one round-trip between client and server) for full handshakes, which directly contributes to a good end-user experience.

This combination of performance and security benefits is particularly notable: the perception is often that one must trade off one for the other, but modern designs can improve both. Notably, TLS 1.3 can have outsized benefits for users on:

• Congested networks, which is particularly relevant during times of increased internet usage.

• Higher-latency connections—especially cellular (mobile) devices—where the reduction in handshake round-trips is particularly meaningful.

• Low-powered devices, thanks to the curated list of ciphers.

For example, Netflix also recently adopted TLS 1.3, and observed improvements in user experience around playback delay (network related) and rebuffers (often CPU related).

As an added benefit, customers who have to meet NIST requirements, including many U.S. government agencies and their contractors, can begin to address the requirement to support TLS 1.3 ahead of NIST’s Jan 1, 2024 deadline.

What’s next?

TLS 1.3 has quickly taken responsibility for securing large swaths of Google Cloud customers’ internet traffic, and we expect that proportion to grow as more clients gain support for it. We’re (already!) working on the next set of modern protocols to bring to our Google Cloud customers—including TCP BBRv2, as well as IETF QUIC and HTTP/3, which are close to being finalized. We’re also planning to support TLS 1.3 0-RTT (though customers will need to update their applications to benefit from it) and certificate compression. 

Click here to learn more about how Google Cloud secures customer traffic using TLS across our edge network, and how to secure your global load balancer using SSL policies.