TLS 1.3 Features. What Changed From TLS 1.2. And Why It Matters

TLS 1.3 shipped in 2018 as RFC 8446. It is the biggest overhaul of the TLS protocol since SSL 3.0 in 1996. Five years after release, TLS 1.3 now protects over 70 percent of HTTPS connections. The upgrade is not incremental. It changes how the handshake works. It removes broken cipher suites. It mandates forward secrecy. And it makes the protocol faster.

This post covers what TLS 1.3 adds. What it removes. And why the changes matter for anyone running a server or building a client.

The Handshake Problem

TLS 1.2 requires two round trips before any application data flows. The client sends ClientHello. The server responds with ServerHello, certificate, and ServerKeyExchange. The client sends ClientKeyExchange and ChangeCipherSpec. The server sends Finished. Only then can encrypted data pass.

That is 2-RTT (two round trips). On a high-latency connection, each round trip adds 50-100 milliseconds. Mobile networks add more. The handshake becomes a noticeable delay.

TLS 1.3 cuts this to 1-RTT. The client guesses which key exchange parameters the server will accept. It sends its key share in the first ClientHello. The server responds with its key share and Finished message. The client can send encrypted data immediately.

The math: 2-RTT becomes 1-RTT. A connection that took 150 milliseconds to establish now takes 75 milliseconds. For a page with 100 resources, that is 7.5 seconds saved on cold connections.

0-RTT Early Data

TLS 1.3 adds an optional 0-RTT mode for resumed connections. If the client has connected to the server before, it can send application data in the very first flight. No handshake wait. No key exchange delay.

The mechanism uses PSK (Pre-Shared Key). The server issues a session ticket after the first connection. The client stores this ticket. On the next connection, the client sends the ticket along with early data. The server validates the ticket and decrypts the data immediately.

There is a trade-off. 0-RTT data is not protected against replay attacks. An attacker can capture the 0-RTT packet and replay it. The server will process it twice. This is acceptable for idempotent operations (GET requests, read-only queries). It is dangerous for state-changing operations (POST, PUT, DELETE).

The spec requires servers to enforce replay limits. Common strategies: accept 0-RTT only once per ticket, or only for specific safe endpoints.

Cipher Suite Cleanup

TLS 1.2 supports dozens of cipher suites. Many are broken. RC4 has known biases. 3DES is vulnerable to Sweet32. CBC mode ciphers suffer from padding oracle attacks. SHA-1 is deprecated for signatures.

TLS 1.3 removes all of these. Only five cipher suites remain:

Cipher Suite	Key Exchange	Bulk Encryption	Hash
TLS_AES_128_GCM_SHA256	(EC)DHE	AES-128-GCM	SHA-256
TLS_AES_256_GCM_SHA384	(EC)DHE	AES-256-GCM	SHA-384
TLS_CHACHA20_POLY1305_SHA256	(EC)DHE	ChaCha20-Poly1305	SHA-256
TLS_AES_128_CCM_SHA256	(EC)DHE	AES-128-CCM	SHA-256
TLS_AES_128_CCM_8_SHA256	(EC)DHE	AES-128-CCM (8-byte tag)	SHA-256

All use AEAD (Authenticated Encryption with Associated Data). This combines encryption and authentication in one operation. No more encrypt-then-MAC debates. No more padding oracle vulnerabilities.

ChaCha20-Poly1305 is the software-friendly option. It runs faster than AES on devices without hardware AES acceleration (phones, IoT devices). AES-GCM is faster on servers with AES-NI instructions.

Forward Secrecy Is Mandatory

TLS 1.2 allows static RSA key exchange. The client encrypts the premaster secret with the server’s RSA public key. If an attacker records the traffic and later steals the server’s private key, they can decrypt everything.

TLS 1.3 requires (EC)DHE (Elliptic Curve Diffie-Hellman Ephemeral) for every connection. The server generates a new key pair for each handshake. The shared secret is never transmitted. Even if the server’s long-term private key is compromised, past sessions remain secure.

This is forward secrecy. It limits the blast radius of a key compromise. The cost is computational: DHE requires more CPU than static RSA. Modern hardware handles this easily. The security benefit is worth it.

Key Schedule Redesign

TLS 1.2 derives keys in an ad-hoc manner. The premaster secret becomes the master secret. The master secret generates key blocks. Different keys are used for encryption, MAC, and IVs. The logic is complex and has led to implementation bugs.

TLS 1.3 uses HKDF (HMAC-based Key Derivation Function) throughout. The key schedule is a clean chain of derivations:

Early Secret → Handshake Secret → Master Secret
     ↓                ↓                ↓
Early Traffic   Handshake Traffic   Application Traffic

Each stage uses HKDF-Extract and HKDF-Expand. The inputs are well-defined. The outputs are cryptographically separated. This reduces implementation errors and makes formal verification easier.

Encrypted Extensions

TLS 1.2 sends some handshake messages in plaintext. The ServerHello includes extensions that reveal server capabilities. A passive observer can fingerprint the server based on these extensions.

TLS 1.3 encrypts everything after the ServerHello. The EncryptedExtensions message carries server parameters that were previously visible. This reduces metadata leakage and makes traffic analysis harder.

Post-Handshake Authentication

TLS 1.2 authenticates the server once, during the handshake. Client authentication (mutual TLS) also happens during the handshake. If the server wants to request a client certificate later, it must renegotiate. Renegotiation is complex and has caused vulnerabilities (CVE-2009-3555).

TLS 1.3 supports post-handshake authentication. The server can request a client certificate at any time using a KeyUpdate message. No renegotiation needed. This enables use cases like on-demand client authentication or certificate rotation without reconnecting.

What TLS 1.3 Removes

The cleanup is as important as the new features. TLS 1.3 explicitly removes:

• SSL 2.0 and 3.0 compatibility (already deprecated, now impossible)
• TLS 1.0 and 1.1 features (separate RFCs, but 1.3 does not interoperate)
• Static RSA key exchange (no forward secrecy)
• Static DH key exchange (no forward secrecy)
• CBC mode ciphers (padding oracle attacks)
• RC4 (broken stream cipher)
• 3DES (Sweet32 birthday attack)
• SHA-1 for signatures (collision attacks)
• MD5 (completely broken)
• Export-grade ciphers (deliberately weakened, 1990s export restrictions)
• Compression (CRIME attack)
• Renegotiation (CVE-2009-3555)
• ChangeCipherSpec protocol (folded into handshake)
• Custom DHE groups (only standardized groups allowed)

The result is a smaller, cleaner protocol. Implementations have less code to audit. Attackers have fewer options to exploit.

Deployment Status

As of 2026, TLS 1.3 adoption is widespread but not universal:

• Cloudflare: 100% of edge servers support TLS 1.3
• Google: 78% of Chrome connections use TLS 1.3
• Firefox: 82% of connections use TLS 1.3
• AWS ALB/CloudFront: TLS 1.3 enabled by default since 2021
• nginx: TLS 1.3 support since version 1.13.0 (2017)
• OpenSSL: TLS 1.3 since version 1.1.1 (2018)

The bottleneck is legacy clients. Windows Server 2016 does not support TLS 1.3 by default. Java 8 requires updates. Some embedded systems ship with OpenSSL 1.0.2 and cannot be upgraded.

The recommendation: enable TLS 1.3 everywhere possible. Keep TLS 1.2 as a fallback for legacy clients. Disable TLS 1.0 and 1.1 entirely.

How To Enable TLS 1.3

nginx:

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256;
ssl_prefer_server_ciphers off;

Apache:

SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite TLSv1.3:+TLS_AES_128_GCM_SHA256:+TLS_AES_256_GCM_SHA384:+TLS_CHACHA20_POLY1305_SHA256

OpenSSL command line:

openssl s_client -connect example.com:443 -tls1_3

Test with curl:

curl -vI https://example.com 2>&1 | grep "TLSv1.3"

The Takeaway

TLS 1.3 is faster, simpler, and more secure than TLS 1.2. The 1-RTT handshake reduces latency. 0-RTT enables instant resumption for repeat visitors. The cipher suite cleanup removes broken algorithms. Mandatory forward secrecy limits the impact of key compromises.

Enable TLS 1.3 on every server you control. The protocol has been stable since 2018. The security benefits are proven. The performance gains are measurable. There is no reason to wait.

For more context, check out SSL Is Dead. TLS Runs The Web Zero-Downtime Nginx to Caddy Migration.

For background on why SSL is deprecated and how TLS became the standard, read SSL Is Dead. TLS Runs The Web. Here Is What Actually Encrypts Your Traffic.