Why TLS Exists

TCP: A Reliable Ordered Byte Stream over an Unreliable Network gives you a byte stream that arrives complete and in order — and that is the entire contract. The bytes are plaintext on every link. The peer is whoever answered the SYN at that IP and port, and ARP and Neighbor Discovery: From an IP to a Local MAC, DNS: Why Names Need a Distributed Database and Internet Routing: Autonomous Systems and BGP each offer a way to make the wrong machine answer. Nothing in the segment lets the receiver tell "the server sent this" from "someone on the path sent this".

The threat model TLS was designed for has two attackers. The passive eavesdropper copies traffic and reads it: a rogue access point, a tap at an ISP, a compromised router. The active man-in-the-middle sits on the path and rewrites: it can inject a script into an HTML page, change an account number in a form post, or terminate the TCP connection itself and open its own to the real server, relaying both directions while reading everything.

The coffee-shop Wi-Fi is the canonical example because every attack is cheap there: the attacker shares your broadcast domain, can win the ARP race for the gateway’s IP, can hand out its own DNS server via DHCP, and sees every frame you send. The same attacks exist at ISP and nation-state scale; the café just makes them a laptop’s work.

Start from the attacks and each property falls out. Against reading: confidentiality — encrypt the application bytes with a symmetric cipher such as AES-GCM or ChaCha20-Poly1305, which run at gigabytes per second with hardware support. Against rewriting: integrity — every record carries an authentication tag computed with the session key; a modified record fails to verify and the connection is torn down. Modern suites combine both in one AEAD construction (authenticated encryption with associated data), so there is no separate MAC step.

Encryption is useless if the key was agreed with the attacker, which forces authentication: the server proves it holds the private key matching a public key that a trusted third party has bound to its hostname — that binding is a Certificates and the Chain of Trust. And symmetric ciphers need both ends to hold the same secret while never sending it in the clear, which forces key agreement: an asymmetric exchange (ephemeral elliptic-curve Diffie-Hellman in every modern configuration) that lets two parties derive the same secret over a public channel.

The split between asymmetric and symmetric is a performance decision, not an aesthetic one. An X25519 key agreement costs on the order of 50–100 µs of CPU; an RSA-2048 signature verification tens of microseconds; encrypting a 16 kB record with AES-GCM under AES-NI costs a few microseconds. You do the expensive asymmetric work once per connection in the The TLS Handshake and the cheap symmetric work on every byte.

TLS is a layer between transport and application. It takes a reliable byte stream from TCP, splits application data into records of at most 16 kB plaintext, encrypts and tags each one, and hands the peer the same byte stream it was given. The application protocol above does not change: HTTPS is ordinary HTTP written into a TLS session on port 443. The same is true of SMTP submission on 465, IMAP on 993, the PostgreSQL wire protocol with sslmode=require, gRPC (which mandates h2 over TLS in most deployments), and MQTT on 8883.

Because TLS needs an ordered stream it cannot run directly over UDP: Datagrams and the Contract You Choose; the datagram variant is DTLS, and QUIC instead embeds the TLS 1.3 handshake inside its own transport — see HTTP/3 and QUIC. Some protocols start plaintext and upgrade in-band (STARTTLS for SMTP on 587, PostgreSQL’s SSLRequest message), which is where downgrade attacks live: an active attacker strips the offer to upgrade and the client, unless configured to require TLS, continues in the clear.

TLS protects the content of the connection, not its existence. The path still sees both IP addresses, the port, packet sizes and timing — enough to fingerprint which site or even which page is being visited. The SNI field in the Client Hello carries the hostname in plaintext so a shared server can pick a certificate; Encrypted Client Hello (ECH) is the fix and is deployed by some large CDNs and browsers but is far from universal. DNS lookups are separate and plaintext unless the resolver speaks DNS-over-HTTPS or DNS-over-TLS.

It also does not protect against a compromised endpoint (malware on the client reads the page after decryption), a misissued certificate (a CA that signs a certificate for a hostname it should not — Certificate Transparency exists to make that detectable), or a client that has been told to trust an extra root, which is exactly how corporate inspection proxies decrypt traffic legitimately and how malware does so illegitimately.

Versions matter. SSL 2/3, TLS 1.0 and 1.1 are deprecated and disabled in current browsers; TLS 1.2 is the floor and TLS 1.3 (RFC 8446, 2018) is the default. Statements about "what TLS does" in the rest of this module are made for 1.3 unless marked, with 1.2 differences called out, because the handshake shape, the set of cipher suites and the resumption mechanism all changed between them.