How TLS 1.3 became the new standard for data transfer security



TLS 1.3 is the latest version of the TLS transport layer protocol, which is responsible for secure transmission and message integrity.

When did TLS 1.3 come along?

TLS 1.3 was developed in August 2018 and is described in RFC 8446. They started working on it back in 2014. By that time, 80% of traffic on Chrome and 70% on Firefox was transferred through secure connections. However, the previous version of the protocol (TLS 1.2) no longer met security and performance requirements.

What problems did TLS 1.2 have?

TLS 1.2 was developed in 2008. At that time, only desktop computers were used to access the internet. Now, on the other hand, everyone has a smartphone, and people go online from mobile devices more often than from computers. However, the latter have less computing power than PCs, so in order for websites to load quickly enough on smartphones, it was necessary to reduce the connection setup time.

Another issue with TLS 1.2 was associated with multiple attacks. There were so many of them that a separate document was created to describe them—RFC 7457.

TLS 1.3 resolved these issues. In this article, we’ll tell you how the new version differs from TLS 1.2 and what features it has.

How is TLS 1.3 different from TLS 1.2?

The main advantages of TLS 1.3 are better performance and security.

Security

1. Banning outdated technologies. TLS 1.2 supports many outdated technologies that are currently not considered secure, such as MD5, SHA-1, 3DES, DES, or AES-CBC. TLS 1.3 dropped these technologies.

At the same time, security in the new version takes precedence over backward compatibility. Therefore, if a device still supports only outdated protocols, the connection with it won’t be established.

Several new ciphers have been added to the protocol. As a result, TLS 1.3 only supports AEAD ciphers—they provide both data encryption and MAC creation. These ciphers are considered more secure, and here’s why.

If different ciphers are responsible for encrypting a message and creating a MAC, and individually they provide security, this doesn’t mean that together they will also provide security. TLS 1.2 used cipher suites to solve this problem. However, they’re vulnerable to some types of attack, while the AEAD ciphers relieve the protocol of this problem.

2. Perfect forward secrecy. TLS 1.3 uses only algorithms that provide PFS—Perfect Forward Secrecy. This technology requires that new encryption keys be generated for each new session. Thus, even if an attacker manages to intercept the message and then, after some time, gain access to the key, they still won’t be able to decrypt the data, since the key will already have changed. That’s why TLS 1.3 prohibits the RSA static private key algorithm and the static Diffie Hellman algorithm.

Consequently, only a limited cipher suite remains in the protocol, which helps not only to strengthen security, but also to improve performance. But more on that later.

3. Prohibiting renegotiation of TLS. Renegotiation in TLS 1.2 allowed the details of the handshake to be changed after the connection had already been established. That was a vulnerability and is prohibited in TLS 1.3.

Performance

1. Simplified handshake process. It was reduced to 1-RTT, which made it possible to reduce the connection setup time by almost 2 times.

In TLS 1.2:

1. The client sends a Client Hello message to the server and the list of ciphers it supports.
2. The server selects a cipher suite that it can work with and sends it to the client in a Server Hello message.
3. Only after that are the keys exchanged between the client and the server.

TLS 1.3 has a smaller cipher suite. Therefore, in the first message, the client assumes which cipher the server supports.

1. Along with the Client Hello message, the client sends the information for key exchange.
2. In response, the server sends a Server Hello message, its key exchange information, a certificate, and a Finished message.

If the client’s assumption turned out to be incorrect and the server does not support the required cipher, then the server sends a HelloRetryRequest (a request to resend Hello) in response along with information about the ciphers it supports. After that, everything happens according to the standard scheme.

2. 0-RTT—a new approach to connection renewal. 0-RTT allows you to restore the session as quickly as possible. If the user visited the site, then closed it, and after a while decided to return, then the client and the server won’t carry out the entire handshake process.

1. In the Client Hello message, the client includes information about the previous session and simultaneously sends encrypted data. It’s encrypted with the keys that were used the last time.
2. The server sends its key information and encrypted data in a Server Hello message.

This way, data exchange takes place even before the connection is renewed, in the first messages, which greatly speeds up page loading, especially on smartphones.

Currently, TLS 1.3 automatically supports most popular browsers, such as Chrome, Firefox, and all Microsoft browsers. The complete transition of the entire internet to the new version of the protocol is only a matter of time.

How do we use TLS 1.3 when delivering content?

Our customers often ask whether our CDN supports the new protocol version. Here’s our answer.

We implemented TLS 1.3 as soon as it appeared, back in 2018. The protocol uses all technologies by default, including 0-RTT.

How do I set up data transfer over TLS 1.3?

The protocol is supported for all customers by default. If you have already signed up for the Gcore CDN, you don’t need to do anything else.

If you’re not using the CDN yet, it’s time to give it a try! With the help of our network, not only will your content be delivered as quickly as possible, but it will also be perfectly secure.

Try a secure CDN