3 ms·

The standard threat model for secure messaging does assume a potentially compromised provider.. that’s exactly why the client-trust issue matters. If the provi

by dijit 1y ago

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.

tptacek 1y ago
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.
- dijit 1y ago
  Re: Slack; yeah, that’s not apples-to-apples for secure 1:1 messaging (it’s enterprise group chat with admins often having god-mode access anyway). A better comp might be old-school Skype pre-Microsoft: client-server backbone (after ditching full P2P), tight client/network control, no E2EE, yet no major leaks despite heavy scrutiny. It worked for millions in a “good enough” threat model without pretending to be bulletproof. Secure messaging apps that default to client-server (like Telegram’s non-secret chats) are similar. They pay lip service to groups but prioritise 1:1, and the security theatre of optional E2EE doesn’t change the core trust calculus. If you don’t trust the provider, don’t trust their code. Simple as.
  - tptacek 1y ago
    The security model of Telegram is essentially that of Slack, plus a seldom-used direct E2EE messenger. You literally can't trust Slack or Telegram. You can opt not to trust Signal; I don't care. But it's at least an option.
    - dijit 1y ago
      Nice try sneaking Slack into a 1:1 secure messaging debate… That’s like comparing a corporate chatroom (with admin access) to a personal diary. Telegram’s client-server default, with optional E2EE, is closer to pre-Microsoft Skype: tight client/network control, 1:1 focus, no major leaks despite a major spotlight on it for a decade+ You dodged Skype because it’s not the piñata Slack is. Weak move.
      - tptacek 1y ago
        That's exactly the security model of Telegram. If you want to say "Skype", fine, Skype is also not a trustable secure messenger. I think we've reached an agreement. Honestly pretty satisfying, I've never managed to drive an argument about Telegram being OK all the way to "Telegram is just as good as Skype".
        dijit 1y ago
        You’re always so quick to call Signal the gold standard, but in reality, it’s not the untouchable system you claim. I’d trust pre-Microsoft Skype, Telegram, and Signal about the same; none are bulletproof when the provider controls both client and server. That’s the real crux, and you’re glossing over it. Skype pre-2011 ran TLS and encrypted storage, held up under global scrutiny with no major leaks, and matched Telegram’s client-server model with optional E2EE. Post-Microsoft? it got gutted: NSA’s PRISM, Chinese eavesdropping, Mac OS X backdoors, the works. This proves my point: when client and server are under one roof, a compromise, hack or coercion becomes possible. Signal’s Double Ratchet E2EE, that locks down past and future messages against server breaches and its open-source code plus reproducible builds invite scrutiny that makes backdoors harder to hide, but here’s the truth: Signal’s client and server are still one entity and they have hid updates from users before. A malicious update, pushed via TOLA or CLOUD Act pressure, can snag plaintext before encryption, E2EE be damned. Most users don’t verify builds. Transparency’s nice, but it’s not a forcefield. Telegram’s optional E2EE and Skype’s old-school TLS setup aren’t inherently worse for low-threat users who just need protection from external hacks, not state-level malice. You’re waving Signal’s flag like it’s untouchable, but in practice, the provider’s grip on the client levels the playing field. That’s why I stick to OMEMO or OTR over XMPP or IRC: decentralised, battle-tested protocols that don’t chain me to one entity’s whims. I run them myself, no middleman, no trust roulette. Your “agreement” smells like a victory lap, but you’re dodging the real issue: single-entity control is the Achilles’ heel, not the protocol’s name.

by dijit 1y ago

tptacek 1y ago

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.

dijit 1y ago
Re: Slack; yeah, that’s not apples-to-apples for secure 1:1 messaging (it’s enterprise group chat with admins often having god-mode access anyway). A better comp might be old-school Skype pre-Microsoft: client-server backbone (after ditching full P2P), tight client/network control, no E2EE, yet no major leaks despite heavy scrutiny. It worked for millions in a “good enough” threat model without pretending to be bulletproof. Secure messaging apps that default to client-server (like Telegram’s non-secret chats) are similar. They pay lip service to groups but prioritise 1:1, and the security theatre of optional E2EE doesn’t change the core trust calculus. If you don’t trust the provider, don’t trust their code. Simple as.
- tptacek 1y ago
  The security model of Telegram is essentially that of Slack, plus a seldom-used direct E2EE messenger. You literally can't trust Slack or Telegram. You can opt not to trust Signal; I don't care. But it's at least an option.
  - dijit 1y ago
    Nice try sneaking Slack into a 1:1 secure messaging debate… That’s like comparing a corporate chatroom (with admin access) to a personal diary. Telegram’s client-server default, with optional E2EE, is closer to pre-Microsoft Skype: tight client/network control, 1:1 focus, no major leaks despite a major spotlight on it for a decade+ You dodged Skype because it’s not the piñata Slack is. Weak move.
    - tptacek 1y ago
      That's exactly the security model of Telegram. If you want to say "Skype", fine, Skype is also not a trustable secure messenger. I think we've reached an agreement. Honestly pretty satisfying, I've never managed to drive an argument about Telegram being OK all the way to "Telegram is just as good as Skype".
      - dijit 1y ago
        You’re always so quick to call Signal the gold standard, but in reality, it’s not the untouchable system you claim. I’d trust pre-Microsoft Skype, Telegram, and Signal about the same; none are bulletproof when the provider controls both client and server. That’s the real crux, and you’re glossing over it. Skype pre-2011 ran TLS and encrypted storage, held up under global scrutiny with no major leaks, and matched Telegram’s client-server model with optional E2EE. Post-Microsoft? it got gutted: NSA’s PRISM, Chinese eavesdropping, Mac OS X backdoors, the works. This proves my point: when client and server are under one roof, a compromise, hack or coercion becomes possible. Signal’s Double Ratchet E2EE, that locks down past and future messages against server breaches and its open-source code plus reproducible builds invite scrutiny that makes backdoors harder to hide, but here’s the truth: Signal’s client and server are still one entity and they have hid updates from users before. A malicious update, pushed via TOLA or CLOUD Act pressure, can snag plaintext before encryption, E2EE be damned. Most users don’t verify builds. Transparency’s nice, but it’s not a forcefield. Telegram’s optional E2EE and Skype’s old-school TLS setup aren’t inherently worse for low-threat users who just need protection from external hacks, not state-level malice. You’re waving Signal’s flag like it’s untouchable, but in practice, the provider’s grip on the client levels the playing field. That’s why I stick to OMEMO or OTR over XMPP or IRC: decentralised, battle-tested protocols that don’t chain me to one entity’s whims. I run them myself, no middleman, no trust roulette. Your “agreement” smells like a victory lap, but you’re dodging the real issue: single-entity control is the Achilles’ heel, not the protocol’s name.