When you open a website with a padlock, your browser and the server do not just greet each other: they run a three-message cryptographic choreography that decides, in milliseconds, which algorithm will encrypt everything that follows. That is the TLS 1.3 handshake, and understanding it is understanding why your connection is secure without you having to do anything.
The problem the handshake solves
Before exchanging a single byte of useful data, both parties must agree on three things: who the other is (authentication), which key they will use (encryption) and how to prove nothing has been tampered with (integrity). Doing this over a network where anyone can listen or impersonate the parties is the central challenge of applied cryptography.
TLS 1.3, standardized in RFC 8446 (August 2018), drastically simplified that process. Where TLS 1.2 needed two full round trips between client and server, TLS 1.3 reduces it to a single one. That shows: an HTTPS connection takes less time to establish, and on high-latency networks the difference is noticeable.
The three messages of the handshake
The sequence is elegant in its economy. The client opens with a ClientHello that already includes its key proposal; the server replies with a ServerHello that closes the agreement; and a third client message confirms and activates the encryption. From then on, everything travels protected.
The key to this efficiency is the ephemeral key exchange. Instead of negotiating first and deriving keys later, the client sends in the first message its part of an ECDHE (Elliptic Curve Diffie-Hellman Ephemeral): a public value computed from a private key that is generated on the fly and discarded when the session ends. The server does the same in its reply. By combining both public parts with their respective private ones, each side obtains the same shared secret without that secret ever traveling over the network.
That the keys are ephemeral is not a detail: it guarantees forward secrecy. Even if an attacker recorded all the encrypted traffic and years later stole the server’s private key, they could not decrypt past sessions, because the session key no longer exists anywhere.
From the shared secret to the working keys
The ECDHE shared secret is not used directly to encrypt. It goes through a key derivation based on HKDF (HMAC-based Key Derivation Function), a mechanism that “stretches” and splits that secret into several independent keys: one to encrypt data from client to server, another for the opposite direction, and separate keys for the integrity of each direction. Separating keys by direction and by function is a defense: if one leaks, the damage is contained.
The encryption itself uses an authenticated encryption with associated data (AEAD) cipher, usually AES-256-GCM or ChaCha20-Poly1305. The G in GCM stands for Galois: the mode combines encryption and authentication in a single operation, so each message carries a tag that allows any alteration to be detected. ChaCha20-Poly1305 is the preferred alternative on devices without hardware AES acceleration, such as many phones.
What was removed from TLS 1.2
The simplification of TLS 1.3 was not cosmetic: it removed mechanisms that were a source of vulnerabilities. Gone are the RSA key exchanges (which offered no forward secrecy), the CBC modes with padding (the origin of attacks such as POODLE and BEAST) and renegotiation, which allowed requests to be injected into an already established session. Weak hash algorithms such as SHA-1 and MD5 were also retired.
The result is a protocol with fewer options but more security: by reducing the configuration surface, the configuration errors that attackers exploited are eliminated. In cryptography, less flexibility usually means more security.
Certificate verification
The key exchange solves the how to encrypt, but not the with whom. To authenticate the server, TLS 1.3 uses an X.509 certificate: a document signed by a certificate authority (CA) that binds a public key to a domain name. The browser checks the chain of signatures up to a trusted root CA, validates the validity dates and verifies that the certificate name matches the visited domain.
That verification is what protects you from a man-in-the-middle attack: if someone intercepted the connection and impersonated the server, they could not present a valid certificate for that domain, and the browser would show the dreaded warning.
Resumption and 0-RTT: the speed of the already known
Doing the full handshake on every visit would be expensive. That is why TLS 1.3 allows session resumption: the server issues an encrypted ticket that the client stores, and on the next connection it can resume the session with a single message. For idempotent requests (such as a GET), there is also the 0-RTT mode, which allows data to be sent already in the first message, without waiting for a reply. It is the basis of HTTP/3’s low latency over QUIC.
0-RTT has a downside: those first bytes can be replayed by an attacker (a replay attack), so it should only be used with requests that have no side effects. It is a good example of how the protocol balances speed and security depending on context.
Why it matters today
TLS 1.3 is not an academic curiosity: it is the standard protecting virtually all web, email and messaging traffic. Its design —ephemeral keys, robust derivation, authenticated encryption and fewer options— is today the reference model for any protocol that wants to be secure by default. The next time you see the padlock in the address bar, you will know that behind it there are three messages, an elliptic curve and a secret that never traveled over the network.
