Encryption at Rest and in Transit
The checkbox says encrypted. That hides the two questions that matter, encrypted where and against whom.
What you will learn
- -Match at-rest and in-transit encryption to the attacker each one stops
- -Name the threats neither one covers
- -Read a TLS handshake and inspect a disk image to prove the difference
The says "data is encrypted" and everyone nods. That sentence hides the only two questions worth asking: encrypted where, and against whom. at and encryption in transit defend against completely different attackers, and each one is useless against the other's . Confuse them and you will protect a laptop that was never at while leaving the live database wide open.
Encryption at rest protects data sitting on storage. Full-disk encryption like LUKS on Linux, BitLocker on Windows, or the transparent volume encryption AWS puts under EBS and S3. The attacker it stops is physical: someone who steals the laptop, buys your decommissioned drive off eBay, or grabs a database snapshot from an unsecured backup bucket.
Here is the limit people miss. Full-disk encryption only helps while the disk is locked, which in practice means powered off. The moment the boots and mounts the volume, the data is transparently decrypted for anything with normal access. A against a running app reads no matter how the disk is encrypted. FDE on a server that never powers down is close to theater against a live attacker. It earns its keep on laptops and dead media, which is exactly where physical theft happens.
Encryption in transit protects data moving across a . That is , and in 2026 you want TLS 1.3 with valid checking. The attacker it stops is on the wire: someone sniffing the coffee-shop wifi, a compromised , a machine-in-the-middle downgrading your connection.
Its limit is symmetric to the other one. TLS protects the pipe, not the . Data is plaintext at both ends before it enters the tunnel and after it leaves. A TLS-terminating load balancer decrypts everything at the edge, so the traffic behind it on your own network is cleartext unless you re-encrypt to the backend. "We use " says nothing about what happens after the request lands.
$cryptsetup luksFormat /dev/sdb$openssl s_client -connect example.com:443 -tls1_3$testssl.sh https://example.comBetween the two sits the gap nobody covers: data in use. While your app processes a record, it is plaintext in RAM. Confidential computing and hardware enclaves aim at that window, but they are rare and you should assume memory is readable to anyone who owns the .
Seeing the difference for yourself is the fastest way to internalize it. Run Wireshark and watch a plain expose a in cleartext, then watch the same request over HTTPS turn into opaque bytes. Do the capture on a network you own or are authorized to test. Sniffing traffic on a network you do not is wiretapping in most places, full stop. Same rule for pulling a to prove FDE works, use your own VM.
The practical takeaway is to stop treating "encrypted" as one control. You need at rest to survive a stolen backup, in transit to survive a hostile network, and application-layer or field-level encryption to limit what a compromised app can read. Field-level encryption, where the app decrypts only the columns it needs with a key the disk never holds, is the one that actually shrinks the blast radius from a running- compromise. The other two do nothing for that case.
Your database volume has full-disk encryption. An attacker finds a SQL injection flaw in the running web app. What does the encryption do for you?