Chalk sketch of two figures shaking hands across a wire beneath a padlock and a sealed certificate scroll

What TLS Actually Does — The Handshake Behind the Padlock

July 13, 2026 · 6 min read · Feynmanpedia Editorial

Article summary

TLS (Transport Layer Security) is the protocol that turns plain connections into the encrypted ones behind HTTPS. At the start of a connection, client and server run a handshake: they perform an ephemeral Diffie-Hellman key exchange to agree on a fresh shared secret in public view, the server presents a certificate, which is a signed voucher from a Certificate Authority binding its domain name to its public key, and the server proves it holds the matching private key. Then both sides switch to fast symmetric encryption for all actual traffic. TLS 1.3, standardized as RFC 8446 in 2018, cut the handshake to one round trip and removed obsolete options. The padlock therefore means two distinct things: the connection is encrypted, and the server's identity was checked against the domain. It says nothing about whether the site itself is honest. Because the key exchange uses throwaway values, TLS 1.3 also provides forward secrecy: recorded traffic stays unreadable even if the server's long-term key later leaks.

Before this page reached your screen, your device and a server it had never met performed a small ceremony lasting a few dozen milliseconds. They agreed on a secret key while shouting everything across the open internet, the server proved it was really the machine your address bar names, and both sides switched into an encrypted channel no eavesdropper on the path can read. That ceremony is TLS, Transport Layer Security, and it is arguably the most-run cryptographic protocol in the world.

TLS is also the payoff of this whole cluster: it is the place where every tool from how encryption actually works gets used in the same breath. Asymmetric cryptography for introductions and identity, symmetric encryption for the traffic, hashes for integrity. If those pieces are new to you, the pillar article frames them; here we watch them run.

What problem TLS is solving

The internet delivers your data by handing it from router to router, across networks owned by strangers: your coffee shop, your ISP, backbone carriers, foreign exchanges. Anyone operating one of those hops can read plain traffic, and, worse, can modify it or answer in someone else's name.

So TLS has to deliver three distinct guarantees at once. Confidentiality: nobody on the path can read the traffic. Integrity: nobody can silently alter it. Authentication: you are talking to the actual owner of the domain, not an impostor sitting in the middle. Miss any one of these and the other two lose their meaning; an encrypted connection to an impostor is worthless.

The protocol began life at Netscape in the 1990s under the name SSL, was renamed TLS when standardization moved to the IETF, and has been repeatedly hardened as attacks with memorable names (BEAST, POODLE, FREAK) exposed weaknesses in old versions. The current version, TLS 1.3, standardized as RFC 8446 in 2018, is a major cleanup: faster and stripped of the legacy options that caused most of the trouble.

The handshake, in plain steps

Here is what happens when your browser opens a TLS 1.3 connection, compressed to its essentials.

Step 1: the client speaks first. Your browser sends a hello: the TLS versions and cipher suites (combinations of algorithms) it supports, plus its half of a key exchange — what the protocol calls a key share. It generates a fresh random value for this connection, computes a public counterpart, and sends that counterpart along. This is the ephemeral Diffie-Hellman opening move, almost always on elliptic curves today.

Step 2: the server answers with its half. The server picks the cipher suite, generates its own fresh random value, and returns its public counterpart. Now the beautiful trick fires: each side combines its own private value with the other's public value, and the mathematics guarantees both arrive at the same number. An eavesdropper who saw both public halves cannot reconstruct it, because deriving the secret from the public pieces is exactly the kind of one-way problem discussed in symmetric vs asymmetric encryption. Both sides now share a secret that was never transmitted. Once each side has derived keys from it, the remainder of the handshake — and everything that follows — travels encrypted; only the two opening hello messages ever crossed the wire in the clear.

Step 3: the server shows papers. A shared secret with a total stranger is only half the job; you need to know which stranger. So the server sends its certificate and then signs a hash of the entire handshake so far with its long-term private key. The signature proves two things at once: the server holds the private key matching the certificate, and nobody tampered with the negotiation messages in flight.

Step 4: verify and go. Your browser checks the certificate's signature chain, checks that the domain matches and the dates are valid, and verifies the handshake signature. Then both sides derive symmetric session keys from the shared secret (using hash-based machinery of the kind covered in hash functions explained) and switch to bulk encryption, typically AES-GCM or ChaCha20-Poly1305, modes that encrypt and integrity-protect every record simultaneously. The application data flows.

TLS 1.3 packs all of this into a single round trip before data can flow, down from two in TLS 1.2, which is a noticeable chunk of the speed difference you feel on connection-heavy pages. Older versions also let attackers negotiate connections down to weak, obsolete ciphers; 1.3 deleted those ciphers outright.

Certificates: who vouches for whom

The certificate deserves a closer look, because it is where cryptography meets bureaucracy. A certificate is a small signed document that says, in essence: "This public key belongs to example.com. Signed, someone you trust."

The someone is a Certificate Authority (CA), an organization whose core business is verifying control of domains and signing certificates, for web certificates today usually via automated challenges: prove you control example.com by publishing this specific token where I can see it. Your operating system and browser ship with a trust store, a curated list of CA verification keys, and any certificate chaining up to one of them is accepted.

This design concentrates trust, and the ecosystem has evolved defenses accordingly: CAs are audited against industry baseline rules, every issued certificate is recorded in public, append-only Certificate Transparency logs (Merkle trees again) so misissuance is detectable, and browsers have ejected CAs that failed badly, a corporate death sentence. Since the mid-2010s, certificates have also become free and automated through services like Let's Encrypt, which is a large part of why the encrypted share of web traffic went from a minority to the overwhelming norm within a decade.

Now the padlock can be read precisely. It asserts: this connection is encrypted, and the server at the other end demonstrably controls the domain in the address bar. It does not assert the domain is honest. A scam site at a lookalike domain gets a valid certificate as easily as anyone. The padlock authenticates the spelling, not the character.

Forward secrecy in one paragraph

Notice something subtle in the handshake: the server's long-term private key was used only to sign, never to encrypt. The session secret came from throwaway values both sides invented for this one connection and deleted afterward. Consequence: an adversary who records your encrypted traffic for years and then steals the server's private key still gets nothing, because the recorded transcripts were keyed by secrets that no longer exist anywhere. This property is forward secrecy, and TLS 1.3 made it mandatory by removing the old alternative, RSA key transport, where the client encrypted the session key directly to the server's long-term key and a single key theft retroactively unlocked every recorded conversation.

The takeaway

TLS is three promises welded together: nobody can read the traffic, nobody can alter it, and the far end really is the domain you named. It keeps those promises by running this cluster's entire toolkit in sequence, an ephemeral key exchange, a certificate signed through a chain of vouching (with RSA or elliptic-curve signatures doing the vouching), and fast symmetric encryption with hashes guarding integrity, all in about one round trip. The next time the padlock appears, you can name every gear that just turned. If you'd like a five-minute primer on the neighboring machinery, from DNS to hashing, before you dig into building or debugging any of it, that daily-explainer habit is exactly what NerdSip was built around.

Frequently asked questions

Does the padlock mean a website is safe and trustworthy?

No, and this is the most common misreading of it. The padlock certifies two things: your traffic to the site is encrypted against eavesdroppers, and the server you reached actually controls the domain name in the address bar. It says nothing about the intentions of whoever runs that domain. A phishing site at a lookalike domain can obtain a perfectly valid certificate in minutes, often free, and display the same padlock. Encryption to a criminal is still encryption. The padlock answers 'is this conversation private and am I talking to this domain,' never 'is this domain run by honest people.' Checking the actual domain name spelling remains your job.

What exactly is a Certificate Authority?

A Certificate Authority (CA) is an organization whose job is to verify that whoever requests a certificate for a domain actually controls that domain, typically by an automated challenge such as placing a specific file on the site or a specific DNS record. Once verified, the CA signs a certificate binding the domain name to a public key. Operating systems and browsers ship with a curated list of trusted CA verification keys, so any certificate carrying a valid signature from a trusted CA is accepted automatically. CAs are audited, and public Certificate Transparency logs record every certificate they issue, so misissuance can be detected. CAs that fail badly have been removed from browser trust lists, which effectively ends their business.

What is forward secrecy?

Forward secrecy means that stealing a server's long-term private key tomorrow does not decrypt traffic recorded yesterday. TLS 1.3 achieves it by never using the server's long-term key to encrypt anything. That key only signs the handshake to prove identity. The actual session key comes from an ephemeral Diffie-Hellman exchange using random values both sides generate for that one connection and delete afterward. Since the session secret was never transmitted and its ingredients no longer exist, a recorded transcript is permanently undecryptable by classical means. Earlier TLS versions allowed a mode where the client encrypted the session secret directly to the server's long-term key, which made recorded traffic retroactively readable if that key ever leaked; TLS 1.3 removed that option entirely.

Where to go next

A short editorial reading list. Pick whichever fits how you like to learn.

RFC 8446: TLS 1.3: the actual 2018 standard, with a surprisingly readable introduction
Wikipedia: Transport Layer Security: history of the protocol from SSL to TLS 1.3, including the attacks that shaped it
NerdSip — how everyday things actually work: daily five-minute explainers of the systems you use without seeing