TLS 1.3 Handshake
Interactive Step-by-Step Visualization of Secure Connection Establishment
TLS 1.3 (RFC 8446, finalized in 2018) is the latest version of the Transport Layer Security protocol that encrypts virtually all modern internet communication. It represents a major overhaul from TLS 1.2: the handshake is reduced from 2 round trips to just 1, all insecure cipher suites and legacy features have been removed (RSA key transport, CBC mode ciphers, compression, renegotiation), and forward secrecy is mandatory for every connection. The result is a faster, simpler, and more secure protocol. TLS 1.3 also introduces 0-RTT resumption that allows returning clients to send encrypted application data in the very first flight, eliminating handshake latency entirely for resumed sessions. Every software engineer, DevOps practitioner, and security professional should understand the TLS 1.3 handshake because it underpins HTTPS, gRPC, QUIC/HTTP3, and virtually every authenticated encrypted channel on the internet.
Interactive Handshake Visualization
Step through the TLS 1.3 handshake one message at a time. Click "Next Step" to see each message exchanged between the client and server, with detailed data contents for every flight.
Waiting to initiate handshake. The client will generate an ephemeral key pair and prepare supported cipher suites.
Waiting for incoming connections. The server holds its certificate and private key, ready to negotiate.
TLS 1.3 vs TLS 1.2 Round Trips
TLS 1.2 requires 2 full round trips before application data can flow. TLS 1.3 collapses this into a single round trip by sending the client's key share in the very first message. With 0-RTT resumption, returning clients can send encrypted data with zero round trips.
Handshake Latency Calculator
Enter your network round-trip time to see how TLS version choice impacts real-world connection establishment latency.
TLS 1.3 Cipher Suite Explorer
TLS 1.3 dramatically simplified cipher suites. The key exchange is always ECDHE (negotiated separately via supported_groups), and the suite string only specifies the AEAD cipher and hash function. Only 5 cipher suites are defined β all of them secure. Click a cipher suite below to explore its components.
AES-128-GCM is the most widely deployed TLS 1.3 cipher. AES (Advanced Encryption Standard) in GCM (Galois/Counter Mode) provides both confidentiality and authenticity in a single operation (AEAD). The 128-bit key provides approximately 2128 security against brute force, which is considered secure through 2030 and beyond by NIST. GCM mode enables hardware acceleration on CPUs with AES-NI instructions, achieving throughput of several GB/s. SHA-256 is used for the HKDF-based key derivation and transcript hashing. This suite is the default choice for most servers and offers the best balance of security and performance.
0-RTT Resumption Visualization
When a client has previously connected to a server, it caches a Pre-Shared Key (PSK) from that session. On the next connection, the client can send encrypted application data in the very first flight β zero round trips before data. Toggle between the two modes to see the difference.
Certificate Chain Visualization
During the handshake, the server presents its certificate chain. The client verifies each link from the server (leaf) certificate up through intermediate CAs to a trusted root CA in its local trust store. Every signature, validity period, and key usage constraint is checked.
The server sends the leaf certificate and intermediate certificate during the handshake. The root CA is not sent β it must already exist in the client's trust store (browsers and operating systems ship with a curated list of ~150 trusted root CAs). The client verifies the chain bottom-up: (1) check the leaf cert's signature against the intermediate's public key, (2) check the intermediate's signature against the root's public key, (3) confirm the root is in the local trust store. Each certificate's validity period, revocation status (via OCSP or CRL), and key usage constraints are also verified. If any check fails, the connection is rejected with a TLS alert.
Key Exchange: ECDHE (Ephemeral Elliptic Curve Diffie-Hellman)
TLS 1.3 mandates ephemeral key exchange using Elliptic Curve Diffie-Hellman (ECDHE). Both parties generate fresh key pairs for each connection, compute a shared secret, and derive encryption keys. The most common curves are X25519 (Curve25519) and P-256 (secp256r1).
Client
a (32 bytes)A = a * GA in ClientHello key_shareBS = a * BS = a * B = b * AServer
Ab (32 bytes)B = b * GB in ServerHello key_shareS = b * AX25519 (Curve25519)
Designed by Daniel J. Bernstein. 128-bit security level. Fixed-time implementation resists side-channel attacks. Fastest ECDHE curve available β a full key exchange takes ~120 microseconds. Used by ~70% of TLS 1.3 connections. The recommended default for all deployments.
P-256 (secp256r1 / prime256v1)
NIST standard curve. 128-bit security level. Widely supported including in HSMs and older hardware. Slightly slower than X25519 but benefits from hardware acceleration on some platforms. Required for compliance with certain government standards (FIPS, Suite B).
Key Derivation (HKDF)
The shared secret S is not used directly as an encryption key. Instead, TLS 1.3 uses HKDF (HMAC-based Key Derivation Function) to derive multiple keys from S and the handshake transcript hash:
Forward Secrecy
Forward secrecy (also called Perfect Forward Secrecy or PFS) is the property that compromising a server's long-term private key does not compromise the encryption of past sessions. TLS 1.3 mandates forward secrecy by requiring ephemeral key exchange.
Without Forward Secrecy (TLS 1.2 RSA key transport)
With Forward Secrecy (TLS 1.3 ECDHE)
The server's long-term private key is only used for signing (proving identity via CertificateVerify), never for key exchange. Session keys are derived from ephemeral ECDHE key pairs that are generated fresh for every connection and destroyed immediately after the handshake. This means that even a nation-state adversary who records years of encrypted traffic and eventually compromises the server's certificate private key will not be able to decrypt any of the recorded sessions. This is why TLS 1.3 removed RSA key transport β the only key exchange mechanism allowed is ephemeral Diffie-Hellman.
Common TLS Attacks and Mitigations
TLS 1.3 was designed with decades of attack research in mind. Many attacks that affected TLS 1.2 and earlier are structurally impossible in TLS 1.3.
BEAST (Browser Exploit Against SSL/TLS)
Eliminated in TLS 1.3Exploited predictable IVs in CBC mode encryption (TLS 1.0). The attacker could decrypt cookies by observing ciphertext patterns. TLS 1.3 eliminates this entirely by removing CBC mode ciphers β only AEAD ciphers (GCM, ChaCha20-Poly1305) are allowed.
POODLE (Padding Oracle On Downgraded Legacy Encryption)
Eliminated in TLS 1.3Exploited padding validation in SSL 3.0/TLS CBC mode to decrypt data byte-by-byte. TLS 1.3 removes CBC mode and SSL 3.0 compatibility entirely. The padding oracle attack surface no longer exists.
Downgrade Attacks
Mitigated in TLS 1.3An active attacker modifies ClientHello to force a weaker protocol version. TLS 1.3 embeds a special sentinel value in the ServerHello random bytes when downgrading, allowing the client to detect and reject the downgrade. The handshake transcript hash also prevents tampering.
CRIME / BREACH (Compression Side-Channel)
Eliminated in TLS 1.3Exploited TLS-level compression to infer plaintext (e.g., session tokens) by observing compressed ciphertext size. TLS 1.3 removes TLS compression entirely. BREACH (HTTP-level compression) remains a concern at the application layer but is outside TLS scope.
Renegotiation Attack
Eliminated in TLS 1.3In TLS 1.2 and earlier, mid-connection renegotiation could be exploited for prefix injection attacks. TLS 1.3 removes renegotiation entirely. Post-handshake authentication and KeyUpdate messages replace the legitimate use cases for renegotiation.
0-RTT Replay Attack
Risk in TLS 1.3The one known vulnerability class in TLS 1.3: 0-RTT early data can be replayed by an attacker who captures the ClientHello. Unlike the full handshake, 0-RTT data lacks the server's contribution to the key exchange. Mitigation: servers must track client hello timestamps, use single-use session tickets, and never allow non-idempotent operations in 0-RTT data.
Heartbleed (CVE-2014-0160)
Implementation BugA buffer over-read in OpenSSL's heartbeat extension leaked server memory (including private keys). Not a protocol flaw but an implementation bug. TLS 1.3 removed the heartbeat extension entirely. The lesson: protocol security is only as strong as its implementations. Use memory-safe languages and fuzz test TLS libraries.
Man-in-the-Middle (MITM)
Prevented by certificate verificationAn attacker intercepts the connection and presents their own certificate. Prevented by the certificate chain verification β the attacker cannot forge a valid certificate signed by a trusted CA. Certificate Transparency (CT) logs make misissued certificates detectable. HSTS and HSTS preloading prevent the initial HTTP request that could be intercepted before the TLS upgrade.
What TLS 1.3 Removed
TLS 1.3 took the bold step of removing many features from TLS 1.2. Every removal was intentional, motivated by security vulnerabilities or unnecessary complexity.