The facts around Zoom and encryption for meetings/webinars • Hacker News Board

Re: The facts around Zoom and encryption for meetings/webinars

#141

Post by ironmagma » Sun, Apr 05, 2020, 1:29 AM UTC

paul_f wrote: post #135

CivBase wrote: post #48

> While we never intended to deceive any of our customers, we recognize that there is a discrepancy between the commonly accepted definition of end-to-end encryption and how we were using it. So you knew that your users would misinterpret the term "end-to-end encryption" but chose to use it anyways. And you somehow expect us to believe you "never intended to deceive any of [your] customers"? > The goal of our encrypt…

I don't agree there is a common definition of end-to-end encryption. Ask a random, non-technical co-worker what they think it means and you might get an answer that matches Zoom's marketing claims.

Since it’s a technical term being used to communicate technical information, it really doesn’t matter what a nontechnical person would think it means.

Re: The facts around Zoom and encryption for meetings/webinars

#142

Post by 0xy » Mon, Apr 06, 2020, 4:44 AM UTC

tptacek wrote: post #118

0xy wrote: post #114

Earlier quoted context omitted.

This statement is simply false, Telegram has never claimed group chats are "end-to-end encrypted". Only secret chats are claimed to be and proven to be. https://telegram.org/faq#q-so-how-do-you-encrypt-data As early as 2017, they broadly and publicly advertised that they are NOT end-to-end encrypted 'by default'. https://telegra.ph/Why-Isnt-Telegram-End-to-End-Encrypted-by...

Your refutation of my claim is an article that claims Telegram's use of TLS encryption makes it more secure than its competitors, and links to another article going into even more detail about that ridiculous claim. I feel comfortable with where it leaves my argument standing.

The central point of your comment was false and invented. You have claimed they made assertions they absolutely never made.

I don't see how the TLS claim is relevant, your comment is still wrong. It also misrepresents their argument, that competitors using cloud backup is less secure than not doing so because it introduces a very untrusted third party (Google Drive is not E2EE).

Their claim that E2EE + Google Drive backup is not secure seems pretty valid to me, not that it's related to the inaccuracy of your comment (it's still a false statement, and pretty egregious considering it's never been claimed).

Why are you putting words in their mouth?

Re: The facts around Zoom and encryption for meetings/webinars

#143

Post by rjmunro » Thu, Apr 09, 2020, 11:11 AM UTC

geofft wrote: post #24

tptacek wrote: post #17

If this pisses you off, it's worth noting that Telegram group chats have the same property, and that Telegram argues forcefully (and falsely) that what they're doing does meet the definition of "end-to-end encryption".

Wait, I thought Telegram was worse than that - Zoom does (what appears to be) end-to-end encryption if you have four native Zoom clients in a meeting. Telegram doesn't do end-to-end if you have four Telegram clients in a group chat, right? (I might be missing something about either Zoom or Telegram)

Zoom does not do end-to-end encryption. End to end encryption means that only the end user can decrypt the message. Zoom central can decrypt the message, because they hold the keys. They mostly don't bother, but that's just an optimisation.

At any point, someone could go into Zoom's systems, get the keys to your chat, and monitor you, and you would have no way of knowing.

Re: The facts around Zoom and encryption for meetings/webinars

#144

Post by rjmunro » Thu, Apr 09, 2020, 11:58 AM UTC

CivBase wrote: post #138

paul_f wrote: post #135

Earlier quoted context omitted.

I don't agree there is a common definition of end-to-end encryption. Ask a random, non-technical co-worker what they think it means and you might get an answer that matches Zoom's marketing claims.

I feel like "end-to-end encryption" is a mostly self-explanatory term. All data passed from one end to the other is encrypted. The point of encryption is to ensure that third parties cannot read your data. If a third party has the power to decrypt and read the data, then it's already misleading to advertise it as "encrypted". That would be like advertising a pair of boots as "waterproof" when they only actually preve…

But that's not the question here. That's only talking about when there is a connector involved. For a zoom-zoom only chat, if my encryption works by:

* I generate a key * I give it to you and another party * You and the other party then chat through my service * I pass the messages between you but don't bother to decrypt them

Does that count as end-to-end encryption? At any time, I could decide to decrypt the message (even months later if it is logged).

Re: The facts around Zoom and encryption for meetings/webinars

#145

Post by jcrawfordor » Sun, Apr 12, 2020, 8:32 PM UTC

liuliu wrote: post #27

jcrawfordor wrote: post #23

Earlier quoted context omitted.

The connectors appear in the participant list - this is a pretty common architecture for all kinds of communications bridging solutions. When someone joins a meeting by phone, Zoom spins up a service that 'assumes the identity' of that phone user to join the meeting (incl. negotiating keys). So, the Zoom service is now a participant in the meeting, but you do know that since a user appears in the participant list. I…

Thanks, that makes sense. I am not familiar with Zoom the product to know the connectors show up in participant list. I think even if proper e2e channel established, without authentication (Zoom just allows you to join any meeting with a token, like every other Hangout product), the key exchanges with other participants will be very automated. There seems to be very limited security guarantee if anyone can send you a…

Right, and this is kind of the key problem that Zoom is having to solve right now. The only material you (used to) need to know to join a meeting was a 9-ish digit meeting ID, and since that meeting ID entitles you to negotiate keys, it more or less nullifies encryption guarantees (except the post-hoc guarantee of the meeting host being able to see if something was up).

I would point out that this is in no way unique to Zoom, though. In fact, after the changes Zoom made in response to all of these issues, Zoom probably has the highest by-default level of meeting security of just about any product out there.