Every HTTPS connection starts with a handshake, the quick back-and-forth where your browser and the website agree on how to talk securely before any real data moves. The little lock icon only shows up once it's done. TLS 1.3 made that handshake much faster than the version before it, and the difference is real on slow connections. Here is what happens in those few hundred milliseconds.
TLS stands for Transport Layer Security. It is the protocol that turns the "HTTP" in your address bar into "HTTPS". TLS 1.3 is the current version, finalized in 2018 and now the dominant one on the public internet.
What the handshake is doing
When your browser connects over HTTPS, three things happen before any useful data flows. First, the server proves it is who it claims to be using a certificate, a digital ID card signed by a Certificate Authority your browser already trusts, like a passport stamped by a government. Second, the two sides agree on which encryption methods to use. That agreed set of locks and codes is the "cipher suite". Third, they settle on a shared secret key without anyone watching the network being able to figure it out. That step is the "key exchange": agreeing on a shared password even though every message is sent in the open.
That is the handshake. Part identity check, part negotiation, part shared-secret derivation.
Two flavors of encryption are in play. Asymmetric encryption uses a public lock anyone can snap shut and a private key only the owner can open. Great for proving identity, but slow. Symmetric encryption uses one shared key both sides hold. Fast. The handshake uses the slow kind just long enough to agree on a key, then switches everything to the fast kind.
The TLS 1.3 handshake step by step
TLS 1.3 finishes the handshake in a single round trip, which is a big deal. A round trip (RTT for short) is one full there-and-back message: client to server, then server back to client. One round trip means one message each way.
The client sends a ClientHello, the opening message your browser fires off. It lists the cipher suites the client supports, a random number, and a "key share". The key share is one half of a Diffie-Hellman exchange, the classic math trick that lets two strangers agree on a shared secret out in the open, where nobody listening in can grab it. The client is saying "here is my public half, if you want to do this".
The server replies with a ServerHello, its own opening message, plus its certificate, its own key share, and a Finished message. Now both sides have everything they need to compute the shared secret, and the server's response is already partly encrypted using keys derived from the exchange.
The client validates the certificate, finishes computing the shared secret, and sends its own Finished message, also encrypted. From here every byte in either direction is encrypted under the freshly derived keys. By the time the second packet from the server arrives, encryption is already running, and your actual HTTP request rides along inside that same flight.
Why TLS 1.2 was slower
The version before this needed two full round trips, mostly for historical reasons. TLS 1.2 separated cipher negotiation from key exchange, so the client had to wait for the server to pick a cipher suite before it knew what kind of key exchange to do. Another round of back-and-forth.
The difference is noticeable on high-latency connections, ones with a lot of lag. 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. With 0-RTT (covered below) it can drop to zero on a resumed connection.
What got cut from the standard
TLS 1.3 is much smaller in scope than its predecessor. The committee threw out a lot of cryptographic baggage that had accumulated over 15 years.
- RSA key exchange. Gone. TLS 1.3 only uses ephemeral Diffie-Hellman. Ephemeral means fresh throwaway keys, made for one session and tossed after. That gives you forward secrecy: if a server's private key is stolen later, past sessions stay safe, because the actual session keys were never transmitted and were destroyed when the session ended.
- Static Diffie-Hellman. Gone for the same reason. Reused keys mean one theft unlocks everything.
- Block ciphers in CBC mode. Gone. Only AEAD ciphers like AES-GCM and ChaCha20-Poly1305 are allowed. AEAD bundles encryption and a tamper check into one step, avoiding an entire class of padding-oracle attacks (tricks that decode data by watching how a server reacts to junk it is fed).
- SHA-1, MD5, RC4. All gone. These older scrambling methods had been weakening for years. TLS 1.3 finally pulled the plug.
- Compression. Gone. TLS-level compression turned out to be exploitable (the CRIME and BREACH attacks), so the committee removed it entirely.
The result is a smaller attack surface and fewer ways to misconfigure. TLS 1.2 ended its life with around 37 valid cipher suites. TLS 1.3 has five.
0-RTT, fast with one caveat
If your client has talked to a server before and remembers the session, TLS 1.3 lets you send real data on the very first message, with no waiting. That is 0-RTT, zero round trips. The catch is that 0-RTT data is replayable. An attacker who captures the encrypted bytes of a 0-RTT request can resend them later, and the server will process them again.
That is fine for safe, repeatable requests like fetching a page. It is not fine for "transfer money" requests. Most servers configure 0-RTT carefully, allowing it for safe operations and blocking anything that changes state. Chrome and Firefox use it for HTTP GETs and not for anything that mutates server data. RFC 8446 has the full rules on what 0-RTT is and is not safe for.
How to check what version you are using
In Chrome, click the lock icon, then "Connection is secure", then "Certificate is valid". The 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 tells 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 shows exactly which protocols are supported and whether the config is sane.
Where this leaves us
Cloudflare Radar shows the vast majority of TLS traffic to its network is now 1.3. The rest is mostly older devices, embedded systems, and a long tail of servers whose admins have not updated their TLS configurations.
If you run a server, enable TLS 1.3 if you have not already, and disable TLS 1.0 and 1.1 if your platform still allows them. The per-request speedup is small. Over a billion page loads it adds up. The security improvements are not subtle.
