TLS
Transport Layer Security encrypts a connection and authenticates one or both parties, giving you confidentiality, integrity, and identity. It's what makes HTTPS private. Handshakes negotiate a cipher and exchange keys, then data flows encrypted.
- Everywhere — encrypt in transit is table stakes.
- mTLS for service-to-service in zero-trust networks.
- Inside a physically isolated, trusted network where the CPU cost matters and threat model allows (rare).
Definition
TLS establishes an encrypted, authenticated channel. The server presents a certificate (trusted by a CA); TLS 1.3 does a 1-RTT handshake (0-RTT resumption optional). mTLS also authenticates the client. Session keys are derived via ECDHE for forward secrecy.
Why it exists
Without it, traffic is readable and tamperable on the wire, and you can't trust you're talking to the real server. TLS gives the 'S' in HTTPS and underpins API auth and service-to-service trust.
How it works
Client sends supported ciphers + a key share; server picks one, sends cert + key share; both derive shared keys; encrypted data follows. Certs are validated via a chain to a trusted CA. Modern stacks use ALPN to negotiate HTTP/2 or HTTP/3 in the handshake.
Scaling limits
Handshake CPU was historically the cost; TLS 1.3 and session resumption cut this. At scale, terminate TLS at a proxy/LB to centralize cert management and offload CPU.
Cost shape
CPU for handshakes (mitigated by resumption and ECDSA). Cert issuance is free via Let's Encrypt; enterprise certs/SANs and HSM key storage cost more.
Alternatives
- WireGuard/IPsec — Encrypts at the network layer for site-to-site, not per-app identity.
- Application-level crypto — Reinvents TLS poorly; almost never justified.
Failure modes
- Expired or mis-chained certs causing outages.
- Weak ciphers or no forward secrecy.
- 0-RTT replay attacks if not mitigated.