Nine years after the release of TLS 1.2, and four long years of agreement on it, TLS 1.3 is now available, designed with the simple goal of making data transfers faster and more secure.

More secure

TLS uses a hybrid encryption process, which means that symmetric encryption is used during communication and the key for that encryption is negotiated through asymmetric encryption. The MAC algorithm is used for integrity checking and the certificate system is used for authentication. This process may sound perfect, but the reality is not always so rosy.

Forward Security

Forward Secrecy (FS), also known as Perfect Forward Secrecy (PFS), is a concept in cryptography that refers to the fact that a compromise of a long-used master key does not result in the compromise of keys from past sessions; in other words, if an attacker saves traffic from past encrypted sessions and also obtains the private key, it still cannot decrypt all sessions.

Forward security is one of the most critical features in TLS 1.3.

RSA and DH

The key part of the TLS handshake is to negotiate the key for subsequent communication, which is divided into two key exchange algorithms, RSA and Diffie-Hellman.

RSA is a common and simple algorithm for exchanging keys, i.e., the client decides the key and transmits it to the other party encrypted with the server’s public key, so that both communicating parties have the key for subsequent communication.

Diffie-Hellman (DH) is another algorithm for exchanging keys, where both the client and the server generate a pair of public and private keys, and then send the public key to the other party. After both parties get the other party’s public key, they use digital signatures to ensure that the public key has not been tampered with, and then combine it with their own private keys to compute the same key.

Both methods were once used to exchange keys, but RSA has the disadvantage that it is not forward-secure, because when the server private key is compromised, all communications can be decrypted and the security depends entirely on the security of the server private key. For DH algorithm, as long as a new key pair is generated for each communication, the decrypted key will be different for each communication.

To ensure forward security, the RSA algorithm is removed from TLS 1.3, and Diffie-Hellman is the only key exchange algorithm.

More potential pitfalls

Besides the above mentioned key exchange algorithms are problematic, some symmetric encryption algorithms and digital signature algorithms also have vulnerabilities, such as CBC, RC4, SHA1.

The method of computing MAC before encryption also has security risks, so the mechanism of using MAC for block encryption and stream encryption is also deprecated, and AEAD becomes the only choice.

At the same time, compression of encrypted TLS messages is vulnerable and is no longer allowed; DH itself has forward security and renegotiation is no longer allowed. The mechanism by which the Change Cipher Spec used to determine when to start transmitting encrypted data is also deprecated, as it can be started naturally with the completion of the handshake.

In addition, in the past, the handshake server signed only part of the content, and the part of the negotiation using the algorithm suite was not signed, and an attack would have tampered with this part, forcing both communicating parties to use weak ciphers and weak algorithm suites. But these too are now history, as TLS 1.3 signs the entire handshake, and the plaintext part of the handshake phase is greatly reduced.

Unfortunately, SNI is still a clear-text transmission

Too much choice is not a good thing

The algorithm suite for TLS negotiation covers almost all the details of a connection, and a suite of algorithms includes the following.

  • Supported certificate types
  • Hashing algorithms for deriving keys (SHA1, SHA256, …)
  • Message Authentication (MAC) functions (HMAC with SHA1, SHA256, …)
  • Key exchange algorithms (RSA, ECDHE, …)
  • Algorithms for symmetric encryption (AES, RC4, …)
  • Algorithms working in encryption mode (CBC, …)

Each part of the past TLS offered a large number of options, which, together with various combinations, resulted in a large number of smelly and long names like DHE-RSA-AES256-GCM-SHA384.

TLS 1.3 simplifies the negotiation of the algorithm suite by removing all known insecure algorithms, while changing the algorithm suite into three orthogonal parts.

  • the encryption algorithm and the HKDF hash algorithm
  • Key exchange algorithm
  • Signature algorithm

HKDF (HMAC based Key Derivation Function) is to solve the lack of randomness in generating keys, so that the hash value of the handshake phase and the negotiated key can be passed through this function to obtain a more secure key.

Compared to 1.2, which has more than thirty algorithm suites, 1.3 currently has only these five suites.

  • TLS_AES_256_GCM_SHA384
  • TLS_CHACHA20_POLY1305_SHA256
  • TLS_AES_128_GCM_SHA256
  • TLS_AES_128_CCM_8_SHA256
  • TLS_AES_128_CCM_SHA256

Faster

Let’s recall the time taken for the TLS 1.2 handshake.

  1. client →→ server: Client Hello (supported encryption suites, key negotiation material, etc.)
  2. client ←← server: Server Hello (certificate, selected cipher suite, etc.)
  3. Client →→ Server: Pre Master Key (RSA) or Client Public Key (DH)

At this point both parties have obtained all the materials needed to calculate the session key and can subsequently start using the negotiated key to continue communication, a process that takes 1.5 RTT.

1-RTT

Yes, TLS 1.3 reduces the RTT by half, thanks to the simplification of key negotiation. Now we can only choose DH, and the server can support so few parameters that it is so easy to guess, so the client can send the first message with the public key and all the key negotiation material directly, rather than waiting until the server chooses the suite to adopt.

Thus, the handshake process can now be simplified as follows

  1. client →→ server: client’s public key
  2. client ←← server: certificate, server’s public key

In the rare case that a server is not supported, then a HelloRetryRequest is sent to retry the connection, but this is extremely rare.

0-RTT

Yes, you read that right, it is possible to send encrypted content directly without RTT, just like HTTP.

Of course, this assumes that the client has already established a connection with the server, after which both parties can export something called a Pre-Shared Key (PSK), the server sends the client a session id or session credentials for subsequent resumption of the connection, and then uses the parameters of the previous communication to continue the communication.

While 0-RTT is great in terms of performance, it comes at the cost of forward security, and there is also the problem of replay attacks. Because neither side communicates before sending, the data is not interactive, so an attacker can capture the packet and resend it, and the server is likely to consider it valid and accept it, which can be risky if the operation is one that has side effects, such as modifying the server state.

Therefore, for clients, only secure data should be placed in 0-RTT data, such as HTTP GET requests.

Summary

In short, TLS 1.3 is another human struggle against security and RTT. Forward security is implemented, leaving only the currently secure algorithms, and the time required to connect is further reduced to 1-RTT, with 0-RTT possible in special cases.