What are some of the most recent and innovative TLS features and extensions?

1 TLS 1.3

TLS 1.3 is the latest version of the protocol, published in 2018, that introduces several improvements over the previous versions. One of the main benefits of TLS 1.3 is that it reduces the latency of the handshake process, which is the initial exchange of messages that establishes the connection and the encryption parameters. TLS 1.3 achieves this by eliminating some of the unnecessary steps and messages, and by allowing the client and the server to resume a previous session without repeating the full handshake. Another advantage of TLS 1.3 is that it removes some of the outdated and insecure cryptographic algorithms and ciphersuites that were supported by the older versions, and only allows the ones that are considered strong and modern. This enhances the security and the interoperability of the protocol, and prevents some of the known attacks and vulnerabilities.

2 Zero Round Trip Time (0-RTT)

Zero Round Trip Time (0-RTT) is a feature of TLS 1.3 that enables the client and the server to exchange application data in the first message of the handshake, without waiting for the confirmation of the encryption parameters. This can significantly improve the performance and the user experience of some applications, such as web browsing, where the client often sends a request for a resource as soon as it connects to the server. However, 0-RTT also introduces some risks and trade-offs, such as the possibility of replay attacks, where an attacker can capture and resend the same message to the server, or the lack of forward secrecy, where an attacker can decrypt the message if they obtain the encryption key in the future. Therefore, 0-RTT should be used with caution and only for specific scenarios where the benefits outweigh the risks.

3 Certificate Compression

Certificate Compression is an extension of TLS 1.3 that allows the client and the server to compress the certificates that they send to each other during the handshake, using a common algorithm such as zlib or brotli. This can reduce the size of the certificates by up to 80%, which can save bandwidth and improve the speed of the connection, especially for mobile devices and low-latency networks. Certificate Compression can also enhance the privacy of the communication, by preventing passive observers from inspecting the certificates and inferring information about the client or the server.

4 Encrypted Server Name Indication (ESNI)

Encrypted Server Name Indication (ESNI) is an extension of TLS 1.3 that aims to protect the privacy of the client by encrypting the Server Name Indication (SNI) field in the ClientHello message. The SNI is a parameter that indicates to the server which hostname or domain name the client is trying to access, which is useful for servers that host multiple websites or services on the same IP address. However, the SNI is also exposed in plaintext during the handshake, which can allow network intermediaries or attackers to monitor, block, or manipulate the traffic based on the SNI. ESNI prevents this by encrypting the SNI with a public key that is obtained from a trusted source, such as a DNS record or a certificate authority. This way, only the intended server can decrypt and process the SNI, while preserving the functionality and compatibility of the protocol.

5 Delegated Credentials

Delegated Credentials is an extension of TLS 1.3 that enables the server to delegate the authentication of the connection to a third-party entity, such as a content delivery network (CDN) or a load balancer. This can improve the scalability and the performance of the server, by allowing it to distribute the workload and avoid the overhead of managing and renewing certificates for each connection. Delegated Credentials are short-lived cryptographic tokens that are signed by the server's long-term certificate, and that contain a public key and an expiration date. The server can generate and send these tokens to the third-party entity, which can then use them to authenticate itself to the client during the handshake, without revealing the server's private key or certificate.

6 Post-Handshake Authentication

Post-Handshake Authentication is an extension of TLS 1.3 that allows the server to request the client to authenticate itself after the handshake is completed, instead of during the handshake. This can be useful for applications that require dynamic or optional client authentication, such as web applications that allow users to log in with different methods or credentials. Post-Handshake Authentication can also improve the efficiency and the security of the connection, by avoiding unnecessary authentication steps or messages, and by preventing some of the attacks that exploit the renegotiation feature of the older versions of TLS.

7 Here’s what else to consider

This is a space to share examples, stories, or insights that don’t fit into any of the previous sections. What else would you like to add?