Live data from Hacker News

The facts around Zoom and encryption for meetings/webinars

blog.zoom.us

91–100 of 145 posts

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

#91
post #42

Earlier quoted context omitted.

I understood they never had it for video. Which was included in their claim. So there's that.

OK, that would be serious flaw, and also the current blog post states clearly that they do, so if that's a lie, then we have a much bigger problem on our hands than whether they should be using the term "end-to-end encryption." > To be clear, in a meeting where all of the participants are using Zoom clients, and the meeting is not being recorded, we encrypt all video, audio, screen sharing, and chat content at the se…

Well, it says they "do not decrypt it" not that they "cannot decrypt it".

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

#92
post #40

Earlier quoted context omitted.

I'm not sure what to do with systems like iMessage/FaceTime under this definition, where the server doesn't hold the private keys but also the client provides no means to check fingerprints out-of-band. In these systems, the server could MITM the clients to each other and thereby snoop on client communications with the same effective result as Zoom/Jitsi. (These systems also generally support changing the peer's fing…

You appear to also realise that if it's a closed source client then the server could be fine, the client could do all the snooping and pass data in a side channel. It's worth spelling that out IMO.

Even worse, the same could happen if it's an open source client!

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

#93
post #29

Zoom! What are you doing?! > To be clear, in a meeting where all of the participants are using Zoom clients, and the meeting is not being recorded, we encrypt all video, audio, screen sharing, and chat content at the sending client, and do not decrypt it at any point before it reaches the receiving clients. That is still not what "end-to-end encryption" means. From wikipedia[1]: > End-to-end encryption (E2EE) is a sy…

What I understand from that statement is that the data travels encrypted and each client does the encryption/decryption duty, not that they are able to decrypt the data at any point but decide not to.

I guess that using "we" in their statement is a tad misleading and can make people arrive at conclusions.

But that's just my point of view, it could still mean they can decrypt at any point.

EDIT: Someone else made the point of the other channels that do not support Zoom's encryption. I read about it in the article but I did not put two and two together. I guess I spoke too soon, seems Zoom can decrypt data at will after all.

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

#94

How could they guarantee end-to-end if not all gadgets support encryption?! Let's demand end-to-end encryption for people connecting via FAX machines to read only the comments. Of course connecting via unreliable machines / protocols means Zoom must have some bridge on their side somewhere. In light of this post it looks like for the majority of users it is end-to-end encrypted. I don't even use Zoom, but really, the…

What are you talking about? What devices that support Zoom don't support encryption?

Does Zoom work on fax machines?

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

#95
post #29

Zoom! What are you doing?! > To be clear, in a meeting where all of the participants are using Zoom clients, and the meeting is not being recorded, we encrypt all video, audio, screen sharing, and chat content at the sending client, and do not decrypt it at any point before it reaches the receiving clients. That is still not what "end-to-end encryption" means. From wikipedia[1]: > End-to-end encryption (E2EE) is a sy…

> The fact that it's possible to decrypt is what makes this not "end-to-end encryption". By that definition, iMessage is also not end-to-end encrypted because Apple can decrypt the messages due to controlling the key servers and the relay servers, but few people bat an eye when Apple claims iMessage is end-to-end encrypted on its privacy marketing page. https://blog.cryptographyengineering.com/2013/06/26/can-appl...…

No, Apple cannot decrypt iMessage or FaceTime traffic because they don't have the keys.

Apple could silently add an extra recipient for whom they do have the keys, but that is out of scope for E2E (in other words, key distribution is out of scope).

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

#96

Earlier quoted context omitted.

> The fact that it's possible to decrypt is what makes this not "end-to-end encryption". By that definition, iMessage is also not end-to-end encrypted because Apple can decrypt the messages due to controlling the key servers and the relay servers, but few people bat an eye when Apple claims iMessage is end-to-end encrypted on its privacy marketing page. https://blog.cryptographyengineering.com/2013/06/26/can-appl...…

Oh, come on, that’s not the same thing at all. Here Zoom actively decrypts the stream so that it’s compatible with non-Zoom clients and then advertises it as end-to-end, a fault in the protocol itself, while you’re comparing it to (outdated, FYI) information where Apple could possibly decrypt messages if they sent out fake keys.

It's not outdated; Apple still controls the key distribution and the users cannot verify how many recipient key sets there are.

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

#97
post #29

Zoom! What are you doing?! > To be clear, in a meeting where all of the participants are using Zoom clients, and the meeting is not being recorded, we encrypt all video, audio, screen sharing, and chat content at the sending client, and do not decrypt it at any point before it reaches the receiving clients. That is still not what "end-to-end encryption" means. From wikipedia[1]: > End-to-end encryption (E2EE) is a sy…

What I understand from that statement is that the data travels encrypted and each client does the encryption/decryption duty, not that they are able to decrypt the data at any point but decide not to. I guess that using "we" in their statement is a tad misleading and can make people arrive at conclusions. But that's just my point of view, it could still mean they can decrypt at any point. EDIT: Someone else made the…

> What I understand from that statement is that the data travels encrypted and each client does the encryption/decryption duty, not that they are able to decrypt the data at any point but decide not to.

Those two things are not mutually exclusive. It reads to me like they are implicitly acknowledging that client-side "private" security keys aren't really private but are also stored elsewhere in Zoom's system.

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

#98

Earlier quoted context omitted.

Oh, come on, that’s not the same thing at all. Here Zoom actively decrypts the stream so that it’s compatible with non-Zoom clients and then advertises it as end-to-end, a fault in the protocol itself, while you’re comparing it to (outdated, FYI) information where Apple could possibly decrypt messages if they sent out fake keys.

It's not outdated; Apple still controls the key distribution and the users cannot verify how many recipient key sets there are.

For one, iMessage (and FaceTime) will now tell you if a new device is added.

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

#99
post #35

Earlier quoted context omitted.

> Zoom marketed end-to-end encryption. They didn't have end-to-end encryption. My understanding is that they do in fact have end-to-end-encryption between Zoom clients, it's just that when you join via a dial-in phone number, the connection is (of course) not encrypted between your phone and the system you're dialing into. People who wanted end-to-end encryption could just choose to not dial in by phone, and they'd g…

> My understanding is that they do in fact have end-to-end-encryption between Zoom clients, it's just that when you join via a dial-in phone number, the connection is (of course) not encrypted between your phone and the system you're dialing into. Which means, there is no end-to-end-encryption. Zoom knows the key but does not decrypt the data unless they need to to let a member join via phone. You need to trust Zoom…

How is that meaningfully different from a system like Signal or iMessage where you need to trust Zoom that when they say "this is Bob's fingerprint" they're actually giving you Bob's fingerprint and not their MITM key? They still need to keep their promise, there still is no technical hurdle.

(Signal gives you the option to verify fingerprints out-of-band but their UI discourages using it; iMessage doesn't even do that. I mean, maybe the answer is we collectively decide to stop calling iMessage end-to-end-encrypted....)

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

#100
post #91
post #42

Earlier quoted context omitted.

OK, that would be serious flaw, and also the current blog post states clearly that they do, so if that's a lie, then we have a much bigger problem on our hands than whether they should be using the term "end-to-end encryption." > To be clear, in a meeting where all of the participants are using Zoom clients, and the meeting is not being recorded, we encrypt all video, audio, screen sharing, and chat content at the se…

Well, it says they "do not decrypt it" not that they "cannot decrypt it".

Sure, but they're making a claim that they cannot decrypt it without you noticing. If a Zoom employee wants to monitor your call, they'll show up as a participant. If you have a 5-person meeting and nobody is joined by phone, and there are 5 people on the call plus one phone bridge, you know some eavesdropper (perhaps Zoom, perhaps someone who's good at guessing conference IDs) has joined.

(I would hope their system is architected in such a way that clients enforce this and do not trust the server for the participant list. If they don't, then I'd take issue with that part of their blog post. But also I'd argue that in practice systems like Signal or iMessage can MITM your traffic if you really want, so I'm not convinced this is meaningfully worse for users even so....)

Post reply on HN