Comment by dijit
1 day ago
That’s fair for a purely malicious provider in client/server mode (they’ve got the plaintext on the server, no fancy footwork needed), but that’s missing the forest: if the provider is adversarial, E2EE doesn’t magically fix it either. They control the client codebase and distribution (app stores, updates), so backdooring it to snag plaintext pre-encryption is trivial—it’s basically a built-in supply chain vuln they own.
Point is, E2EE only “protects” against server-side compromise if you assume the client is golden, which loops back to trusting the provider not to mess with it. If they’re bad actors, they can (and govts do compel them to) inject client-side leaks (again, see Australia’s TOLA Act forcing software mods), or historical cases like Lavabit’s key handover pressure.
In trusted-provider scenarios (which is most users’ reality), client/server + TLS + encrypted storage suffices against external threats, with less complexity than E2EE’s multi-device key mgmt headaches.
If distrust is total, bail! Because neither model’s your friend. Supply chain worries aren’t a distraction; they’re the real vector, as SolarWinds and Jia Tanning of xz remind us. E2EE’s great tech, but you are pretending that it is a cure-all, which ignores practical realities.
First, the setting for secure messaging cryptography assumes a compromised provider, so this is all entirely besides the point. But second, no, it's not exclusively a problem for a "purely malicious provider". It's also a problem for any provider that is compromised; a serverside compromise is completely fatal to the privacy of every user of a client-server-encrypted system.
There isn't an amount of hand-waving that's going to get you to a place where client-server-only encryption is sufficient for secure messaging.
I am also more concerned about supply chain attacks than I am about attacks on E2EE, generally. But that stops being true in the specific case of secure messaging.
The standard threat model for secure messaging does assume a potentially compromised provider.. that’s exactly why the client-trust issue matters.
If the provider is compromised (maliciously or via hack/subpoena), they can alter the client to capture data before E2EE engages, rendering it moot.
E2EE protects past messages from server-side access, sure, but it doesn’t prevent future compromises via client backdoors, which are a real vector under laws like Australia’s TOLA or US CLOUD Act, again: providers have been compelled to modify software (e.g., Lavabit’s resistance led to shutdown, but others comply quietly).
You’re right that client-server alone fails catastrophically on server compromise, but E2EE isn’t a panacea if the same actor controls the client supply chain.
Trust is binary: If you don’t trust the provider, don’t use their client. reproducible builds help a tiny fraction, but for most, it’s unverifiable.
In partial-trust scenarios (e.g., worrying about hacks but not full malice), client-server with distributed keys and TLS can suffice without E2EE’s complexities.
I’m hand-waving a bit here; but I’m talking about peoples actual realities, not some hypothetical.
How does E2EE hold up if a subpoena forces a silent client update? You won’t know, and history shows that’s the path of least resistance for adversaries.
Client supply chain is moot in the client-server setting. The attackers just target the server and get everything. You only get to raise the salience of the client supply chain when E2EE is already in place. Again: this is an analysis specific to secure messaging.
Slack isn't E2EE secure. The Slack client supply chain is not how I worry about my Slack message history being intercepted.
5 replies →