What The Handshake Accomplishes
By the time the TLS handshake completes, both sides have done four things at once: agreed on a TLS version and a cipher suite, authenticated the server (and optionally the client), established fresh symmetric session keys, and gotten forward secrecy as a free bonus.
| Goal | How TLS 1.3 achieves it |
|---|---|
| Negotiate version and cipher | Client lists supported options in ClientHello. Server picks one in ServerHello. Downgrade attempts trigger a downgrade-sentinel check. |
| Authenticate the server | Server sends its certificate chain plus a signature over the handshake transcript using the certificate's private key. |
| Establish session keys | Ephemeral (EC)DH exchange in the first round trip. Both sides derive identical traffic keys via HKDF. |
| Forward secrecy | The (EC)DH private exponents are ephemeral. After the handshake, they are discarded. Past sessions stay safe even if long-term keys leak. |
TLS 1.3 does all of this in one round trip. Earlier versions needed two. The savings come from sending the key share in the very first message instead of negotiating ciphers first.
TLS 1.3 Walkthrough
The handshake involves six logical messages, packed into two flights:
- ClientHello: random nonce, supported cipher suites, supported groups (curves), key_share (a fresh ephemeral DH public key for each group the client supports).
- ServerHello: random nonce, chosen cipher suite, chosen group, server's key_share. After this message, both sides can derive the handshake traffic keys.
- EncryptedExtensions: protocol parameters that did not fit in ServerHello, now encrypted.
- Certificate: the server's X.509 leaf cert plus its intermediate chain.
- CertificateVerify: the server signs a hash of the entire transcript so far, proving possession of the private key that matches its certificate.
- Finished: an HMAC over the transcript, confirming the handshake was not tampered with.
The client then sends its own Finished message, and from that point on, both sides use the derived application traffic keys for the rest of the connection. The walkthrough below shows each message in order, what each side computes upon receipt, and what an eavesdropper sees.
Step Through The Handshake
Click Next to advance one message at a time. Each step shows the message on the wire, what each side knows at that moment, and what Eve (the network eavesdropper) can read.
Trace every message in a real TLS 1.3 handshake
The simulated session is a browser connecting to zzz-consulting.com using the cipher suite TLS_AES_256_GCM_SHA384 with X25519 key exchange. Notice how quickly the conversation becomes encrypted: by step 4, everything on the wire is opaque to Eve.
Forward Secrecy In The Handshake
The (EC)DH key exchange in step 1 and 2 uses ephemeral keys. Both sides generate fresh DH private values for every handshake and throw them away when the connection closes. The server's long-term certificate key is only used to sign the transcript, never to derive the session key.
This separation is the entire point of forward secrecy. Even if an attacker records every byte of every TLS session and later steals the server's private key, the recorded traffic stays encrypted. The ephemeral DH private values no longer exist anywhere. There is no key to compromise that would unlock the past.
Old TLS 1.2 supported a mode where the client encrypted the pre-master secret with the server's RSA certificate key. That mode had no forward secrecy: stealing the server's key meant retroactively decrypting every recorded session. TLS 1.3 dropped this mode completely. Every TLS 1.3 connection uses ephemeral (EC)DH. There is no opt-out, no compatibility setting, no legacy mode. This is one of the most important security wins of the TLS 1.3 design.
0-RTT And Its Tradeoffs
TLS 1.3 includes an optional mode called 0-RTT (Early Data) that lets a returning client send application data in the very first packet, before the handshake completes. The data is encrypted with a key derived from a pre-shared key (PSK) saved from a previous session.
This saves an entire round trip, which is huge on mobile networks. Cloudflare, Google, and major CDNs use it heavily. But it has one critical caveat:
Because the early data is encrypted with a key derived from a stored PSK and has no transcript hash to bind it to a specific handshake, an attacker who captures a 0-RTT packet can replay it. The server cannot tell the difference between the original request and a replay. This is fine for idempotent GETs (fetching a stylesheet) but catastrophic for non-idempotent operations (transferring money, deleting a record). TLS 1.3 explicitly warns implementers that 0-RTT must only carry idempotent requests, and HTTP servers must be configured to reject or anti-replay-protect any non-idempotent endpoint reachable via early data.
What TLS 1.2 Did Wrong
TLS 1.3 was not just an incremental cleanup. It removed entire categories of attack that plagued TLS 1.2 and earlier.
| Attack | Year | What it exploited | TLS 1.3 fix |
|---|---|---|---|
| BEAST | 2011 | CBC mode with predictable IVs in TLS 1.0 | CBC removed. Only AEAD ciphers allowed. |
| CRIME / BREACH | 2012-2013 | Compression-based length leakage | TLS-level compression removed. |
| Lucky Thirteen | 2013 | Timing side channel in MAC-then-encrypt CBC | MAC-then-encrypt removed. AEAD is encrypt-and-authenticate in one operation. |
| POODLE | 2014 | SSL 3.0 padding oracle | SSL 2.0 and 3.0 disallowed. Version downgrade explicitly detected. |
| FREAK | 2015 | Downgrade to 512-bit "export" RSA | All export-grade ciphers removed. |
| Logjam | 2015 | Downgrade to 512-bit DH groups | Weak DH groups removed. Minimum group size enforced. |
| SLOTH | 2016 | RSA-MD5 signatures still accepted | MD5 and SHA-1 signatures removed from handshake. |
| DROWN | 2016 | SSLv2 sharing a key with a modern server | SSLv2 was already dead. TLS 1.3 makes sure it stays dead. |
The pattern is hard to miss: most of those CVEs lived inside features (CBC modes, compression, MAC-then-encrypt, export ciphers, weak DH groups, legacy hashes) that TLS 1.3 simply deleted. The cleanest defense against a class of attacks is to not have the feature.
Reading A Wireshark Capture
If you open a TLS 1.3 handshake in Wireshark, here is what you see and what you do not:
- ClientHello and ServerHello: fully readable. Cipher suites, supported groups, key shares (the raw DH public keys), session tickets, and the Server Name Indication (SNI) hostname are all in plaintext.
- EncryptedExtensions, Certificate, CertificateVerify, Finished: opaque. These are encrypted with the handshake traffic keys derived from the ECDH exchange. Wireshark shows them as a single "Application Data" record unless you supply the session keys.
- Application data (HTTP requests, responses): opaque. Encrypted with the application traffic keys, again derived from the ECDH plus the handshake transcript.
The one thing that has historically leaked is SNI: the hostname the client is connecting to (e.g. chase.com) is sent in plaintext in ClientHello so the server can route to the right virtual host. Encrypted ClientHello (ECH), standardized in 2025, encrypts SNI under a public key advertised by the front-end CDN. Browsers and major CDNs are rolling it out now.
Two options: configure Wireshark with the server's RSA private key (only works for non-PFS suites, which TLS 1.3 does not have) OR set the SSLKEYLOGFILE environment variable in your browser or curl, which writes derived session keys to a file that Wireshark can ingest. The second method is how every modern HTTPS debugging session is done. It is a deliberate disclosure by the client, not an attack on the protocol.