Every HTTPS connection you make starts with a handshake. The little lock icon in your browser only shows up once it is done. Most people never think about what is happening in those few hundred milliseconds, which is fine. But it is actually pretty interesting, and TLS 1.3 made it dramatically faster than the version before it.
If you have ever wondered what the lock icon actually means, or why some sites feel snappier than others, the answer is mostly in the handshake.
What the handshake is actually doing
When your browser connects to a website over HTTPS, three things have to happen before anything useful can flow:
- The server has to prove it is who it claims to be (using a certificate signed by a Certificate Authority your browser trusts).
- Your browser and the server have to agree on a set of cipher suites, which are the specific algorithms they will use for encryption and integrity checking.
- They have to derive a shared secret key, without anyone watching the network being able to figure out what the key is.
That is the handshake. It is part identity check, part negotiation, part cryptographic magic.
The TLS 1.3 handshake, step by step
TLS 1.3 finished the handshake in a single round trip, which is a big deal. Here is what happens, drawn out:
The client sends a ClientHello. This message contains a list of cipher suites the client supports, a random number, and (this is the new part) a key share. The key share is one half of a Diffie-Hellman key exchange. The client is essentially saying: "Here is my public key, if you want to do this, here is what I am bringing."
The server replies with ServerHello plus its certificate, plus its own key share, plus a Finished message. At this point, both sides have everything they need to derive the shared secret. The server's response is already partially encrypted using the keys derived from the exchange.
The client validates the certificate, finishes deriving the shared secret, and sends its own Finished message, encrypted this time. From here on, every byte exchanged in either direction is encrypted under the freshly derived keys.
That is one full round trip. By the time the second packet from the server arrives, the encryption is already up and running. Application data, your actual HTTP request, can ride along inside that same flight.
Why TLS 1.2 was slower
The version before this needed two full round trips to finish the handshake. The reason is mostly historical: TLS 1.2 separated the cipher negotiation from the key exchange. The client had to wait for the server to pick a cipher suite before it knew what kind of key exchange to do, which meant another round of messages.
The difference is real and noticeable, especially on high-latency connections. If you are on a phone with a 100ms ping to a server, TLS 1.2 added 200ms of pure handshake before any data flowed. TLS 1.3 cuts that to 100ms. Add in 0-RTT (more on that in a second) and you can sometimes get to zero round trips on resumed connections.
What got cut
TLS 1.3 is also dramatically smaller in scope than its predecessor. The committee threw out a lot of cryptographic baggage that had accumulated over fifteen years:
- RSA key exchange. Gone. TLS 1.3 only uses ephemeral Diffie-Hellman, which gives you forward secrecy by default. If a server's private key is stolen later, past sessions are still safe, because the actual session keys were never transmitted and were thrown away when the session ended.
- Static DH. Gone for the same reason.
- Block ciphers in CBC mode. Gone. Only AEAD ciphers (AES-GCM, ChaCha20-Poly1305) are allowed. These bundle encryption and integrity into a single primitive and avoid an entire class of padding-oracle attacks.
- SHA-1, MD5, RC4. All gone. These had been weakening for years. TLS 1.3 finally pulled the plug.
- Compression. Gone. TLS-level compression turned out to be exploitable (CRIME, BREACH), so they just removed it.
The result is a protocol with a much smaller attack surface and far fewer ways to misconfigure. TLS 1.2 had something like 37 valid cipher suites by the end of its life. TLS 1.3 has five.
0-RTT, fast with caveats
If your client has talked to a server before and remembers the session, TLS 1.3 lets you send application data on the very first message. Zero round trips. Great for performance, not great for security in one specific way: 0-RTT data is replayable. An attacker who captures the encrypted bytes of a 0-RTT request can re-send them later, and the server will process them again.
This is fine for idempotent requests like fetching a page. It is less fine for "transfer money" requests. Most servers configure 0-RTT carefully, allowing it for safe operations and not for anything that mutates state. Browsers like Chrome and Firefox use it for HTTP GETs but not for anything that changes data on the server side. RFC 8446 has the full details on what 0-RTT is and is not safe for.
How to tell what version you are using
If you are curious whether a site is using TLS 1.3, the easiest check is in your browser. In Chrome, click the lock icon, then "Connection is secure", then "Certificate is valid", and the connection details usually show the protocol version. Firefox shows it under the security panel of the page info dialog.
From the command line, openssl s_client -connect example.com:443 -tls1_3 will tell you in the first few lines whether the negotiation succeeded. SSL Labs' Server Test is the gold standard for grading a server's TLS configuration, and it will explicitly tell you which protocols are supported and whether the configuration is sane.
Where this leaves us
TLS 1.3 was finalized in 2018 and is now the dominant version of HTTPS on the public internet. Cloudflare Radar shows that the vast majority of TLS connections to their network are now 1.3. The remaining 1.2 traffic is mostly older devices, embedded systems, and a long tail of servers whose admins have not yet updated their TLS configurations.
If you run a server, the right move is to enable TLS 1.3 if you have not already, and disable TLS 1.0 and 1.1 if your platform still allows them. The user-visible difference is small per request, just tens of milliseconds, but those add up over a billion page loads. And the security improvements are not subtle. The handshake your visitors are doing every time they land on your site is genuinely better than it used to be. They will not see it, but they will feel it in the speed.
