TLS Encryption
Prove identity, encrypt everything
TLS 1.3 negotiates a cipher suite, the server proves its identity with an X.509 certificate, both sides derive a shared secret via ECDHE, and all subsequent data is encrypted.
How It Works
TLS 1.3 (RFC 8446) secures the connection in a single round trip. The client sends a ClientHello containing supported cipher suites and a key share (its half of an ECDHE key exchange). The server responds with a ServerHello (chosen cipher suite), its key share, its certificate chain, and a signature proving it possesses the certificate's private key. Both sides independently derive the same shared secret using Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) — without the secret ever crossing the wire.
The browser validates the server's certificate: Is it signed by a trusted Certificate Authority? Is it within its validity period? Is the domain name in the certificate's Subject Alternative Name (SAN) field? Has it been revoked (OCSP stapling)? Is it logged in Certificate Transparency logs? Only if all checks pass does the connection proceed. From this point, every byte of data — HTTP headers, cookies, request bodies, responses — is encrypted with AES-256-GCM or ChaCha20-Poly1305.
The Signal Flow
Key Concepts
A key exchange protocol where both parties generate temporary key pairs, exchange public halves, and independently derive the same shared secret. 'Ephemeral' means new keys every connection — providing forward secrecy.
Even if the server's long-term private key is compromised in the future, past recorded traffic cannot be decrypted. Each connection's encryption key is derived from ephemeral ECDHE keys that are discarded after use.
Server cert → intermediate CA cert → root CA cert. Your browser trusts ~150 root CAs. The server only needs to send its cert and intermediates; the browser already has the roots.
All publicly-trusted certificates must be logged in public, append-only CT logs. This means a rogue CA can't issue a certificate for your domain without it being publicly visible and detectable.
Deep Dive
TLS 1.3 vs 1.2 — what changed
TLS 1.3 is a major simplification. It removed insecure algorithms (RSA key exchange, CBC ciphers, MD5, SHA-1), reduced the handshake from 2 round trips to 1, and made encryption mandatory for the handshake itself (in 1.2, the certificate was sent in plaintext). The result: faster connections, fewer attacks, and a much smaller specification. There are only 5 cipher suites in TLS 1.3, compared to hundreds in 1.2.
The Web PKI trust model
The Web Public Key Infrastructure is a trust hierarchy. ~150 Certificate Authorities (CAs) are trusted by browsers. CAs verify domain ownership (via DNS or HTTP challenge) before issuing certificates. Let's Encrypt automated this process in 2015, making HTTPS free and universal. The CA/Browser Forum sets policy — like certificate maximum lifetime (currently 398 days, moving toward 90 days). If a CA misbehaves, browsers remove it from their trust store, effectively revoking all its certificates.
Related Specs
Must-know specifications from the Transport Security, Certificate Trust layers.
Every HTTPS connection, SMTP/IMAP over TLS, OAuth token exchange, and API call uses TLS. It is the foundational security layer.
A one-line HTTP header that eliminates a class of downgrade attacks. Every public web app should set HSTS.
Governs every TLS certificate you buy or provision via Let's Encrypt/ACM/Digicert. Understanding BR helps with cert errors, CAA records, and domain validation requirements.