A guided, interactive walk from a customer's browser to your database — and the cryptography that protects each hop. Pick a stage to go deep; the Overview map links straight into every concept.
"Encrypted in transit" and "end-to-end encrypted" are different claims. The path into a database is almost never true E2EE — it's a chain of separately encrypted hops, broken wherever TLS terminates and plaintext briefly lives in memory.
Hop-by-hop. Each segment is encrypted, then decrypted at the next boundary. Protects data on the wire, not necessarily at rest in between.
Only the final recipient holds the key. Every intermediary — CDN, gateway, app server — sees ciphertext only.
The route below is Guarantee A. Plaintext appears at every termination point — that's where compliance exposure lives.
Tap any stage to open its deep-dive tab. Teal segments carry ciphertext; amber nodes are where data is decrypted.
The route above is the journey. Everything here applies across it — the trust, the keys, the identity and the foundations each hop depends on. Tap any concept to open its own tab.
Every concept on this map now has its own tab — the data path, the controls that wrap each hop, and the wider ecosystem of trust, key, identity and data-protection topics around them. Tap any node above, or use the tab bar, to go deep. 25 tabs, one self-contained page.
Before any data moves, the client and server run a handshake: agree on a shared key, prove the server's identity, and switch on encryption. TLS 1.3 does it in one round trip; TLS 1.2 needed two.
One session performs four jobs. Switch versions to see how TLS 1.3 collapsed two round trips into one, and step through each message.
TLS 1.3 also supports 0-RTT resumption: a returning client can send data in its very first flight. It's faster but those 0-RTT bytes lack replay protection, so they're reserved for safe, idempotent requests.
The key-exchange job. Diffie-Hellman lets both sides derive an identical secret while an eavesdropper watches every byte — like mixing paint: easy to mix, practically impossible to un-mix. Change either private colour:
Real ECDHE swaps paint for scalar multiplication on Curve25519 (X25519): public = k·G, shared = a·(b·G) = b·(a·G). Keys are ephemeral — discarded after the session — which is what gives forward secrecy.
Across untrusted networks the payload is protected by an AEAD cipher — Authenticated Encryption with Associated Data — which delivers confidentiality and integrity in a single operation. The two you'll see are AES-GCM and ChaCha20-Poly1305.
Click any byte to alter it and watch the authentication tag react. The tag is checked before decryption — so tampering is caught and the record dropped.
AES-GCM runs AES in counter mode to make a keystream, then computes a tag over the result. Highlight each path:
Both are AEAD and both are strong. The choice is about the hardware. Does the endpoint have an AES instruction set (AES-NI on x86, ARMv8 crypto)?
Throughput is illustrative. The real point: AES-GCM flies on silicon with AES instructions but can leak timing in pure software; ChaCha20 is constant-time in software, so browsers prefer it on devices without AES hardware. TLS 1.3 negotiates this per connection.
A suite name lists the algorithms a session uses. Tap each part; switch versions to see what TLS 1.3 streamlined.
The CDN, WAF, or load balancer is where the public TLS connection usually ends. How it ends decides where plaintext appears and what the edge can inspect. This is the single most audit-relevant choice in the whole path.
Switch models and watch where plaintext lives (amber) and what the edge can do for you.
At every termination point your data exists as plaintext in memory, and whoever controls that point can read it. For a vendor review the questions are concrete:
Past the edge, services talk to services. A flat "trusted" network passes plaintext between them; a zero-trust mesh wraps every hop in mutual TLS so a single breach can't move laterally. The difference is blast radius.
Click a service to compromise it. Watch how far an attacker reaches in each model.
Flat networks treat "inside" as safe, so one foothold exposes everything reachable. A mesh (Istio, Linkerd) gives every workload a cryptographic identity via SPIFFE/SPIRE and requires mutual TLS on each call — the breached node still can't impersonate or read its neighbours.
Transit protection ends at the database; a separate mechanism protects the stored bytes. Which one you pick determines which threats you actually stop — a stolen disk is not the same threat as a compromised application.
Tap a threat column to see which mechanisms defend against it.
| Mechanism | Stolen disk / backup | Compromised app query | Rogue DBA / full dump |
|---|---|---|---|
| Volume / disk encryption | ✓ | ✗ | ✗ |
| TDE (transparent DB enc.) | ✓ | ✗ | ✗ |
| Field-level / app-layer enc. | ✓ | partial | ✓ |
TDE and disk encryption protect against stolen media — not against a query from a compromised app, which still returns plaintext. Only field-level encryption keeps data opaque to the database itself.
Data is encrypted with a data key (DEK); the DEK is itself encrypted by a key-encryption key (KEK) held in a KMS or HSM. Only the wrapped DEK is stored beside the data.
Rotating the KEK re-wraps the DEK in milliseconds — the terabytes of ciphertext never move. That's why envelope encryption makes rotation cheap, and why KEK custody (KMS vs. HSM, separation of duties) is the real control to audit.
If the database must hold data no intermediary ever saw in cleartext, the client encrypts the field with a key the edge and app never possess. The lock never opens along the way.
Trade-off: the server can't search, index, or compute on those fields — which drives searchable/deterministic encryption (CSFLE, Always Encrypted) and confidential computing.
E2EE reuses the same primitives but arranges them so no server holds a usable key. Signal's design is two algorithms: X3DH for the initial agreement, then the Double Ratchet for every message after.
X3DH establishes the first shared secret by combining several Curve25519 DH operations against pre-published keys — even while the recipient is offline:
The Double Ratchet then derives a fresh, one-time key for every message. Send messages, then try compromising the endpoint:
TLS gives forward secrecy per session; the Double Ratchet gives it per message and adds self-healing. Signal's PQXDH folds a Kyber / ML-KEM key encapsulation into X3DH against "harvest-now, decrypt-later." Group E2EE at scale uses MLS (RFC 9420).
The handshake only protects a connection that actually forms over HTTPS, with a certificate you can trust. Two systems guarantee those preconditions: HSTS forces HTTPS on the first request, and the WebPKI decides whether a certificate is genuine.
HTTP Strict Transport Security is a remembered header — not encryption — that tells the browser to use HTTPS only, and never allow a click-through past a cert warning. It closes the gap the handshake can't: the first cleartext request, before TLS exists.
A server's certificate is trusted because it chains up to a root your browser already trusts. Tap each link:
In the handshake, CertificateVerify proves the server holds the leaf's private key; the browser walks the chain to a trusted root, checks validity and revocation, and (for many CAs) expects the cert to appear in public CT logs — which is how mis-issued certificates get caught.
A certificate can be unexpired and signed by a trusted CA yet no longer trustworthy — the private key leaked, the domain changed hands, or the CA mis-issued it. Revocation is how that “pull it back” signal reaches the browser. The hard part is not publishing the signal; it is making the client refuse to proceed without it.
Fixed threat: the cert was revoked 2 hours ago after a key compromise, and an on-path attacker blocks the CA’s revocation endpoint. Switch the checking method and watch whether the browser still trusts the dead certificate.
The modern answer is to stop revoking and start expiring. If a certificate only lives for days, the revocation window closes on its own — it expires before any CRL or OCSP cache would even refresh. Let’s Encrypt now offers opt-in ~6-day certs, and the CA/Browser Forum is phasing the maximum lifetime down to 47 days by 2029 — already 200 days as of March 2026. Automation (ACME) makes that practical.
Browser reality: rather than live OCSP, Chrome ships curated CRLSets and Firefox uses bloom-filter-based CRLite — both push revocation data to the client so no per-visit query (and no privacy leak) is needed. For a vendor review, the questions that matter: do you OCSP-staple, is Must-Staple set, and how short are your certificate lifetimes?
Every layer in this guide ends at the same question: where do the keys live, who can use them, and can you prove it? A strong cipher with its key sitting in plaintext next to the data buys you nothing. Key management is the control that decides whether “encrypted” means anything at all.
Data is sealed with a DEK, the DEK is wrapped by a KEK, and the KEK is wrapped by a root key that never leaves the HSM. Pick an action and watch what actually moves.
The single most important key question for a regulated workload: can your cloud provider decrypt your data without you? The control model decides.
HSM & FIPS 140-3 in one breath. A Hardware Security Module is tamper-resistant hardware that generates and uses keys but never releases them in plaintext — the crypto happens inside the boundary. FIPS 140-3 grades that boundary: L1 basic, L2 tamper-evidence + role auth, L3 tamper-response that zeroizes keys on intrusion (the common bar for regulated data), L4 hardened against environmental attack.
No single person should be able to extract or use the root key. A key ceremony with M-of-N control (e.g. 3 of 5 custodians) and dual control enforces separation of duties — and every use is logged, so you can prove the key never left the HSM.
A future quantum computer would break today's ECDHE and RSA. The threat is already live as "harvest now, decrypt later": capture ciphertext today, decrypt it once the hardware exists. The fix is the same primitives, hardened.
In 2024 NIST published ML-KEM (FIPS 203) for key establishment, and ML-DSA (204) and SLH-DSA (205) for signatures — the three core standards are final. Two more are still on the track: a code-based KEM backup, HQC (selected 2025, in case lattices fall), and a compact signature scheme, FN-DSA / FALCON (FIPS 206, draft). Deployment is concrete: major browsers and CDNs negotiate hybrid key exchange today, pairing a classical curve with a PQ KEM so the result is safe if either holds.
Two procurement gates for regulated work: is the crypto inside a FIPS 140-3 validated module (not merely "uses AES"), and does the vendor hold a crypto-agility / PQC transition plan?
Note the asymmetry: symmetric encryption (AES-256, ChaCha20) only needs a doubled key size to resist Grover's algorithm, so AES-256 is fine. It's the public-key parts — key exchange and signatures — that need replacing.
On resumption, TLS 1.3 can send application data in the very first flight using a key from the last session. It saves a round trip, but that early data is not forward-secret and can be replayed — fine for reads, dangerous for anything that changes state.
On resumption, TLS 1.3 lets the client send early data with its first flight — before the handshake finishes — using a pre-shared key from the last session. It saves a round trip, but that early data has no forward secrecy and can be replayed. Pick what rides in it and watch an attacker resend the captured packet.
The rule of thumb. 0-RTT is safe only for requests that are harmless to run twice. Most servers ship it off by default or restrict it to safe methods; enable it for state-changing endpoints only behind single-use tickets, a server-side anti-replay window, and application idempotency keys — and never for authentication or payment flows.
This is the one place where the Customer device handshake leaks a security property for speed: early data sits outside the forward-secret, replay-protected channel the full handshake gives you. For a governance review, “is 0-RTT enabled, and on which routes?” is a fair question.
End-to-end encryption keeps the provider out of your messages, but the provider still hands out the public keys. Key transparency publishes those bindings to an auditable, append-only log so a silent key substitution can be detected rather than simply trusted away.
End-to-end encryption keeps the provider out of your messages — but the provider is still the one who hands out the public keys. If it vends you the attacker’s key instead of your contact’s, the math is flawless and the attacker reads everything. Fixed threat: the provider performs a silent key substitution for your conversation with Bob. Pick the defence.
Certificate Transparency, but for identity keys. A key-transparency service publishes every (user → key) binding into an append-only, publicly auditable log (a Merkle tree). Your client checks that the key it was given for a contact is the one in the log, and that the log never rewrites history. A targeted substitution then has nowhere to hide: the rogue key is either absent from the log or permanently recorded for the world to see.
In the wild: Google Key Transparency, WhatsApp Key Transparency, Apple’s iMessage Contact Key Verification, and the CONIKS research it grew from. It does not prevent a provider from issuing a bad key — it makes doing so detectable, which is what shifts the trust model. The End-to-end tab showed the message is unreadable in transit; this closes the gap before the first byte is sent. Vendor question: how are identity keys distributed, and can substitution be detected?
Service-to-service auth ran on long-lived shared secrets for decades. SPIFFE gives each workload a cryptographically verifiable identity in a short-lived, auto-rotated credential issued only after attestation — collapsing the blast radius of a leaked credential from months to minutes.
Services authenticate to each other too — and for decades they did it with long-lived shared secrets: API keys and static certs baked into config, env vars and container images. SPIFFE gives each workload a cryptographically verifiable identity in a short-lived, auto-rotated credential (an SVID) issued only after the workload attests to what it is. Leak each credential into a log and see how much an attacker actually gets.
How SPIFFE works. Every workload gets a SPIFFE ID — a URI like spiffe://acme.example/ns/prod/sa/billing — carried in an SVID (an X.509 cert or JWT). The workload proves what it is to a SPIRE agent through node and workload attestation (Kubernetes service account, cloud instance identity, process/kernel facts); only then is an SVID issued, and it is rotated automatically every few minutes. Services then mutually authenticate over mTLS using those SVIDs — no shared secrets to leak, embed or forget to rotate.
The Internal · mTLS tab showed mutual authentication shrinks blast radius; SPIFFE answers the question it raised — where do those certs come from, and how do they stay short-lived? Service meshes such as Istio build on SPIFFE identities. Governance payoff: verifiable, auditable workload identity and the end of standing credentials.
A ClientHello is cleartext, and its cipher and extension ordering is characteristic of the software that sent it. JA3 and JA4 hash that into a signature — letting defenders identify what is talking without reading what it says, and reminding everyone that the shape of an encrypted connection is itself observable.
A ClientHello is sent in cleartext, and its cipher list, extensions and their exact order are characteristic of the software that produced it. JA3 and JA4 hash those fields into a compact signature — so a defender can identify what is talking without decrypting what it says. Pick a client and watch the same handshake become an identity.
JA3, then JA4. JA3 (Salesforce, 2017) MD5-hashes the TLS version, cipher list, extensions, curves and point formats; JA3S does the same for the server’s reply. JA4 (FoxIO, 2023) is a more robust successor family (JA4, JA4S, JA4H…) — human-readable, resistant to trivial cipher/extension shuffling, and built for TLS 1.3 and GREASE. Both turn a handshake into a stable label.
Used for bot and malware detection over encrypted channels, asset inventory, and WAF/CDN rules — detection without decryption. The flip side is privacy: the shape of your connection is observable even when its contents are not, and Encrypted ClientHello (ECH) hides the SNI but not the whole fingerprint. Every other tab protects what is in the connection; this one is the reminder that the connection itself is metadata.
Every key, nonce and signature in this guide is drawn from a random number generator. If that generator is predictable — by mistake or by design — the attacker reconstructs the keys and the strongest cipher above it protects nothing.
Every key in this guide — TLS session keys, ECDHE ephemerals, nonces, the DEK and KEK, every signature — is drawn from a random number generator. If that generator is predictable, the attacker reconstructs the keys and the strongest cipher above it protects nothing. Pick the RNG and see what an attacker can do.
Two cautionary tales — one malice, one mistake. Dual_EC_DRBG was a NIST-standardised generator (SP 800-90A, 2006) whose two curve points could form a backdoor: whoever chose them to know the secret scalar between P and Q could predict all future output after seeing ~32 bytes. Shumow and Ferguson demonstrated the risk in 2007; 2013 reporting indicated the NSA had paid to make it the default in a widely-used toolkit; NIST withdrew it in 2014.
Debian OpenSSL (CVE-2008-0166) needed no villain: a maintainer removed a line that fed entropy into the RNG, so for ~2 years every SSH and TLS key on Debian and Ubuntu was seeded from little more than a process ID — roughly 32,000 possible keys, brute-forced in seconds.
Related failures rhyme: reused ECDSA nonces have leaked signing keys, and low boot-time entropy on embedded devices has produced thousands of TLS keys sharing factors. The throughline for a governance review: good randomness is an assumption every other control silently depends on — worth verifying, not assuming.
Browsers trust hundreds of certificate authorities, and any one of them can issue a certificate for your domain — through compromise, error or coercion. Certificate Transparency forces every issued certificate into public, append-only logs, turning silent mis-issuance into something you can detect and revoke.
Fixed threat: a trusted CA mis-issues a certificate for your domain to an attacker. The cert is cryptographically valid and chains to a trusted root. Switch on the transparency machinery and see whether you ever find out.
Receipts in the handshake. Certificate Transparency (RFC 6962) runs public append-only Merkle logs of every issued certificate. A cert carries SCTs — signed timestamps proving it was logged — and Chrome and Safari reject certificates that lack enough of them. So to be usable at all, a cert must first be made public, where domain owners and auditors can see it.
CT was born from the DigiNotar compromise (2011) and hardened through the Symantec mis-issuance distrust. Monitor your own domains with tools like crt.sh or Cert Spotter. It is the web-PKI sibling of the Key transparency tab: one watches certificate authorities, the other watches messaging identity keys. CT detects; Revocation then removes.
Transit and at-rest encryption are solved problems; the data is still exposed in plaintext while it is being processed in memory. Confidential computing closes that third gap.
Data is protected in transit by TLS and at rest by disk encryption — but to be processed it must be decrypted into memory, and there it sits as plaintext. Add each layer and watch where exposure remains.
Closing the in-use gap. Confidential computing runs the workload inside a Trusted Execution Environment — a hardware enclave with encrypted memory, isolated from the OS, hypervisor and cloud operator. Remote attestation then proves to a relying party that a genuine enclave is running the exact expected code before any secret is released.
Forms range from process-level (Intel SGX) to whole-VM (AMD SEV-SNP, Intel TDX, ARM CCA). Use cases: processing regulated data in an untrusted cloud, multi-party computation, and protecting keys in use. It is the third leg of the lifecycle alongside the Public internet (transit) and Database (at rest) tabs.
TLS protects the connection, but the DNS lookup that finds the server is traditionally cleartext — visible to observers and forgeable by spoofers. Encrypted DNS and DANE close that upstream gap.
Before TLS can protect anything, DNS turns the name into an address — traditionally in cleartext. An on-path party can watch every site you visit and forge the answer to redirect you. Add protection and see what the attacker keeps.
Privacy and authenticity are different jobs. DoH (RFC 8484) and DoT (RFC 7858) encrypt the query to a trusted resolver, hiding it from observers. DNSSEC signs the records so forged answers are rejected. DANE (RFC 6698) publishes the site cert in a DNSSEC-signed TLSA record, pinning it independently of the CA system.
One caveat: even with encrypted DNS, the hostname leaked in the TLS SNI until Encrypted ClientHello (ECH) closed that gap. Encrypted DNS and DANE sit just upstream of the Customer device handshake and complement Certificate Transparency in the trust story.
Server-to-server email encryption is opportunistic by default and trivially downgraded. MTA-STS and DANE turn it into enforced, downgrade-resistant TLS.
SMTP between mail servers starts in cleartext and upgrades via STARTTLS only if both sides offer it — which an active attacker can quietly strip, forcing plaintext with no warning. It is the same gap HSTS closed for the web. Add enforcement and watch the strip fail.
Enforcing transport, two ways. MTA-STS (RFC 8461) lets a domain publish an enforce policy over HTTPS so senders refuse to downgrade — the email analogue of HSTS — with TLS-RPT reports for failures. DANE for SMTP (RFC 7672) anchors the requirement and the receiving cert in DNSSEC-signed TLSA records, removing the web-PKI bootstrap MTA-STS leans on.
This is transport security between servers, distinct from end-to-end message encryption (PGP, S/MIME), which protects content from the mail providers themselves. It mirrors the Transport guards tab’s HSTS story, one layer down the stack.
Sometimes the best protection is to not hold the sensitive value at all. Tokens and format-preserving ciphertext keep the shape while moving the real data out of reach — and out of audit scope.
Encrypting a card number protects it but changes its shape and keeps it in audit scope. Tokenization and format-preserving encryption replace the value with a same-shape surrogate, so most systems never touch the real number. Switch representation and watch the scope move.
Tokens versus ciphertext. A token is a random surrogate with no mathematical relationship to the original; the real value lives only in a hardened vault, so systems holding only tokens fall out of PCI DSS scope. Format-preserving encryption (NIST FF1) instead encrypts while keeping the length and character set, so a 16-digit card becomes another 16-digit value that fits existing schemas and validation.
Both shrink the blast radius of a breach and the systems an auditor must inspect. Caveats: the token vault becomes a high-value target, and some FPE modes (FF3) have needed cryptanalytic fixes. This complements the Database tab’s at-rest controls by reducing what is sensitive in the first place.
Applications run on credentials, and where those live and how long they last decides what a single leak costs. Dynamic, short-lived secrets shrink that blast radius to almost nothing.
Apps need database passwords and API keys. Where those live, how long they last, and whether anyone can audit them decides what a single leak costs. Change the model and watch the blast radius shrink.
Dynamic secrets change the game. A secrets manager (HashiCorp Vault, the cloud secret managers) can generate a unique, short-lived credential on demand with an automatic lease, log every issuance, and revoke instantly. The leak window shrinks from months to minutes, and there is no standing shared secret to steal.
The bootstrap problem — how does the app authenticate to the secrets manager without a secret zero — is solved with workload identity, the SPIFFE story. This is distinct from Key management: a KMS handles cryptographic keys, a secrets manager handles arbitrary credentials and their lifecycle.
Algorithms break and standards move. A cryptographic inventory plus the ability to swap algorithms without re-architecting is what turns the post-quantum transition from a panic into a plan.
When an algorithm is deprecated — or quantum computers arrive — the hard part is not the new algorithm, it is finding every place the old one is used. A cryptographic bill of materials plus crypto-agility decides whether migration is a project or a panic.
Inventory first, then agility. A CBOM (cryptographic bill of materials, an extension of the SBOM in formats like CycloneDX) lists every algorithm, key, certificate and protocol in use. Crypto-agility is the architectural property that lets you swap one for another without re-engineering — algorithms behind an abstraction rather than hard-wired.
The urgency is harvest-now-decrypt-later: adversaries can store today’s RSA/ECC traffic and decrypt it once quantum computers mature, which is what makes the Post-quantum migration a today problem. The same discipline handled the retirement of MD5, SHA-1, RC4 and DES.
A sound algorithm can be defeated by how it runs — timing, padding, cache. Side-channel resistance is the discipline of making the implementation reveal nothing about the secret.
An algorithm can be mathematically sound and still leak through how it is implemented — a branch that depends on a secret, or an error that distinguishes good padding from bad. The attacker measures the difference and extracts the secret without ever breaking the cipher.
Side-channels leak through behaviour. Timing, cache, power and error differences turn a secret-dependent code path into an oracle. Padding-oracle attacks (Lucky13, POODLE, ROBOT, Bleichenbacher) recover plaintext or keys by watching how a server reacts to malformed input — no algorithm is broken, only its implementation.
Defences: constant-time code with no secret-dependent branches or memory access, uniform error handling, and authenticated encryption. This is one more reason the Public internet tab favours AEAD over older CBC modes — AEAD removes the padding oracle entirely.
Certificates fail more often from a missed renewal than from broken math. Automated issuance and short lifetimes remove the human-error failure mode and bound every key’s exposure.
Certificates have a lifecycle: issued, deployed, renewed before expiry, replaced on compromise. Done by hand it produces outages and slow incident response. Automate it and the failure modes mostly disappear.
Automation, then short lifetimes. ACME (RFC 8555, popularised by Let’s Encrypt) automates validation, issuance and renewal, so certs renew themselves well before expiry and reissue fast on compromise. Pushing lifetimes down to days then bounds the exposure of any single key.
Let’s Encrypt now offers opt-in ~6-day certs and the CA/Browser Forum is phasing the maximum down to 47 days by 2029 (200 days as of March 2026). This is the issuance side of the Revocation tab’s thesis: the most reliable answer to revocation is a certificate that expires before it matters.