How HTTPS and TLS 1.3 Actually Work Under the Hood
1. Why Plain HTTP Was Never Actually Private
I used to think of the padlock icon in the address bar the way most people probably do — as a binary "safe or not safe" signal and nothing more. It wasn't until I actually sat down with openssl s_client and watched a real handshake happen packet by packet that I understood how much is actually going on in the roughly fifty milliseconds between typing an address and a page starting to load. It's a genuinely elegant piece of applied cryptography, and once you've seen it broken down, you can't really unsee it every time you load a webpage again.
Before HTTPS was the default, HTTP sent everything — passwords, session cookies, form data, all of it — as plain, readable text across the network. It's worth being blunt about what that actually meant in practice: anyone with access to the path your packets traveled could read them. Your coffee shop's Wi-Fi router, your ISP, anyone running a packet sniffer on the same network, any hop along the backbone in between. There was no lock on any of it. HTTPS solves this by wrapping ordinary HTTP inside TLS (Transport Layer Security, the modern successor to SSL), which gives you three specific guarantees: encryption so the contents can't be read in transit, authentication so you know you're actually talking to who you think you're talking to, and integrity so nobody can quietly tamper with the data along the way.
"HTTPS wraps ordinary HTTP inside TLS, giving three non-negotiable guarantees: encryption in transit, identity authentication, and data integrity."
2. The Key-Exchange Problem, and How It Gets Solved Without Ever Sending a Key
Encrypting a full HTTP stream in real time needs to be fast, and symmetric ciphers like AES-256-GCM or ChaCha20 are fast precisely because both sides use the identical secret key to encrypt and decrypt. That speed comes with an obvious problem, though: your browser in one part of the world and a server somewhere else have never met, and they need to agree on a shared secret key over a network that anyone could be listening to. Just sending the key over would defeat the entire point.
This is what Elliptic-Curve Diffie-Hellman (ECDHE) actually solves, and it's one of those pieces of math that still feels slightly like a magic trick even once you understand it. Both sides generate their own key pair, exchange only the public half of it, and then each independently computes the exact same shared secret using their own private key combined with the other side's public value. The secret itself never crosses the network at any point — an eavesdropper watching the entire exchange sees both public keys and still can't reconstruct the shared secret without solving a computationally infeasible math problem.
3. Knowing Who You're Actually Talking To
Solving the key-exchange problem gets you a private channel, but it doesn't answer a separate question: how do you know the server on the other end of that private channel is actually your bank, and not someone sitting in the middle of the connection pretending to be it? That's what X.509 certificates and Certificate Authorities exist to answer.
The mechanism is a chain of trust. A web server obtains a certificate — cryptographically signed by a CA like Let's Encrypt, DigiCert, or Cloudflare — that ties its public key to its domain name. Your browser and operating system ship with a pre-installed trust store of root CA certificates that they've decided to trust in advance. When a connection is made, the server presents its certificate chain, and your browser walks that chain back to a root it already trusts, verifying the signatures mathematically at each step. If any link in that chain is broken, forged, or expired, you get the warning page instead of a silent failure — which is exactly the behavior you want from something protecting a banking session.
4. Getting the Handshake Down to One Round Trip
Older TLS versions, particularly 1.2, needed two full round trips between client and server before a single byte of actual encrypted application data could move — negotiate the cipher and protocol version in one round trip, then complete the key exchange in a second. On a slow connection, that's real, noticeable latency stacked on top of everything else the page still has to load.
TLS 1.3, finalized as RFC 8446 in 2018, collapses that down to a single round trip by folding key exchange and cipher negotiation into the very first exchange instead of treating them as sequential steps. In practice it looks like this:
• Client Hello — the browser sends its supported TLS version, its supported cipher suites, and its Diffie-Hellman public key share, all in the first packet.
• Server Hello, encrypted extensions, and certificate — the server picks a cipher suite, computes the shared symmetric key on its end, sends back its own public key share, and presents its certificate to complete authentication.
• Encrypted application data — the symmetric channel is already live at this point, so the client can send its actual HTTP request immediately, without waiting for a separate confirmation round trip.
That single round trip you're saving might sound small, but multiplied across every new connection a page makes — fonts, scripts, images, API calls — it adds up to a real, felt difference in how fast a site feels to load, especially on higher-latency mobile connections.
5. Watching the Handshake in Real Time
You can watch this handshake happen in real time instead of just taking it on faith:
# Inspecting a live TLS 1.3 handshake with OpenSSL
openssl s_client -connect example.com:443 -tls1_3 -brief
# Output will show something like:
# CONNECTION ESTABLISHED
# Protocol version: TLSv1.3
# Ciphersuite: TLS_AES_256_GCM_SHA384
# Peer certificate: CN = example.com
# Verification: OK6. Beyond the Summary
The first time I ran that against a server I controlled and actually saw the negotiated cipher suite print out in plain terminal output, the whole handshake stopped being an abstraction and started being something I could point at. If you want to go further than the summary version, RFC 8446 is the actual protocol specification and is more readable than you'd expect for an IETF document, and Let's Encrypt has a genuinely good explainer on how ACME automates certificate issuance — worth reading if you've ever wondered how a server gets a valid certificate without a human ever manually approving it.