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

81–90 of 145 posts

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

#81

Post by [deleted] »

gfodor wrote: post #80
detaro wrote: post #78

Earlier quoted context omitted.

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…

[deleted]

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

#82

Post by angry_octet »

tommoor wrote: post #28
softwaredoug wrote: post #20

Is there any evidence that other teleconferencing solutions meet or exceed what's described in this blog article? I just find the Zoom hate weird. We have no reason to think Teams, Hangouts, or anything else does anything close to or better than this. Lots of reason to suspect they probably don't. Don't get me wrong, I think the scrutiny is good, and will lead to positive outcomes. But we probably need to scrutinize…

The video must be decrypted to do the scaling, transcoding, and dynamic bitrate adjustment for different platforms and network speeds – there's no way around this. All of the group video providers will be decoding video on the server to achieve the reliability everyone wants.

The clients can dynamically adjust their sending rate and resolution. It is pretty easy to downgrade your video when not talking. Its also possible to number and label the encrypted frames (I frames or B frames), allowing decimation for low bandwidth clients without recoding, which is expensive and slow.

There are also ways to send additive resolution streams -- a base stream and additional detail layers (multiresolution like JPEG2000).

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

#83

Post by [deleted] »

gfodor wrote: post #80
detaro wrote: post #78

Earlier quoted context omitted.

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…

[deleted]

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

#84

Post by angry_octet »

president wrote: post #47

So essentially any time a Zoom Connector is involved, Zoom has access to the meeting contents since they own the keys. It would be interesting then to know what percentage of all Zoom calls involve a Connector.

Who says there is not an invisible Connector? They have the keys.

You have to assume every Zoom call is recorded by Zoom.

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

#85

Post by detaro »

gfodor wrote: post #80
detaro wrote: post #78

Earlier quoted context omitted.

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…

It's a lot easier to implement central key management than a fully e2e system, especially if they do need the key for many meetings anyway on some of their systems.

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

#86

Post by [deleted] »

netsharc wrote: post #38
prophesi wrote: post #7

"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. 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." In other words, "We deceived our customers with false advertising but we'…

Oh fucking hell, that corporate bullshit. If my non-existant wife catches me snorting coke out of a stripper's ass I'm going to say "I recognize that there's a discrepancy between the commonly accepted definition of marriage fidelity and how I'm using it."

[deleted]

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

#87

Post by cameldrv »

cbsmith wrote: post #76
gregmac wrote: post #30

Earlier quoted context omitted.

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

It's possible to do E2E encryption even with a web client. The endpoints exchange keys, possibly with certificates that validate who is on the other end, and then the web client encrypts the stream and sends it either directly to the other endpoint or to a Zoom server, which relays it but doesn't possess the decryption key. Their statements are pretty vague, but my impression is that Zoom servers decrypt the stream and then reencrypt it. That is not end to end encryption, in fact, the specific difference between normal TLS type encryption and end to end is that the server has no ability to decrypt the traffic.

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

#88

Post by dmitrygr »

detaro wrote: post #79
dmitrygr wrote: post #71

"Zoom has never built a mechanism to decrypt live meetings for lawful intercept purposes" Is this a lie or have they not heard of CALEA?

Are they classified as something falling under CALEA?

yes: https://apps.fcc.gov/edocs_public/attachmatch/FCC-06-56A1.pd...

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

#89

Post by lern_too_spel »

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…

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

https://www.apple.com/privacy/features/

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

#90

Post by saagarjha »

lern_too_spel wrote: post #89
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…

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