What happens in a TLS 1.3 handshake, step by step?

A TLS handshake is the exchange that lets a client and server agree on encryption keys and lets the client verify the server's identity before any application data moves. In TLS 1.3, defined in RFC 8446, a full handshake takes one round trip and everything after the ServerHello is encrypted.

What is the handshake for?

Three jobs: agree on cryptographic parameters, establish shared secret keys, and authenticate at least the server. Nothing else in the connection can be trusted until these are done.

What are the steps?

Here is the common case, a browser connecting to a web server with no earlier session.

1. ClientHello. The client lists the cipher suites it supports and sends its key share, the public half of a Diffie-Hellman style exchange for one or more groups it guesses the server will accept. Sending the key share in the first message is what saves a round trip.
2. ServerHello. The server picks a cipher suite and a key share group and sends its own key share. At this point both sides can compute the same shared secret and derive keys. Everything the server sends from here on is encrypted.
3. EncryptedExtensions and Certificate. The server sends further parameters, then its certificate chain, protected by the new keys.
4. CertificateVerify. The server signs a hash of the handshake so far with the private key matching its certificate. This proves it owns the key, and ties the identity to this specific exchange.
5. Finished. The server sends a message authenticating the whole handshake. The client checks the certificate chain against its trusted authorities, checks the name matches, verifies the signature, and sends its own Finished.
6. Application data. Both sides now send encrypted data.

If the client guessed wrong about the key share group, the server answers with a HelloRetryRequest and the client tries again, which adds a round trip.

What changed from older TLS versions?

RFC 8446 lists the differences. Static RSA and static Diffie-Hellman cipher suites were removed, so all public key exchange now provides forward secrecy: a stolen server key cannot decrypt recorded past sessions. All handshake messages after the ServerHello are now encrypted, which hides the certificate from passive observers. The key derivation was redesigned.

What about 0-RTT?

When a client and server have a pre shared key from a previous session, TLS 1.3 lets the client send early data in its first flight. The RFC covers its trade-off: it comes at the cost of certain security properties, and it has an anti replay section. Use it only for requests that are safe to replay, such as reading public pages.

A constructed debugging example

A mobile app fails to connect to an API only on one carrier. A packet capture shows the ClientHello leaves, and the server replies with an alert. The cause turns out to be a middlebox that cannot handle the newer protocol version. Knowing the handshake order lets the engineer see where the conversation stops, which narrows the search from "the network" to "something modifying the first message".

How to check or apply this

1. Test your server with a command line client and note the negotiated protocol version and cipher suite.
2. Disable TLS versions older than 1.2, and prefer 1.3.
3. Make sure certificates cover the exact names clients use, and watch expiry dates.
4. Use an automated issuance and renewal process.
5. Decide whether to enable 0-RTT, and limit it to idempotent requests.
6. If you inspect TLS in the middle, document the trust decision and the data it exposes.
7. Log handshake failures by alert type, since patterns point to causes.

Quick check

Sources

• RFC 8446, The Transport Layer Security Protocol Version 1.3

Last reviewed: 18 October 2026.