TLS 1.3: What Changed and Why It Matters

TLS 1.3 is the latest version of the Transport Layer Security protocol, finalized in RFC 8446 in August 2018. It represents the most significant upgrade to the TLS protocol since TLS 1.0, removing legacy cryptographic algorithms, simplifying the handshake, and dramatically improving both security and performance. For anyone running web services, understanding TLS 1.3 is essential for maintaining a secure and fast infrastructure.

The TLS Handshake: 1.2 vs 1.3

The most immediately noticeable improvement in TLS 1.3 is the reduced handshake latency. TLS 1.2 requires two round trips (2-RTT) to establish a secure connection. TLS 1.3 reduces this to a single round trip (1-RTT), and supports zero round trips (0-RTT) for repeat connections.

TLS 1.2 Handshake (2-RTT)

Client → Server: ClientHello (supported ciphers, random)
Server → Client: ServerHello, Certificate, ServerKeyExchange, ServerHelloDone
Client → Server: ClientKeyExchange, ChangeCipherSpec, Finished
Server → Client: ChangeCipherSpec, Finished
[Application data begins]

TLS 1.3 Handshake (1-RTT)

Client → Server: ClientHello + KeyShare (guessed key exchange params)
Server → Client: ServerHello + KeyShare, EncryptedExtensions, Certificate, CertificateVerify, Finished
Client → Server: Finished
[Application data begins — one round trip saved]

The key difference: in TLS 1.3, the client sends its key share parameters in the very first message, guessing which key exchange the server will choose. If the guess is correct (which it usually is), the entire handshake completes in one round trip.

0-RTT Resumption

When a client reconnects to a server it has previously communicated with, TLS 1.3 supports 0-RTT (early data). The client can send encrypted application data in its very first message, before the handshake completes:

Client → Server: ClientHello + KeyShare + EarlyData (encrypted with PSK)
Server → Client: ServerHello + KeyShare + Finished
[Server processes early data immediately]

This eliminates handshake latency entirely for repeat visitors. However, 0-RTT data is vulnerable to replay attacks, so it should only be used for idempotent requests (like GET) and never for state-changing operations.

Removed Algorithms and Features

TLS 1.3 aggressively removes cryptographic primitives that were considered weak or unnecessary:

Supported Cipher Suites

TLS 1.3 supports only five cipher suites, all providing authenticated encryption with associated data (AEAD):

TLS_AES_128_GCM_SHA256        (mandatory)
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_CCM_SHA256
TLS_AES_128_CCM_8_SHA256

All TLS 1.3 cipher suites provide forward secrecy by design. The key exchange algorithm (ECDHE or DHE) is negotiated separately from the cipher suite, simplifying the configuration.

Forward Secrecy by Default

In TLS 1.2, forward secrecy was optional — it depended on choosing ECDHE or DHE key exchange. Many servers were configured with RSA key exchange, meaning a future compromise of the server's private key would allow decryption of all previously recorded traffic.

TLS 1.3 mandates forward secrecy. Every connection uses ephemeral key exchange (ECDHE or DHE), so each session has a unique key. Compromising the server's long-term key does not expose past sessions.

Encrypted Handshake

In TLS 1.2, the server certificate is sent in plaintext during the handshake. This allows passive observers to identify which website a client is connecting to by examining the certificate.

TLS 1.3 encrypts the server certificate and most handshake messages after the ServerHello. Combined with Encrypted Client Hello (ECH, formerly ESNI), this significantly improves privacy by preventing passive observers from determining which specific service a client is accessing.

Performance Impact

On a connection with 50ms RTT, TLS 1.3 saves 50ms on every new connection and 100ms on every resumption compared to TLS 1.2.

Server Configuration

Enabling TLS 1.3 on modern web servers is straightforward:

# Nginx
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256;
ssl_prefer_server_ciphers off;  # Let client choose in TLS 1.3

# Apache
SSLProtocol -all +TLSv1.2 +TLSv1.3
SSLCipherSuite TLSv1.3 TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256

Checking TLS 1.3 Support

You can verify TLS 1.3 support with command-line tools:

# Test with OpenSSL
openssl s_client -connect example.com:443 -tls1_3

# Test with curl
curl -v --tlsv1.3 https://example.com 2>&1 | grep "SSL connection"

# Check supported protocols
nmap --script ssl-enum-ciphers -p 443 example.com

Browser and Server Support

As of 2025, TLS 1.3 is supported by all modern browsers and most server software. Chrome, Firefox, Safari, and Edge have supported it since 2018-2019. On the server side, OpenSSL 1.1.1+, Nginx 1.13+, and Apache 2.4.37+ all support TLS 1.3.

Summary

TLS 1.3 is a major improvement over TLS 1.2 in every dimension: it is faster (1-RTT handshake, 0-RTT resumption), more secure (mandatory forward secrecy, removed legacy algorithms), and simpler (fewer cipher suites, encrypted handshake). If your servers still only support TLS 1.2, upgrading to TLS 1.3 is one of the most impactful performance and security improvements you can make with minimal configuration effort.