What is TLS?

TCP gives you a reliable byte stream that every 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.

Why it exists

TCP gives you a reliable, ordered byte stream between two computers. What it does not give you is any privacy. Every router, ISP, and coffee-shop access point along the path sees those bytes in the clear and could modify them mid-flight. The protocol was designed in a more trusting era.

TLS 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 in 2026 is TLS, with TLS 1.3 (RFC 8446, 2018) the current target and TLS 1.2 (RFC 5246, 2008) still common for older clients.

Why it matters now

You almost can’t make a network call in modern infrastructure without TLS underneath:

• Every HTTPS request your browser makes.
• Every modern email transport (SMTP with STARTTLS).
• Every database driver in production (Postgres, MySQL, Redis — all over TLS).
• Every gRPC call between services.
• 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 for basically the whole working internet.

The short answer

TLS = handshake (key agreement + server cert verification) + encrypted record stream using symmetric AEAD

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

Roughly, in TLS 1.3:

1. ClientHello. The client offers supported TLS versions, cipher suites, and a key share — its half of an ECDHE key agreement.
2. ServerHello + Certificate + key share. The server picks a cipher suite, sends its certificate chain and its half of the key share, and signs the handshake transcript with the certificate’s private key — that signature is what proves it actually owns the cert, not just a copy of the public part.
3. Shared secret derivation. Both sides combine their own private key share with the other side’s public share. The math (Diffie–Hellman) means they end up with the same secret, while a passive eavesdropper who saw both public shares cannot compute it. This is key agreement, the heart of the handshake.
4. Key derivation. The shared secret is run through HKDF to produce the symmetric keys used for the record layer.
5. Cert verification. The client walks the certificate chain up to a trusted CA in its root store, checking signatures, dates, and hostname. The chain-of-trust details get their own deep dive in HTTPS certificates.

Because the key share is fresh per connection (the E in ECDHE — ephemeral), each session has its own secret. Compromise the server’s long-term private key tomorrow and you still can’t decrypt traffic captured today — the ephemeral keys were thrown away. That property is forward secrecy, and it’s why TLS 1.3 mandates ECDHE instead of the older “encrypt the symmetric key with the server’s RSA key” approach.

In TLS 1.3 this whole handshake is 1-RTT for a fresh connection, and 0-RTT for a resumed one — the client can send the first application bytes alongside its ClientHello. TLS 1.2 was 2-RTT. That round-trip win is the headline reason TLS 1.3 (and QUIC, which folds it in) feel snappier on high-latency links.

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 HTTP requests, SQL queries, and gRPC messages once the connection is up.

Show the seams

• TLS authenticates server names, not humans. A valid cert for example.com proves you’re talking to whoever currently controls that DNS name and convinced a CA to issue them a cert. It does not prove you’re talking to a specific company or 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. It’s only safe for idempotent operations, and applications have to opt in deliberately.
• 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.
• Honest gap: the relative deployment share of TLS 1.3 vs 1.2 in production today varies by ecosystem, and I don’t have a current confident number to pin.

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. Surprisingly readable for an RFC; the handshake diagrams in particular are worth sitting with.
• Bulletproof TLS and PKI by Ivan Ristić — the practitioner reference for configuring, debugging, and reasoning about TLS deployments.
• Cloudflare’s TLS 1.3 explainer posts — good visual walkthroughs of the 1-RTT and 0-RTT flows if the RFC’s notation is rough going.