Live data from Hacker News

The facts around Zoom and encryption for meetings/webinars

blog.zoom.us

71–80 of 145 posts

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

#72
post #64

Earlier quoted context omitted.

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.

Fair point on the FAQ. At least they didn't explicitly misuse the term "end-to-end"?

That being said, I'm not certain encryption is an entirely solved problem for the case of multiple devices, including web clients, or for large public groups. (WhatsApp only supports a single client -- their web interface attaches to the phone -- and their group chats are limited to 256 members.) I'm not sure it can be solved under the current model Telegram uses for authorizing devices, as the server can authorize a device to access an account, and any non-secret chats it was involved in, without the involvement of any previously signed-in devices.

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

#73

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…

> How could they guarantee end-to-end if not all gadgets support encryption?! That question could be similarly applied to any company that has made an outlandish claim. And it would not change the fact that one could create a set of companies known to have made outlandish claims. Zoom was clearly part of that set. They are now removing themselves from that set by admitting that marketing used a novel definition of a…

It doesn't seem a stretch goal to make it clear to organisers and participants that joining encryption-incapable clients downgrades the confidentiality of the meeting.

Basically Zoom is just using sophistry to avoid being straight forward about limitations, which reinforces my poor opinion of them.

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

#74
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.

Is the end to end encryption removed for all clients when a legacy device connects? I don't understand how some devices could be end to end encrypted in a meeting while some legacy devices in the same meeting are not. How could the legacy devices send and receive to the encrypted clients?

It is possible if you think about it beforehand -- genrally you use a tone and/or a visual indicator to show that a transmission is in the clear (unencrypted). Other clients can then have a mechanism to allow speaking in the clear (sometimes requiring PTT -- press to talk). When encrypted transmission is ongoing, the gateway to the encrypted net may output a 'talk tone' that indicates the channel is busy. In this way a low grade client can join the conference, but they hear nothing but beeps (for a pure voice circuit) or see a busy indicator (for IP circuits) until someone wants to talk to them. When they talk, it is unencrypted till it reaches a gateway, after which it is either encrypted with the gateway key or passed unencrypted. (For radio broadcasts you just hear crackle or nothing.)

Obviously for un-trained users you often have the problem where someone transmits encrypted when they meant to talk in the clear, and vice versa. This is the reason for the 'plaintext' or 'ciphertext' side tones. If someone starts talking in the clear when they should not, another participant may choose to transmit over them, known as stepping on their transmission.

None of this requires there be a group key known by a central server.

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

#75
post #68
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.

So which of the two is it? A shared secret key among all clients, or individual keys per client. If its the latter, which would be smart, this line is a lie:

"...and do not decrypt it at any point before it reaches the receiving clients"

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

#76
post #30

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…

> How could they guarantee end-to-end if not all gadgets support encryption?! They can't. So they shouldn't. > In light of this post it looks like for the majority of users it is end-to-end encrypted. It absolutely is not. What they can say is for the vast majority of users, the streams are encrypted between all clients, and due to policy, Zoom won't view them as they pass through. The problem is Zoom could intercept…

Their ability to do so is no different than anyone else's. They are literally running a client that is set up in their cloud.

This is the intrinsic contradiction of meeting software. Once you're in the meeting, the whole point is that you have access to the content. If you don't want zoom to have access to your content, don't invite them to your meeting.

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

#77
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…

How do iMessage and FaceTime provide end-to-end encryption? Is there a public key associated with Apple account? How does my private key get on different Apple devices without my help?

>Is there a public key associated with Apple account

with each device

https://manuals.info.apple.com/MANUALS/1000/MA1902/en_US/app...

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

#78
post #75
post #68

Earlier quoted context omitted.

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

So which of the two is it? A shared secret key among all clients, or individual keys per client. If its the latter, which would be smart, this line is a lie: "...and do not decrypt it at any point before it reaches the receiving clients"

It doesn't make sense to encrypt the traffic differently for the individual users, since you would need to send multiple copies of the stream if the server can't do it (which is also a big downside of all the P2P solutions). It's not smart design for large-scale video chat.

A shared key or different keys per sender (which I don't think adds anything, but I might be missing something) both do not require the server to decrypt/reencrypt, and thus fairly sure that's what they are doing if this is anywhere close to accurate.

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

#80
post #78
post #75

Earlier quoted context omitted.

So which of the two is it? A shared secret key among all clients, or individual keys per client. If its the latter, which would be smart, this line is a lie: "...and do not decrypt it at any point before it reaches the receiving clients"

It doesn't make sense to encrypt the traffic differently for the individual users, since you would need to send multiple copies of the stream if the server can't do it (which is also a big downside of all the P2P solutions). It's not smart design for large-scale video chat. A shared key or different keys per sender (which I don't think adds anything, but I might be missing something) both do not require the server to…

WebRTC SFUs encrypt traffic differently to the individual users. Each outgoing packet needs to be encrypted with the receiver's negotiated keys, is my understanding. If it was a shared key, then presumably that key could be negotiated among the peers using public key exchange, unbeknownst to the server, and then all traffic be e2e encrypted, which it isn't. I have minimal understanding of what protocols Zoom uses out of the box, but if they don't support e2e encryption, it seems to me they need the keys on the servers for a reason, and the only legit reason would be to trans-crypt the packets.
Post reply on HN