[ethbr1]

> TLS works the same way.

TLS does not use emphemeral keys, from a practical live connection perspective, because the root of trust is established via chaining up to a trusted root key.

Ergo, there are a set of root keys that, if compromised, topple the entire house of cards by enabling masquerading as the endpoint and proxying requests to it.

And that's exactly the problem you're gripping about with regards to a tap system. One key to rule them all.

[DexesTTP]

Hacking the root certificates of TLS doesn't allow you to read every TLS-encrypted conversation ever, thankfully. It just allows you to set up a MITM attack that looks legit. And sure, that is bad, but it's not "immediately makes everything readable" bad.

That's why I call TLS keys "ephemeral" under this threat model.

The goal of anti-E2E legislation isn't to be able to MITM a conversation - again, government agencies can already set that up with the current protocols fairly easily. The goal of the legislation is to make it so that, "with the correct keys that only the good guys have", you can decrypt any past message you want that was already sent using the messaging system, without needing access to either device.

If the governments only settled with an "active tap system" that works like a MITM for e2e encrypted channels, we wouldn't be having this discussion or we wouldn't be talking about new regulations. Because again, that is already possible, and governments are already doing it.

[ethbr1]

That's why I put the live caveat. Granted, decryption of previously recorded conversations and decryption of new conversations are two different threat models.

Out of curiosity, can MITM of new connections be set up fairly easily with current protocols? (let's say TLS / web cert PKI and Telegram)

For the TLS case, they'd need to forge a cert for the other end and serve it to a targeted user. Anything broader would risk being picked up by cert transparency logs. Which limits the attack capability to targeted, small-scale and requires control of key internet routing infrastructure? Not ideal, but at least we're limiting mass continuous surveillance.

For Telegram, the initiation is via DH [0] and rekeyed every 100 messages or calendar week, whichever comes first, with interactive key visualization on the initial key exchange [1]. That seems a lot harder to break.

[0] https://core.telegram.org/api/end-to-end

[1] https://core.telegram.org/api/end-to-end/pfs#key-visualizati...

[EGreg]

And not just TLS and certificate authorities but also DNSSEC. Still, it is pretty worrying to have one CA like letsencrypt be behind so many sites, or seven people behind DNSSEC:

https://www.icann.org/en/blogs/details/the-problem-with-the-...

But here is how they protect it:

https://www.iana.org/dnssec/ceremonies

On the other hand, data is routinely stored in centralized databases and they are constantly hacked:

https://qbix.com/blog/2023/06/12/no-way-to-prevent-this-says...