Every request your systems make crosses wires someone else controls. This page walks the full journey — handshake, identity, record protection, termination, internal hops — and shows where the guarantees actually hold, where they quietly end, and what an auditor will ask about each one.
TLS makes three promises about data on the move: nobody can read it (confidentiality), nobody can alter it undetected (integrity), and you know who is on the other end (authenticity). Most real-world failures do not break the math — they exploit the places where one promise was silently never made. Tap any node below to open its deep-dive.
The record layer seals every byte with authenticated encryption: an eavesdropper reads nothing, and a single flipped bit kills the connection. In modern configurations, this part of TLS is essentially unbroken.
Encryption to an unverified endpoint is a private conversation with a stranger. Certificates, validation, and termination points decide who actually holds the keys — and this is where nearly every practical failure lives.
Every concept above has its own tab with a hands-on interactive and the dense technical detail underneath. Ten concepts, eleven tabs, one self-contained page.
Before a single byte of application data moves, client and server must agree on a protocol version, a cipher suite, and — the hard part — a shared secret, over a network an attacker may fully control. TLS 1.3 rebuilt this step: fewer choices, fewer round trips, and almost the entire negotiation now happens under encryption.
The same client connects to the same server under three protocol generations. Switch versions and watch the round trips, the guarantees, and the verdict change.
How the TLS 1.3 handshake works. The client opens with a ClientHello that already contains its key shares — ephemeral public values for groups it expects the server to accept (X25519, P-256, or the hybrid X25519MLKEM768). The server answers with its own key share, and from that moment both sides hold a shared secret: the certificate, the CertificateVerify signature, and the Finished message all travel encrypted, and application data can follow after one round trip. Keys are derived through an HKDF-based schedule; only five AEAD cipher suites exist (AES-128/256-GCM, ChaCha20-Poly1305, and two AES-CCM variants), and static RSA key transport is gone entirely. A downgrade sentinel baked into ServerHello.random lets a 1.3-capable client detect an attacker forcing the pair down to an older version.
Context and caveats: 0-RTT resumption exists in TLS 1.3 but early data is replayable — restrict it to idempotent requests or disable it. QUIC (RFC 9001) embeds this same handshake, so HTTP/3 inherits the 1.3 security model. There will be no TLS 1.4: the IETF is refreshing RFC 8446 in place (rfc8446bis), which also forbids negotiating TLS 1.0/1.1 outright. Related tabs: why ephemeral key shares matter (Forward secrecy) and what the certificate step proves (Certificates).
Adversaries do not have to break TLS today; they can record ciphertext and wait for your private key to leak tomorrow — a breach, a mishandled backup, the next Heartbleed. Forward secrecy decides whether that recording ever becomes readable.
Traffic is recorded in 2026. The server’s long-term private key is stolen a year later. Switch the key-exchange method and see what the stolen key unlocks.
The mechanism. With ephemeral Diffie-Hellman (ECDHE over X25519 or P-256), each side generates a fresh key pair per connection, exchanges only the public halves, computes the shared secret locally, and deletes the ephemeral keys when the session ends. The long-term certificate key is used only to sign the handshake — authentication and key agreement are separated, so stealing the certificate key enables future impersonation (bad, but detectable and revocable) rather than retroactive mass decryption. Heartbleed (2014) is the canonical example of key theft at scale, and it is exactly the scenario forward secrecy contains. TLS 1.3 makes this mandatory; TLS 1.2 still allows static RSA key transport, and it still ships in legacy configurations.
Two caveats worth an auditor’s attention. First, session resumption: long-lived or poorly rotated session-ticket keys can quietly weaken forward secrecy — rotate ticket-encryption keys frequently. Second, forward secrecy protects against a classical adversary who later steals keys; it does nothing against a future quantum computer replaying the recorded handshake math itself. That distinct threat — and its fix — is the Post-quantum tab.
The padlock does not mean “safe”; it means “encrypted to whoever holds the private key for the certificate that was presented”. Certificate validation is the step that makes that party the one you intended — and disabling it, which one line of code can do, converts TLS into gift-wrapped delivery to your attacker.
Your client connects to api.bank.example across a hostile network where a proxy intercepts the connection. Switch the validation posture and watch whether the interception succeeds.
How the trust chain works. The server presents a leaf certificate binding its hostname (in the Subject Alternative Name field) to its public key, signed by an intermediate CA, which chains to a root the operating system or browser already trusts. The client checks the signature chain, the name match, the validity window, and — increasingly — a Certificate Transparency proof: RFC 6962 logs force every publicly trusted certificate into append-only public logs, and Chrome and Safari reject public certificates without one, so a rogue or coerced issuance for your domain becomes visible evidence you can monitor. Issuance itself is now overwhelmingly automated: roughly 94% of certificates are domain-validated, most via the ACME protocol (RFC 8555).
The current governance story is lifetime compression. CA/Browser Forum ballot SC-081v3 (approved April 2025) caps new public TLS certificates at 200 days as of March 15, 2026 — already in force — then 100 days in March 2027 and 47 days in March 2029, with domain-validation reuse shrinking to 10 days. Revocation remains the weak link (OCSP and CRLs fail open at internet scale), so short lifetimes are the practical mitigation, and certificate automation has quietly become a compliance requirement: PCI DSS 4.x demands a maintained inventory of the keys and certificates protecting account data (4.2.1.1). Where the certificate lives also decides where encryption ends — see Termination.
Once keys exist, every byte travels in records protected by authenticated encryption (AEAD): a single primitive provides both secrecy and a cryptographic seal. The seal matters as much as the scramble — encryption that does not authenticate lets an attacker modify what they cannot read.
A record carrying amount=100 crosses the wire and an attacker flips bits in the ciphertext. Switch the protection scheme and watch whether the tampering lands.
The mechanics. AEAD ciphers — AES-GCM and ChaCha20-Poly1305 (RFC 8439) — take a key, a unique nonce, the plaintext, and associated data, and produce ciphertext plus an authentication tag. The receiver verifies the tag before releasing a single byte; a failed check rejects the record and terminates the connection with an alert. Per-record sequence numbers feed the nonce, so replayed or reordered records also fail. TLS 1.3 permits only AEAD, encrypts the record type itself, and adds a key-update mechanism for long-lived connections. The legacy MAC-then-encrypt CBC construction, by contrast, generated a decade of padding-oracle attacks — BEAST (2011), Lucky Thirteen (2013), POODLE (2014) — that recovered plaintext byte by byte from error and timing behavior.
What AEAD does not hide: message lengths, timing, and destination metadata. Traffic analysis still works on encrypted flows, and the Server Name Indication in the ClientHello still reveals the hostname being visited — Encrypted Client Hello (ECH), still an IETF draft with growing browser and CDN deployment, is the effort to close that last plaintext window. For what happens when the attacker attacks the negotiation instead of the records, see Downgrade.
TLS is point-to-point, not end-to-end. The connection your customer’s browser opens terminates at the first box holding a certificate — a CDN edge, a load balancer, a WAF. Everything behind that point is a separate design decision, and it is the question most vendor answers quietly skip.
A browser reaches your app through a CDN or load balancer. The public leg is always TLS. Switch the back-half design and watch what the private leg exposes.
The taxonomy. Three patterns cover most estates. Termination: the edge decrypts and forwards plaintext — maximum inspection capability, maximum back-half exposure. Re-encryption (bridging): the edge decrypts, inspects, and opens a second TLS session to the origin — the edge still sees plaintext, but the private leg is covered. Passthrough: the edge routes on the TCP or SNI layer without decrypting — true end-to-end, but no L7 features (WAF, caching, bot rules). The history lesson is MUSCULAR (2013): intelligence agencies tapped the unencrypted private links between cloud datacenters, on the correct bet that “internal” segments were plaintext — Google encrypted its inter-datacenter traffic in direct response.
For a vendor review, the questions that matter: where exactly does TLS terminate, and is the origin connection encrypted and authenticated? Who holds the private keys — does the CDN hold them outright, or is a keyless-signing arrangement in place? Are decrypted payloads logged at the edge, and does that bring the provider into compliance scope for the data class involved? The strongest common answer — re-encryption with mutual TLS to a firewalled origin — is exactly the pattern the Internal & mTLS tab generalizes.
Past the edge, the old assumption was that the internal network is “trusted”. Every major intrusion of the last decade says otherwise: attackers who land on one workload read and impersonate their way sideways. Encrypting and mutually authenticating service-to-service traffic is how zero trust stops being a slogan.
An attacker holds one workload inside your VPC and targets the payments API next door. Switch the internal transport posture and see how far the foothold reaches.
How mTLS works at scale. Nobody hand-manages certificates for a thousand microservices. Service meshes (Istio, Linkerd) inject sidecar proxies that transparently upgrade every service-to-service call to mutual TLS; workload identity frameworks like SPIFFE/SPIRE issue short-lived X.509 identities (hours, not months) that rotate automatically and encode what the workload is rather than where it runs. Authorization policy then pins which identities may call which services — the payments service refusing everything except the checkout identity is a two-line policy, not a firewall project. Private CA services (cloud-native or Vault-based) anchor the internal trust chain, kept deliberately separate from the public web PKI.
Governance hooks: NIST SP 800-207 frames this as core zero-trust architecture — authenticate and encrypt every flow regardless of network location. PCI DSS 4.x pulls any internal segment carrying account data into scope and expects strong cryptography there, explicitly including wireless in the CDE (4.2.1.2). Practical caveat for assessments: kernel-level network encryption (WireGuard-style CNI overlays) encrypts the wire but does not authenticate the workload — it answers the confidentiality question and leaves the identity question open.
The cheapest attack on encryption is preventing it from being negotiated at all. Stripping attacks rewrite the first plaintext moments of a connection — the http:// redirect, the protocol offer — so both sides believe the other cannot do better. The defenses are commitments made in advance.
A user on a hostile network types bank.example with no scheme. The attacker answers first. Switch the HSTS posture and watch whether the plaintext moment survives.
The stripping family. sslstrip (demonstrated in 2009) proxies a plaintext HTTP session to the victim while speaking HTTPS upstream — no cryptography is broken, the victim simply never enters TLS. HSTS (RFC 6797) is the counter-commitment: a Strict-Transport-Security header instructs the browser to refuse plaintext for that domain for max-age seconds (set a year or more, with includeSubDomains), and it also removes the click-through option on certificate errors, which is a feature. The residual gap is trust-on-first-use; the preload list closes it by shipping the HTTPS-only commitment inside Chrome, Firefox, Safari, and Edge before any request is ever made. Modern browsers’ HTTPS-first modes narrow the same gap for non-preloaded sites.
Protocol-level downgrade has its own defenses: TLS 1.3 servers embed a fixed sentinel in ServerHello.random whenever a lower version is negotiated, so a 1.3-capable client detects the forced downgrade; the historical attacks this closes off include FREAK and Logjam (2015, export-grade suites) and the SSL 3.0 fallback that enabled POODLE. PCI DSS 4.x makes the governance version of the same point: approved protocols must not permit fallback to insecure versions or configurations (4.2.1). The email analog of stripping — deleting STARTTLS from an SMTP banner — gets its own tab: Email.
SMTP predates transport encryption by nearly two decades. STARTTLS retrofitted it — but as an offer, not a requirement: if the offer disappears, or an attacker deletes it, the mail goes in plaintext and nobody is told. Contracts, invoices, and password resets ride this channel every day.
Your mail server delivers to a recipient domain while an attacker on the path strips the STARTTLS capability. Switch the recipient’s transport policy and see whether the message leaks.
The three-layer fix. STARTTLS (RFC 3207, 1999) upgrades a plaintext SMTP session to TLS when both sides offer it — effective against passive taps, useless against an active attacker. MTA-STS (RFC 8461) lets a receiving domain publish an HTTPS-hosted policy: compliant senders (Gmail and Microsoft among them) must negotiate TLS 1.2+ with a valid certificate or refuse delivery, turning a stripping attempt into a bounce instead of a silent leak. DANE for SMTP (RFC 7672) goes further, pinning the expected certificate in a DNSSEC-signed TLSA record — no trust-on-first-use, no CA dependency, but it requires a signed DNS chain. Deploy MTA-STS in testing mode first with TLS-RPT (RFC 8460) reports, then enforce; add DANE where DNSSEC is available — senders support one or the other, so both together maximize coverage.
Where adoption actually stands: a June 2026 scan of 1.25 million domains found only about 0.3% with a fully valid MTA-STS deployment, against roughly 40% among UK government domains — the gap between regulated leaders and everyone else is enormous. Keep the layers straight in assessments: SPF, DKIM, and DMARC (now mandated for bulk senders by Google and Yahoo since 2024 and Microsoft since 2025) prove sender identity; MTA-STS and DANE protect transport confidentiality; and neither encrypts the message at rest — a domain at p=reject can still deliver everything in plaintext. The layers are independent, and audits routinely find exactly one of them done.
A cryptographically relevant quantum computer would break the elliptic-curve math every classical TLS handshake rests on. It does not exist yet — but recordings made today do, and any secret whose lifetime outruns the quantum runway is already at risk. The industry response is live: hybrid key exchange is now the default in every major browser.
A patient adversary records your traffic today and stores it until a quantum computer exists. Switch the key exchange and see whether the archive ever opens.
The mechanism and the rollout. ML-KEM-768 is the lattice-based key encapsulation mechanism NIST standardized as FIPS 203 (August 2024). In TLS 1.3 it rides alongside the classical curve in the X25519MLKEM768 named group (IETF draft-ietf-tls-ecdhe-mlkem, still standards-track): both secrets feed the key schedule, so an attacker must break both problems — a quantum attack on the curve still faces the lattice, and any future lattice surprise still faces the curve. The cost is about 1.1 KB of extra handshake data. Deployment moved fast: Chrome enabled it by default in April 2024, Firefox in November 2024, Apple platforms in October 2025, and Akamai made it the edge default in early 2026 — by early 2026 over 60% of browser-initiated connections offer the hybrid group and roughly half of scanned domains accept it.
What is deliberately unfinished: certificates are still classical — public deployment of post-quantum certificates is effectively zero so far, and that is rational sequencing: impersonation requires a quantum computer at connection time, while recorded key exchanges are at risk retroactively, so confidentiality migrates first. Governance clocks to plan against: NSA CNSA 2.0 sets 2033 as the completion date for national-security systems, and draft NIST guidance (IR 8547) proposes deprecating classical public-key cryptography by 2030 and disallowing it by 2035. One dependency risk-teams miss: only TLS 1.3 can carry these hybrid groups — a fleet pinned to TLS 1.2 has no migration path at all (see Handshake).
Frameworks do not ask whether you “use TLS”. They ask which protocols and suites are permitted, where the certificate inventory lives, what protects the segments behind the edge, and who reviewed all of it this year. This tab maps the mechanisms in this page to the questions an assessor will actually ask.
Rows are the transit-encryption controls from this page; columns are four frameworks a regulated shop most often answers to. Click a framework header to highlight its column and see what it actually demands.
| Control | PCI DSS 4.x | HIPAA | NIST 800-52r2 | ISO 27001 |
|---|---|---|---|---|
| Strong protocol floor — TLS 1.2+, no insecure fallback | ● | ◔ | ● | ◔ |
| Trusted certificates + key/cert inventory | ● | ◔ | ◔ | ◔ |
| Documented annual cipher & protocol review | ● | ◔ | ◔ | ● |
| Internal / service-to-service encryption | ● | ◔ | ◔ | ◔ |
| Email transport enforcement | ● | ◔ | ○ | ◔ |
| Post-quantum migration plan | ○ | ○ | ◔ | ○ |
Every hop in this page — browser to edge, edge to origin, service to service, MTA to MX — is its own decision with its own failure mode. Audit the segments, not the sentence.