Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The facts around Zoom and encryption for meetings/webinars

blog.zoom.us

Post reply on HN
Print view View original

61–70 of 145 posts

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

#61

Post by lukevp »

close04 wrote: post #59
lukevp wrote: post #53

Earlier quoted context omitted.

The spirit of encryption? What does that mean? End to end encrypted means from one client through all networks and servers to the other client, no one can decrypt the traffic. Anything besides that is not end to end.

It means nothing but this is what Zoom tells us we have. Encryption given "in the spirit" of their intentions. > Zoom has always strived to use encryption to protect content in as many scenarios as possible, and in that spirit, we used the term end-to-end encryption.

Oh, I missed your sarcasm originally. I agree that it’s meaningless.

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

#62

Post by duskwuff »

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)

Telegram only uses end-to-end encryption for "secret chats" and voice calls. Group chats and standard person-to-person chats are not end-to-end encrypted, and I don't believe Telegram has made any claims to the contrary.

(Encrypted messaging is a hard problem, especially when you have to deal with users with multiple devices which are offline intermittently, or users joining an established group chat. Telegram has taken the sensible approach of not trying to solve this.)

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

#63

Post by kreetx »

gregmac wrote: 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…

This. They really should look into what end-to-end encryption means.

As the parent says, they can implement their app however they please, but they should get their feature list straight.

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

#64

Post by tptacek »

duskwuff wrote: post #62
geofft wrote: post #24

Earlier quoted context omitted.

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)

Telegram only uses end-to-end encryption for "secret chats" and voice calls. Group chats and standard person-to-person chats are not end-to-end encrypted, and I don't believe Telegram has made any claims to the contrary. (Encrypted messaging is a hard problem, especially when you have to deal with users with multiple devices which are offline intermittently, or users joining an established group chat. Telegram has ta…

Encrypted messaging is a solved problem, and even WhatsApp manages end-to-end group chats. Telegram does not, but claims in its FAQ that "All Telegram messages are always securely encrypted" (it is referring explicitly to group messaging). Telegram is far more misleading than Zoom is, but again, Zoom lacks the cheering section. Maybe if they released a ZoomCoin.

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

#65

Post by jiqiren »

hedora wrote: post #13

In fairness, it sounds like it’s end to end encrypted until a legacy device connects. Am I misunderstanding something? This doesn’t seem like it should be controversial.

you're missing the fact they manage all the keys. So it isn't E2E encryption... Each client should generate their own key and exchange it with all the other clients directly. Zoom is collecting all the keys in their cloud.

Their blog post even says if zoom managing keys isn't good security for enterprise - they will have a new product (soon?) to host the keys in an enterprises DC instead.

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

#66

Post by TwoBit »

kreetx wrote: post #63
gregmac wrote: 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…

This. They really should look into what end-to-end encryption means. As the parent says, they can implement their app however they please, but they should get their feature list straight.

Zoom knows exactly what end-to-end encryption means, and always has. Most likely their marketing group didn't like their engineering group telling them this nice buzzword didn't apply and intentionally chose to misuse it.

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

#67

Post by gfodor »

If Zoom literally doesn't decrypt the packets in flight to re-encrypt them, it means they don't have peerwise keys for each client. So (as a non-expert) they're either now lying about something else (and in fact, the data is decrypted on the server temporarily in memory, and re-encrypted for each peer using a distinct key, akin to a WebRTC SFU) or there's a shared secret key between all clients, which is a major security deficiency.

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

#68

Post by detaro »

gfodor wrote: post #67

If Zoom literally doesn't decrypt the packets in flight to re-encrypt them, it means they don't have peerwise keys for each client. So (as a non-expert) they're either now lying about something else (and in fact, the data is decrypted on the server temporarily in memory, and re-encrypted for each peer using a distinct key, akin to a WebRTC SFU) or there's a shared secret key between all clients, which is a major secu…

The article specifically states that they coordinate the key through their servers.

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

#69

Post by sweeneyrod »

geofft wrote: post #34
tptacek wrote: post #26

Earlier quoted context omitted.

I think you're right! I'm more interested in the double standard (and the dynamics of a pile-on) than the details.

Yeah, I'm honestly a bit surprised because I personally would agree with Zoom that what they're doing is "end-to-end encryption." (Maybe it'd be nice if they had a "mandatory e2e" checkbox that you had to uncheck to get a dial-in phone number, but, obviously when I call a number by phone I know there's no e2e going on.) I think the pile-on is mostly because finding security problems with Zoom is the cool new thing to…

If what Zoom is doing in the first diagram is end-to-end encryption, what would non-e2e encryption for that set up look like?

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

#70

Post by pbhjpbhj »

geofft wrote: post #40
f38zf5vdt wrote: post #25

Earlier quoted context omitted.

When a product specifies "end to end encryption" my expectation is that the only function of the server is to pass the public keys from two clients around so they can Diffie-Hellman kx to achieve a mutually shared private key to encrypt their communications to each other, so that information flow is: client client (no server knowledge of communications aside from the encrypted packets being passed back end forth) Not…

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.
Post reply on HN