Hacker News Reader

Comment by kelnos | Hacker News Reader

Not sure why you're being downvoted, as I'm curious about that as well.

Your parent's description of the protocol makes it seem like the meeting host generates a key and sends it to Zoom so Zoom can send the key to the participants. I skimmed the whitepaper, though, and it seems what actually happens is the clients generate their own public/private keypairs, which allows the clients to negotiate session keys without exposing the keys to Zoom's server.

Of course since the client code is closed source, you just have to trust that it isn't sharing the session keys with Zoom or a third party. That's the same potential flaw as with something like WhatsApp's, Telegram's, or FB Messenger's E2EE mode: the app itself can intentionally break the security of the system, and you probably won't know it.

View on HN

The default mode is not E2EE. The same key is used by all participants and is distributed by Zoom's servers. In this mode, all features are available, including the ones that require a cloud service (like 1-800 number support).

If a meeting is set to E2EE, then a bunch of features are turned off and the keys come from the host* and are sent to the other attendees enveloped with their public keys. Zoom's infrastructure never sees the keys, only the encrypted content packets that are relayed to all the participants.

Agreed with the parent. Even if the above is true, what's to prevent Zoom from creating a quiet/phantom "extra participant" and never having the client UI tell you about it.

I mean, the entire premise of their service is that you're routing your communications through their super-powered intermediate proxy services. You're using their clients end-to-end and their servers in the middle. They can do whatever they want with any of those

Alex Stamos promised that they have no way to do this. https://web.archive.org/web/20200702200900/https://twitter.c... But the tweet has since been deleted.

The same that prevents Whatsapp from doing the same: trust.

Last time I checked, the entire client codebase of Telegram was open source, and encryption happens on the client.

Of course, all the metadata are visible to Telegram servers, because they handle authorization and discovery. But not the communication content.

What am I missing?

The new and shiny TelegramX client all of my friends are using is only available as closed source binary. Also their encryption is open, that's true, but they implemented their own algorithms with blackjack and hookers and noone is really sure how secure it really is iirc. Additionally, encrypted chats aren't even the default, single-end to single-end and not available on desktop.

I still use telegram because I deem it better than whatsapp, but the security sucks nonetheless.

Reply on news.ycombinator.com