TLS 1.3 handshake explained

Fewer round trips make TLS 1.3 faster

A TLS handshake establishes the encrypted connection before any application data flows. TLS 1.3 reaches a shared key in one network round trip for a new session where TLS 1.2 needed two. Because each round trip is a full client-to-server-and-back exchange, that saved trip is meaningful on high-latency connections, for example a visitor far from the origin or on a mobile network.

In the old model (TLS 1.2) the client sends the supported cipher suites and the server replies with the chosen one plus its certificate, then more messages negotiate keys. TLS 1.3 compresses this: the client sends its key share, a list of cipher suites and a small amount of other data in one message, and the server responds with the selected suite, its certificate and a finished message. Both sides can then start sending encrypted application data immediately.

The practical result is a full TLS handshake plus the TCP handshake resolves in fewer total round trips, which shows up as a faster first byte on real-world links. There is more on the general SSL handshake and the certificate types that the server presents.

The 0-RTT option

TLS 1.3 also adds 0-RTT (zero round trip), where a client that spoke to the server before can resume a session using a pre-shared key and send application data in the very first packet, on the first client message. That removes the handshake entirely for the repeat visitor.

The speed has a cost. A 0-RTT resumption carries the risk of replay: an attacker can capture a legitimate first request and resend it, and the server cannot yet tell the message is a duplicate. Because of that, servers restrict 0-RTT to safe operations such as idempotent GETs and never offer it for purchases through POST or anything with side effects.

Verifying a site uses TLS 1.3

• Browser. Open the lock icon in DevTools, switch to the Security tab and read the TLS version next to the connection details.
• Command line. Ask the server explicitly for each version:

curl -sv --tlsv1.3 https://example.com/  2>&1 | grep version

If the site negotiates only TLS 1.2, the cert issuer or a legacy client may be holding the server back. Modern hosts enable TLS 1.3 by default; the cause is usually a server or edge config set to an old minimum.

When to check the handshake

A TLS handshake failure or an SSL certificate error is a separate diagnosis from TLS 1.3 negotiation. TLS 1.3 being disabled is rarely the cause of a broken connection: it is a performance and latency improvement, and an outdated client falls back to TLS 1.2 automatically. The practical checks are whether the site negotiates the best offered version and whether the 0-RTT setting matches the risk profile of the operations it serves.