How TLS encryption actually works, one handshake at a time
The two problems TLS has to solve at once
Every time a browser connects to https:// anything, it needs to solve two separate problems before a single byte of the actual page can travel safely. First: encryption — making sure that anyone intercepting the traffic between you and the server sees meaningless noise instead of your password or your bank balance. Second, and just as important: authentication — making sure the server on the other end is actually who it claims to be, because encrypting a conversation with an impostor perfectly is worthless. TLS (Transport Layer Security — the modern name for what most people still call SSL) solves both at once, and the mechanism it uses to do it is one of the more elegant pieces of everyday cryptography.
Why you can't just encrypt with a shared secret from the start
The obvious approach — "both sides agree on a secret password and encrypt everything with it" — has a fatal flaw: how do the two sides agree on that secret in the first place, over a connection that isn't secure yet? Anyone watching the connection would see the secret being exchanged and could read everything afterward just as easily as the intended recipient. This is exactly the problem asymmetric cryptography was invented to solve, and it's the first piece of the TLS handshake.
Asymmetric cryptography, in one paragraph
In asymmetric (public-key) cryptography, every party has two mathematically linked keys: a public key, which can be shared with literally anyone, and a private key, which never leaves the owner's machine. Anything encrypted with the public key can only be decrypted with the matching private key — so a server can publish its public key openly, and anyone can use it to send that server a message that only the server itself can read. This solves the "agreeing on a secret over an insecure channel" problem directly: your browser can encrypt something using the server's public key, send it across the open internet in full view of anyone watching, and only the real server — the one holding the matching private key — can actually decrypt it.
Why TLS doesn't just use asymmetric encryption for everything
If asymmetric cryptography solves the problem, why doesn't TLS just encrypt the entire page load with it? Because asymmetric encryption is computationally expensive — meaningfully slower than the alternative — while the rest of the browsing session might involve thousands of packets. So TLS uses asymmetric cryptography for exactly one job: securely agreeing on a session key, a much simpler shared secret, at the very start of the connection. Once both sides have that session key, they switch to symmetric encryption — the same key locking and unlocking data on both sides — which is dramatically faster and handles the actual bulk of the page, images, and API calls for the rest of the session. This handoff, expensive-but-secure key exchange followed by cheap-and-fast bulk encryption, is the core trick behind almost every practical encryption system, not just TLS.
The part that proves who you're actually talking to
Solving encryption alone still leaves the authentication problem: anyone can generate their own public/private key pair and claim to be your bank. This is where certificates and certificate authorities (CAs) come in. A certificate is a file that bundles a server's public key together with its domain name, digitally signed by a certificate authority — an organization your browser and operating system already trust, with that trust baked in ahead of time as a list of known CA public keys shipped with every browser and OS. When your browser connects to a server, the server presents its certificate, and your browser checks that certificate's signature against the CA's known public key. If the signature checks out, your browser can trust that a CA verified, at some point, that this specific public key really does belong to this specific domain — which is what actually stops an attacker from simply generating their own keys and pretending to be your bank, since they'd also need a CA to sign a certificate claiming their key belongs to your bank's domain, and CAs won't do that without verifying domain ownership first.
Putting the whole handshake together
When you connect to an HTTPS site, roughly this sequence happens before any page content moves: your browser says hello and lists which encryption methods it supports; the server replies with its certificate and picks an agreed-upon method; your browser verifies that certificate against its trusted CA list; browser and server then use asymmetric cryptography to securely agree on a session key, each contributing randomness so that key is unique to this one connection; and from that point forward, everything — the actual HTML, images, form submissions — travels encrypted with that fast symmetric session key. This entire sequence typically completes in well under a second, which is part of why it's easy to forget it's happening at all.
Why "the padlock" is a lower bar than people think
The padlock icon in a browser's address bar means the connection is encrypted and the certificate is valid for that domain — genuinely useful guarantees. It does not mean the site itself is trustworthy, safe, or legitimate; certificate authorities verify that you control a domain, not that the content you're serving from it is honest. A phishing site with a name like paypa1-security.com can have a perfectly valid certificate and a perfectly legitimate padlock, because nothing in the TLS handshake checks whether a domain name is trying to impersonate a different, real company. Understanding what TLS actually verifies — this specific key belongs to this specific domain, and traffic to it is encrypted — versus what it doesn't — whether that domain is the one you actually meant to visit — is the difference between the padlock being a mildly useful signal and it being something you trust more than it deserves.