Reqflow
← All concepts
Security·3 min read

Encryption in Transit & at Rest

Encrypt data on the wire (TLS) and on disk (at-rest) so neither a network eavesdropper nor a stolen drive yields plaintext.

Try it

Encrypt a message and send it. See what the eavesdropper gets.

You"Transfer $500"encrypt with key
the wire
Recipientwaiting…decrypt with key

Encryption scrambles data with a key so only someone with the right key can read it. In transit (TLS) it stops eavesdroppers on the network; at rest it protects data if the disk is stolen. Anyone in the middle sees only ciphertext, which is useless without the key.

First time reading this? Start here

Plain English: encryption in transit (TLS/HTTPS) scrambles data while it travels the network so eavesdroppers can't read it. Encryption at rest scrambles data sitting on disk so a stolen drive or leaked backup is useless. You need both, since they protect against different attackers.

What it is

Two complementary protections. Encryption in transit secures data moving over a network (TLS for HTTP, mTLS between services) so anyone sniffing the wire sees ciphertext. Encryption at rest secures stored data (disk/volume encryption, database/field-level encryption, encrypted backups) so anyone who obtains the physical media or files can't read them. Symmetric crypto (AES) does the bulk work; asymmetric crypto and key management handle key exchange and rotation.

The problem it solves

Data is exposed in two places: while moving and while sitting still. A network attacker can intercept unencrypted traffic; a thief, insider, or misconfigured bucket can expose unencrypted storage. In-transit encryption defeats eavesdropping and tampering on the wire; at-rest encryption defeats stolen-disk, leaked-backup, and snapshot-exposure scenarios. Compliance regimes (PCI-DSS, HIPAA, GDPR) generally mandate both.

How it works

In transit: TLS does an asymmetric handshake to authenticate the server (via certificates) and agree a symmetric session key, then encrypts the stream with AES; mTLS adds client-cert authentication for service-to-service. At rest: data is encrypted with a symmetric data key before hitting disk; that data key is itself encrypted by a master key held in a KMS/HSM (envelope encryption), enabling rotation without re-encrypting everything. Sensitive fields can be encrypted at the application layer so even the database never sees plaintext.

Why use it

  • In-transit (TLS/mTLS) defeats eavesdropping and man-in-the-middle on the network
  • At-rest defeats stolen disks, leaked backups, and exposed snapshots
  • Envelope encryption + a KMS lets you rotate keys and revoke access without re-encrypting all the data

What it costs you

  • Key management is the hard part: lose the key and the data is gone; leak it and encryption is moot
  • At-rest disk encryption doesn't protect a running, compromised app, since the data is decrypted in memory for live access
  • Crypto and handshake overhead add latency/CPU (small with modern hardware, but real for high-throughput or microsecond systems)

Where it shows up in our architectures

  • Payment Gateway

    TLS on every API call plus at-rest encryption of card data in the ledger; both are hard PCI-DSS requirements

  • WhatsApp

    End-to-end encryption means messages are encrypted on the sender's device; even the server stores only ciphertext in transit and at rest

  • Amazon S3 (Object Storage)

    Server-side encryption with KMS-managed keys encrypts every object at rest; TLS protects it in transit to and from the store

Gotchas

  • At-rest encryption does nothing against a compromised live application: the app holds the decryption key and serves plaintext. It defends against stolen media, not against an attacker who's already inside.
  • Key management is the whole game. Hardcoded keys, keys in the repo, or keys next to the data defeat the purpose, so use a KMS/HSM and envelope encryption so you can rotate and revoke.
  • TLS termination at the load balancer leaves traffic plaintext on the internal network. If that network isn't trusted (multi-tenant, compliance scope), use mTLS end-to-end, not just at the edge.
  • End-to-end encryption (WhatsApp-style) is different from server-side at-rest encryption: with E2EE the server can't read the data at all, which also means it can't search, index, or recover it.
When this went wrong in production

Heroku's OAuth token breach: 7-week secret exposure · 2022

Postmortem ↗

An attacker stole Heroku's GitHub OAuth tokens and downloaded private repos for 7 weeks undetected.

In April 2022, GitHub notified Heroku that OAuth tokens from Heroku's GitHub integration had been used to access private repositories, including Salesforce's own internal infrastructure repos. The attacker got the tokens from an internal Heroku database. They'd been stored with insufficient encryption and the attacker had access for roughly 7 weeks before detection. Because the access pattern (a token reading repos it had authorized access to) looked like normal OAuth usage, existing monitoring never flagged it. Heroku revoked all OAuth tokens, breaking GitHub integrations for every Heroku customer. The lesson: OAuth tokens at rest are secrets. Encrypt them with envelope encryption and rotate them. Anomaly detection for authorization must use behavioral baselines, not just permission checks.

Zoom's certificate expiry takes down 300M daily meeting users · 2020

Postmortem ↗

An expired TLS certificate silently broke Zoom for millions of users for 2 hours before anyone noticed.

In August 2020, a TLS certificate used by Zoom's authentication infrastructure expired without being renewed. Certificate expiry doesn't produce a loud failure. Clients simply can't establish a TLS handshake and get a connection error. For users, this looked like the Zoom app failing to log in or freezing on the meeting join screen. Because the failure was a silent TLS error rather than an obvious application exception, Zoom's monitoring didn't alert for nearly 30 minutes. 300M daily users were affected. The lesson: certificate expiry is one of the most predictable outages in existence. Monitor cert expiry as an SLO metric. Alert at 30 days, page at 7, and auto-renew by default. Let's Encrypt and AWS ACM exist precisely to make manual renewal unnecessary.

Interview angle

Encryption comes up as a standard checklist item in any system design with sensitive data. The signal is knowing that in-transit and at-rest protect against different attackers: TLS defeats a network eavesdropper, at-rest encryption defeats a stolen disk. Show you know key management is the real challenge by mentioning envelope encryption and a KMS so you don't store data keys next to the data. Candidates lose points by just saying 'use HTTPS' without addressing at-rest encryption for stored sensitive data.

Your notes

Private to you