Every time you open a padlocked website, your browser and the server run a handshake protocol: an exchange of messages that agrees how to encrypt data before a single useful byte travels. For two decades that cost two network round trips. With TLS 1.3 it is settled in a single one, and in the process the cryptographies that made it fragile were removed for good. This is what happens inside that single round trip.
From two round trips to one
In TLS 1.2, the classic handshake needed two round trips between client and server before sending the first HTTP request. On high-latency networks, especially mobile ones, that meant hundreds of milliseconds of pure waiting. TLS 1.3 (RFC 8446, finalized in 2018) squeezed the protocol down to a single round trip, and to zero on resumed connections. The trick: the client sends its key proposal guessing which algorithm the server will use, instead of waiting for the server to say so.
A key that dies with the session
The biggest design decision was to make forward secrecy mandatory. In TLS 1.2, the server could pick cipher suites that used its fixed private key to derive the session; if that key leaked years later, all recorded traffic could be decrypted. TLS 1.3 forbids this: the key exchange is now always ephemeral Diffie-Hellman (ECDHE), where each session generates temporary keys that are destroyed when it ends. Stealing the server’s private key today no longer lets you read conversations recorded yesterday. This is the end of “store now, decrypt later”.
Fewer options, smaller attack surface
The protocol dragged decades of insecure modes for compatibility: RC4, 3DES, SHA-1, stateful hash functions, RSA key transport or static Diffie-Hellman. Each was a door an attacker could open. TLS 1.3 removed almost that whole menu and left a minimal set: key exchange always with ECDHE, and session encryption always with an AEAD authenticated cipher (AES-GCM, AES-CCM or ChaCha20-Poly1305). AEAD encrypts and authenticates in a single operation, so any tampering with the traffic is detected instantly.
Encryption defined before the greeting
In the single-round-trip handshake, the client sends in its first message (ClientHello) a list of algorithms and a provisional key proposal computed with ECDHE. The server replies in kind and that is it: both sides derive the final session key and can encrypt. The derivation uses the HKDF standard (a key-derivation function built on HMAC), fed with the ephemeral shared secret. The intermediate protocol messages, the ones that settle who is who, are also encrypted from the very start, preventing a snooper from seeing certificates in the clear: this is the seed of what later became ECH (Encrypted Client Hello), which hides even the domain name.
Resuming without breaking a sweat
To avoid repeating the handshake on every request, the server hands out a session ticket: a key the client stores and reuses. With it, a later connection resumes in 0-RTT mode: the client sends encrypted data on the very first packet. The price is replay attacks: an attacker can rebroadcast that first packet. The protocol mitigates them by tracking used tickets and demanding application-level idempotency tolerance, a deliberate trade-off between speed and security.
Why this matters today
Almost all of the world’s HTTPS traffic already runs on TLS 1.3: it cuts perceived latency, protects archived conversations, and leaves such a small cipher menu that it is hard to misconfigure. The next step on the road, post-quantum cryptography so current keys survive future quantum computers, does not break the protocol: it just replaces the key exchange with new algorithms inside the same single-round-trip scheme. Understanding what happens in that network trip is understanding why the web stopped waiting.
