TLS 1.3 Basics

Learn about TLS 1.3, configure handshake parameters, and explore PQC migration trade-offs.

What is TLS 1.3?

1.3 (RFC 8446) is the latest version of the Transport Layer Security protocol, securing virtually all HTTPS traffic on the internet. It was a major overhaul from TLS 1.2, removing insecure legacy features and introducing mandatory , a faster 1-RTT handshake, and a dramatically simplified cipher suite list.

Removed
  • RSA key exchange (no forward secrecy)
  • CBC cipher modes
  • Renegotiation & compression
Added
  • Mandatory ECDHE forward secrecy
  • 0-RTT early data (optional)
  • Encrypted handshake messages
Simplified
  • 5 cipher suites (vs hundreds in 1.2)
  • 1-RTT handshake (vs 2-RTT)
  • AEAD-only encryption

The TLS 1.3

The handshake establishes a secure connection in a single round trip. The client sends its supported parameters and a key share; the server responds with its choice and key share. After the ServerHello, all remaining handshake messages are encrypted using handshake traffic keys derived via .

💻
Client
🖥️
Server
Encrypted from here
ClientHello
+ key_share, supported_groups
ServerHello
+ key_share
Handshake keys derived
{EncryptedExtensions}
{CertificateRequest}*
mTLS optional
{Certificate}
Server identity
{CertificateVerify}
Signature proof
{Finished}
Server handshake MAC
{Certificate}*
Client identity (mTLS)
{CertificateVerify}*
Client signature (mTLS)
{Finished}
Client handshake MAC
Application Data
Encrypted with traffic keys

Explained

TLS 1.3 cipher suites only specify the symmetric encryption algorithm and hash — key exchange and authentication are negotiated separately. This is why there are only 5 suites compared to hundreds in TLS 1.2.

TLS_AES_256_GCM_SHA384 in GCM mode (AEAD) + SHA-384 for HKDF
TLS_AES_128_GCM_SHA256AES-128 in GCM mode (AEAD) + SHA-256 for HKDF
TLS_CHACHA20_POLY1305_SHA256 (AEAD) + SHA-256 — optimized for mobile/ARM
TLS_AES_128_CCM_SHA256AES-128 in CCM mode + SHA-256 — designed for constrained environments (IoT)
TLS_AES_128_CCM_8_SHA256AES-128 in CCM mode with 8-byte auth tag + SHA-256 — for highly constrained devices

Key Exchange: Classical, PQC, and Hybrid

TLS 1.3 uses ephemeral key exchange for every connection, ensuring forward secrecy. With post-quantum cryptography (PQC), three approaches are available:

Classical ()

, , . Fast and small (~32 byte keys). Vulnerable to quantum computers.

PQC ()

ML-KEM-512/768/1024. Quantum-resistant. Larger keys (~1.2 KB for ML-KEM-768) increase handshake size.

Hybrid

combines both. Already deployed in Chrome and Firefox. Secure even if one algorithm is broken.

Key Schedule (HKDF)

TLS 1.3 derives all session keys through a structured key schedule using HKDF (HMAC-based Key Derivation Function). The shared secret from key exchange feeds into a chain of Extract and Expand operations:

1.Early Secret — derived from PSK (or zero for full handshake)
2.Handshake Secret — derived from ECDHE/KEM shared secret → produces CLIENT_HANDSHAKE_TRAFFIC_SECRET and SERVER_HANDSHAKE_TRAFFIC_SECRET
3.Master Secret — produces CLIENT_TRAFFIC_SECRET_0 and SERVER_TRAFFIC_SECRET_0 for application data

These exact secrets are visible in the Simulate tab after running a handshake.

Post-Quantum Cryptography in TLS

Quantum computers threaten classical key exchange (ECDH) through . The attack means adversaries can record encrypted traffic today and decrypt it once quantum computers are available. PQC integration into TLS addresses this by using KEMs (ML-KEM) and signatures ().

The trade-off: PQC algorithms have larger keys and ciphertexts, increasing handshake overhead. For example, ML-KEM-768 public keys are ~1,184 bytes vs 32 bytes for X25519. The hybrid approach (e.g., X25519MLKEM768) provides quantum resistance while maintaining classical security as a fallback.

Related Resources