TLS

In 1994, Netscape was about to release the world's first commercial web browser and needed a way to make e-commerce safe. Credit card numbers over plain HTTP could be sniffed by anyone on the wire. Netscape's engineers built SSL (Secure Sockets Layer) — a protocol that wrapped any TCP-based application in encryption and authentication. SSL 2.0 (1995) had bugs. SSL 3.0 (1996) fixed them. In 1999, the IETF standardized SSL's successor as TLS 1.0 (Transport Layer Security).

Today, TLS protects the majority of internet traffic. Every HTTPS site, every gRPC call, every email delivery, every SSH session, every payment, every VPN — all rely on TLS or a TLS-adjacent protocol. The current version, TLS 1.3 (RFC 8446, August 2018), reduced the handshake from 2 RTTs to 1 RTT (or 0 RTT for resumed sessions), simplified the cipher negotiation, and removed all the legacy cruft that gave TLS its reputation for security bugs.

TLS is technically a Layer 6 (Presentation) protocol in the OSI model — it presents an encrypted stream to Layer 7 applications. But in practice TLS is usually terminated at the L7 load balancer (Nginx, AWS ALB, Cloudflare edge), so the origin application sees plain HTTP. Understanding what TLS gives you — and where it hands off — is core system-design knowledge.

What TLS gives you — three guarantees

TLS wraps an application protocol (HTTP, SMTP, gRPC) in three cryptographic guarantees:

• Confidentiality — nobody in the middle can read the plaintext. Uses symmetric encryption (AES-256-GCM, ChaCha20-Poly1305).
• Integrity — nobody can modify the ciphertext undetected. AEAD ciphers (Authenticated Encryption with Associated Data) build integrity into the encryption itself.
• Authentication — the client verifies the server is really who it claims to be, via X.509 certificates signed by a trusted Certificate Authority. Optional: mutual TLS (mTLS) verifies the client too.

The TLS 1.3 handshake — 1 RTT to a secure channel

The magic of TLS is negotiating a shared symmetric key over a public network where an eavesdropper sees every byte. In TLS 1.3 this negotiation takes 1 round-trip:

The key exchange uses Elliptic Curve Diffie-Hellman (ECDHE) — an algorithm where two parties can derive the same shared secret by exchanging public values, without anyone in the middle being able to derive it. Every session uses a fresh ephemeral key pair, which gives you forward secrecy: if your server's private key is stolen tomorrow, past traffic remains safe (the session keys were derived from ephemeral values that no longer exist).

Certificates and the chain of trust

The server proves it's really bank.com by presenting an X.509 certificate — a signed statement from a Certificate Authority (CA) that says "the public key attached to this certificate belongs to the operator of bank.com." The client verifies the signature against the CA's public key, which is preinstalled in the OS/browser trust store.

The trust chain typically has 3 levels: Root CA (offline, signs Intermediate CAs) → Intermediate CA (signs leaf certificates) → Leaf certificate (your server's). The browser trusts ~200 Root CAs preinstalled (Let's Encrypt, DigiCert, GlobalSign, Sectigo…). If any CA is compromised, they can issue certificates for any domain — which is why Certificate Transparency logs every issued cert publicly so misuse is detectable.

TLS version comparison — 1.2 vs 1.3

mTLS — mutual authentication for service-to-service

Regular TLS authenticates the server to the client. Nothing forces the client to prove its identity — you rely on application-layer auth (JWT, cookies) for that. Mutual TLS (mTLS) flips this: both sides present certificates during the handshake, and both sides verify the other.

mTLS is the standard authentication for service mesh deployments (Istio, Linkerd, Consul Connect). Every service in the mesh gets a short-lived certificate signed by an internal CA. Services talk to each other only if both present valid certs. No shared secrets. No API keys to rotate. Certificate rotation is automated (spiffe.io defines the SPIFFE/SPIRE standard for this).

Where TLS terminates in a real architecture

The most common pattern: TLS terminates at the load balancer (Nginx, HAProxy L7, AWS ALB, or CDN edge). The LB decrypts and forwards plain HTTP to the origin. This lets the LB inspect and route based on HTTP content. The trade-off: the LB-to-origin traffic is plaintext, which is fine within a private network but a security concern in some regulated environments — enterprises use end-to-end TLS or service mesh mTLS to encrypt those hops too.

Applied in real systems — lots of examples

Key takeaways

• TLS is Layer 6 (Presentation). Sits between the transport (TCP or UDP-via-QUIC) and the application (HTTP, gRPC, SMTP).
• Three guarantees: confidentiality, integrity, authentication. Optional mTLS also authenticates the client.
• TLS 1.3 (2018) reduced the handshake to 1 RTT (or 0-RTT for session resumption). Removed all forward-non-secret cipher suites. Simpler and faster than 1.2.
• Certificates chain from a Root CA (in your trust store) through Intermediate CAs down to a Leaf cert proving domain ownership. ~200 Root CAs are preinstalled in every OS.
• Let's Encrypt (2016) made HTTPS free and automated. Certificate Transparency (Chrome 2018+) makes CA misuse detectable. HSTS prevents downgrade attacks.
• mTLS is the modern service-to-service auth pattern. Istio, Linkerd, Consul Connect all default to mTLS. SPIFFE/SPIRE standardizes workload identity.
• Where TLS terminates is an architecture decision. Most commonly at the L7 LB. Regulated environments push it to end-to-end.

References

• RFC 8446 (2018) — TLS 1.3 specification.
• Rescorla & Dierks — the primary TLS 1.3 authors.
• RFC 5280 — X.509 certificate profile.
• RFC 6962 / RFC 9162 — Certificate Transparency.
• Ivan Ristić — Bulletproof TLS and PKI.The definitive practical book.
• SSL Labs — free TLS configuration tester at ssllabs.com/ssltest.