What is TLS?

TCP gives you a reliable byte stream that any router along the path can read and modify. TLS is the layer that wraps that stream so you get confidentiality, integrity, and proof of who's on the other end.

The picture version

Five pictures for a reader who has never wondered what the padlock means, following one action: logging into your email over carriage Wi-Fi.

Why it exists

You’re on the train, logging into your email over the carriage Wi-Fi. The bytes of your password leave your laptop, pass through an access point bolted to the ceiling, through the train operator’s uplink, through whichever ISP carries it, and through a handful of routers you’ll never see. Nothing about TCP stops any intermediary on that path from reading those bytes, or changing them. That login on the train is the example this post follows.

TCP gives you a reliable, ordered byte stream between two computers. What it does not give you is any privacy. Any router, ISP, or coffee-shop access point along the path can read those bytes in the clear, and could modify them mid-flight. TCP’s design predates the assumption that the network is hostile, and nothing was retrofitted into it.

TLS — Transport Layer Security — wraps that stream and gives it three properties TCP doesn’t:

1. Confidentiality — only the two endpoints can read the bytes.
2. Integrity — a tampered byte is detected, not silently delivered.
3. Authentication — the client gets cryptographic evidence that the server is the one it intended to reach.

The SSL name you still hear (“SSL certificates”) is a vestige of the Netscape-era predecessor; every version of SSL is formally deprecated. What ships today is TLS, with TLS 1.3 (RFC 8446, 2018) the current version and TLS 1.2 (RFC 5246, 2008) still present for compatibility with older clients.

Why it matters now

A large share of the network calls modern infrastructure makes have TLS underneath:

• Every HTTPS request your browser makes.
• Mail between servers, where SMTP usually upgrades to TLS via STARTTLS — though opportunistically, so it’s not a guarantee the way HTTPS is.
• Database and cache drivers (Postgres, MySQL, Redis) reached across a network; plaintext survives on trusted links and Unix sockets.
• gRPC between services, unless a service mesh is terminating it for them.
• Every QUIC session — TLS 1.3 isn’t bolted onto QUIC, it’s built into it.

The browser padlock is just the visible tip. TLS is the load-bearing encryption layer under most of the working internet.

The short answer

TLS = handshake (key agreement + server cert verification) + encrypted record stream with tamper detection

Picture to keep: two strangers in a crowded carriage building a shared combination out loud — everyone hears both halves and still can’t work out the combination — then locking every later message in a box only that combination opens. Where the picture breaks: nothing in it stops one of the “strangers” from being an impostor, which is precisely the job the certificate does and the key agreement doesn’t.

Two phases, two jobs. The handshake is expensive public-key crypto, run once per connection: both sides agree on a fresh shared secret, and the client checks the server’s certificate. The record layer is cheap symmetric encryption that runs for every byte after that. The split exists because public-key math is too slow for bulk data — so it’s used briefly, just to bootstrap a symmetric key that does the real work.

How it works

Phase 1: the handshake

Each step below is forced by the failure of the step before it.

Naive attempt: encrypt with a shared password. Fine for two people who met beforehand. Useless for your laptop and a mail server that have never exchanged anything, over a carriage access point that reads everything. The two ends have to invent a shared secret in full view of the train.

Fix: agree on a secret in public. The client opens with a ClientHello — supported TLS versions, cipher suites, and a key share, its half of an ECDHE exchange. The server answers with ServerHello and its own half. Each side then combines its private share with the other’s public share; the Diffie–Hellman math means both land on the same secret, while an eavesdropper who saw both public halves still cannot compute it. That’s key agreement, and the secret is then run through HKDF to produce the actual record-layer keys.

But key agreement authenticates nobody. The access point on the ceiling can run that same exchange with you, and a second one with the real mail server, and sit in the middle reading plaintext. Fix: in the same flight the server sends its certificate chain and signs the handshake transcript with the certificate’s private key. The client walks the chain up to a trusted CA in its root store — signatures, dates, hostname — and checks that transcript signature, which is the part a copied certificate can’t produce. The chain-of-trust details get their own deep dive in HTTPS certificates.

sequenceDiagram
    participant C as Client
    participant S as Server
    C->>S: ClientHello — versions, ciphers, my key share
    S->>C: ServerHello — my key share
    S->>C: Certificate + signature over the transcript
    Note over C,S: both derive the same secret; client verifies chain
    C->>S: application data (1 RTT after the first packet)

But one long-term key is a single point of retroactive failure. If the symmetric key were simply encrypted to the server’s long-term key — the old static-RSA approach — anyone who recorded today’s traffic and stole that key in 2030 could decrypt all of it. Fix: make the key share fresh per connection (the E in ECDHE, ephemeral) and throw it away afterwards. That property is forward secrecy, and it’s why TLS 1.3 dropped static RSA key transport entirely.

And even with secrecy and authentication solved, setup still costs round trips before your password moves. TLS 1.2 needed two. TLS 1.3 gets a fresh connection down to 1-RTT by having the client guess a key share in its very first message, and a resumed connection to 0-RTT, where application bytes ride along with the ClientHello. That round-trip win is a large part of why TLS 1.3 — and QUIC, which folds the handshake into the transport — feel snappier on a high-latency link like a train.

Phase 2: the record layer

After the handshake, the rest is simpler. Application bytes get chopped into records, each encrypted with an AEAD construction (AES-GCM and ChaCha20-Poly1305 are the two you’ll see) and shipped over the underlying TCP connection. AEAD gives you confidentiality and integrity in one primitive: flip any bit in transit and the receiver’s tag check fails, and the record is rejected. The record layer is what’s actually moving your login — and every mail your client fetches afterwards — once the connection is up.

Show the seams

• TLS authenticates server names, not humans. A valid cert for example.com proves the peer holds the private key for a certificate a CA issued for that name — normally after checking that the requester controlled the domain. It does not prove you’re talking to a specific company or an honest operator, a much narrower claim than “the padlock means it’s safe.”
• CA trust is messy by construction. Your browser ships with a root store of many CAs, and any of them can technically issue a cert for any domain. Certificate Transparency logs (append-only public records of issued certs) are the partial fix — they make misissuance noisy after the fact, not preventable up front.
• 0-RTT trades safety for speed. Data sent in the zero-round-trip early flight can be replayed by an attacker who captured it. RFC 8446 spells out anti-replay measures and warns that idempotence is the starting point, not a sufficient condition — applications have to opt in deliberately and think about what a replay would actually do.
• TLS only protects between TLS endpoints. A reverse proxy that terminates TLS sees plaintext. “End-to-end encrypted” and “served over HTTPS” are not the same claim.
• “We use TLS 1.3” describes a capability, not a guarantee. The version is negotiated per connection, so a server that supports 1.3 will still complete a 1.2 handshake with a client that can’t do better. Which version your traffic actually got is a property of that connection, not of the server’s configuration page.

You started with TLS = handshake + encrypted record stream. What did the train ride add? — + the handshake does two separate jobs, and only one of them is encryption. Key agreement gives you a secret with somebody; the certificate and the transcript signature are what make that somebody your mail server. Drop the second job and the access point on the ceiling gets a perfectly encrypted copy of your password.

Famous related terms

• TCP — TCP = reliable + ordered + single byte stream — the layer underneath that TLS wraps.
• HTTPS certificate / cert chain — cert ≈ public key + domain name + CA's signature — the chain-of-trust deep dive covers what TLS leans on for server authentication.
• Public-key crypto — public-key crypto = key pair + math where one half can't be derived from the other — the primitive the handshake is built on.
• Forward secrecy — forward secrecy = key compromise tomorrow doesn't decrypt today's traffic — the property ECDHE buys you, and the reason TLS 1.3 dropped static-RSA key transport.
• AEAD — AEAD = symmetric encryption + built-in tamper detection — the primitive that does the actual byte-by-byte work in the record layer.
• QUIC — QUIC = UDP + TLS 1.3 + per-stream reliability + connection IDs — QUIC folds the TLS 1.3 handshake into the transport, no separate negotiation step.
• mTLS — mTLS = TLS + the client also presents a cert — both sides authenticate. Common in service-to-service traffic inside a cluster.

Going deeper

• RFC 8446 (TLS 1.3) — the primary source for “what is actually in each handshake message, and in what order”; the message-flow diagrams answer that better than any paraphrase.
• Bulletproof TLS and PKI by Ivan Ristić — read this for the practitioner’s question: given all these knobs, what should a real deployment be configured to do, and how do you debug it when it isn’t?
• Cloudflare’s TLS 1.3 write-ups — for “why did 1.3 drop so much of 1.2,” which is the fastest way to see which older options turned out to be mistakes.