Encryption is sold as an unambiguous good: encrypt everything, everywhere, and you’re safer. At first glance it does bring privacy — nobody in the middle can read your traffic, your disk, your backup. But privacy and security are not the same goal, and they don’t always move in the same direction. Sometimes gaining one costs you the other.
I already touched this in Full Containment? Do We Have to Treat Software Like Ebola?: “encryption like SSL ensures the privacy of data in transit, but this applies to both you and potential attackers.” This post is that sentence, unpacked.
Privacy, Security, and Safety Aren’t the Same Thing
Using the definitions from that earlier post:
- Privacy — the right not to be observed.
- Security — measures taken to prevent bad things from happening.
- Safety — measures taken in case something bad happens anyway.
At the airport, you trade privacy for security: you reveal your name and ID so the system can verify you’re not a threat. Encryption does the reverse trade: you gain privacy — nobody can observe your traffic or your data — at the cost of a security capability: the ability of anyone, including your own defenses, to inspect that traffic and tell good from bad.
That’s not an argument against encryption. It’s an argument against treating “encrypted” as a synonym for “secure.”
1. Blind Defenders
A TLS tunnel doesn’t just hide your data from an attacker in the middle — it hides an attacker’s data from you, too. Once a channel is encrypted end-to-end, your IDS, your DPI, your firewall’s content inspection all lose visibility into what’s actually flowing through it. They can see that a connection exists, not what it’s carrying.
This isn’t theoretical. It’s the default playbook for modern malware and C2 infrastructure:
- Ransomware and C2 channels increasingly ride over plain HTTPS specifically because it blends into normal traffic and defeats content-based detection.
- TLS 1.3 with Encrypted Client Hello (ECH) and DNS-over-HTTPS hide the destination as well as the content — from your ISP, yes, but also from your own corporate security stack.
- The “fix” — TLS inspection/interception, terminating and re-encrypting traffic at a proxy — reintroduces exactly the trust problem Zero Trust architectures are supposed to eliminate: now a single mid-path box holds the keys to everything, and every client has to trust a locally-installed CA certificate to make it work.
You can’t verify what you can’t see. Every layer of encryption you add between an attacker and your detection tooling is a layer your detection tooling has to be explicitly re-architected to see through.
2. False Sense of Security
“It’s encrypted” is one of the most dangerous sentences in security, because it tends to end the conversation instead of continuing it.
- An encrypted USB drive with a four-digit PIN is not meaningfully more secure than an unencrypted one against a motivated attacker — but it feels solved, so the harder questions (who has physical access, what’s on it, does it need to leave the building at all) stop getting asked.
- Encrypted backups that are never restore-tested are a common way to discover, during an actual incident, that the passphrase was lost, the key rotated without updating the backup target, or the backup software silently failed for six months.
- Compliance checklists often ask “is data encrypted at rest / in transit?” as a yes/no box. Once it’s checked, server hardening, patch cadence, and access control frequently get less scrutiny — not because anyone decided that on purpose, but because attention is finite and the box is checked.
Encryption is one control among many. Treating it as the control is how organizations end up hardened against the threat model they already solved and exposed to every other one.
3. Key Management Is a New Attack Surface
Encryption doesn’t remove the problem of protecting your data. It relocates it: instead of protecting the data directly, you now have to protect the key that protects the data — and that’s a smaller, more concentrated, and in some ways more attractive target.
- Lose the key and you’ve done to yourself what an attacker would otherwise have needed to do to you: made the data permanently inaccessible. A key management failure is a self-inflicted denial of service.
- Ransomware doesn’t fight your encryption — it uses the same mechanism against you, encrypting your data with a key only the attacker holds. The tool and the threat are the same technology pointed in different directions.
- Every additional piece of key management infrastructure — an HSM, a KMS, a certificate authority, a secrets vault — is itself software that needs securing, patching, and access-controlling. It’s the same point made about
doasvssudoin the Ebola post: every extra line of infrastructure is another place for something to go wrong.
You haven’t eliminated the attack surface. You’ve moved it, concentrated it, and in the case of a lost key, made recovery from your own security control indistinguishable from recovery from an actual attack.
4. The Trade-off, Restated
Put the three points together and the pattern is the same one from the airport analogy, just run in reverse. Security in the classical sense — the ability to observe, inspect, and verify — depends on visibility. Privacy depends on the absence of it. Encryption is a very effective privacy tool precisely because it removes visibility, which means it is, by the same mechanism, removing a security capability for everyone who would otherwise have had it — including you, defending your own systems.
None of this is an argument for less encryption. It’s an argument for knowing exactly what you bought when you turned it on: privacy from observation, not automatically security from harm, and definitely not a substitute for the containment, monitoring, and key-management discipline that has to sit around it.
Outlook: Encrypt the Secret, Not the Fact
If blanket encryption trades away visibility, the fix isn’t “encrypt less” — it’s “encrypt more precisely.” Most of the blindness described above comes from treating the whole message as the secret, when usually only part of it actually is.
Take a credit card number. There’s a real difference between two claims:
- “This field contains a credit card number.”
- “The credit card number is 4111 1111 1111 1111.”
The first is metadata. Admitting it costs you almost nothing — it tells a fraud system, a firewall, or a PCI auditor what kind of data they’re looking at, which is exactly the context they need to apply the right rule. The second is the secret. That’s the only part that actually needs to be unreadable. Format-preserving encryption and tokenization exist specifically to make this split practical: the field still looks like a card number — same length, same shape — so downstream systems, validation, and routing keep working, but the value itself is protected. You get privacy for the number and security visibility for the fact that a number is there.
The same principle scales up:
- Selective/field-level encryption instead of blanket opacity. Encrypt the payload that’s actually sensitive; leave structural metadata (message type, size class, destination category) inspectable. This is most of what “blind defenders” actually needs solved — you don’t need to read someone’s private message to know it is a private message and route/rate-limit/log it accordingly.
- Traffic analysis without decryption. JA3/JA4 TLS fingerprinting, timing and size analysis, and destination reputation can catch a lot of C2 and exfiltration behavior without ever touching plaintext. It’s not a full replacement for content inspection, but it closes part of the gap TLS opened without reintroducing a man-in-the-middle.
- Narrow, accountable TLS inspection over blanket MITM. If you do need content inspection, scope it — specific destinations, specific data classes, with the interception itself logged and audited — rather than terminating and re-encrypting everything by default.
- Split and threshold key management. Shamir’s Secret Sharing, threshold cryptography, and HSM-backed keys turn “one lost key = permanent data loss” into “several independent parties have to cooperate, or several backups have to fail, before that happens.” It doesn’t remove the key-management attack surface, but it removes the single point of failure sitting inside it.
- Restore drills, not just backup jobs. If “encrypted” is going to stay on the compliance checklist, “restore tested last quarter” should be sitting right next to it.
None of these are exotic. They’re the same containment instinct as the rest of this blog, applied one layer down: don’t seal the whole room when sealing the one dangerous shelf would do the job — and still let you see what’s on every other shelf.
Related Content
Full Containment? Do We Have to Treat Software Like Ebola?
Zero Trust Architecture – Overview