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

101–110 of 145 posts

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

#101

Post by lern_too_spel »

saagarjha wrote: post #90
lern_too_spel wrote: post #89

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.

> 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

I took issue with a specific definition that precludes both products. I didn't say that both products use the same protocol.

> you’re comparing it to (outdated, FYI) information

Has the implementation changed in any way that makes it meet the definition? No? Then the information is not outdated for our purposes.

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

#102

Post by lern_too_spel »

ThePowerOfFuet wrote: post #95
lern_too_spel wrote: post #89

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

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

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

They can very easily decrypt iMessage traffic using the method outlined in the article. They simply provide the sender with an erroneous key.

> key distribution is out of scope

Not according to GGP's definition, which didn't require merely that messages stay encrypted between endpoints but that middlemen have no way of decrypting the data.

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

#103

Post by geofft »

luckylion wrote: post #54
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)

> Zoom does (what appears to be) end-to-end encryption if you have four native Zoom clients in a meeting. I don't understand their blog post that way. From the post: 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 sounds like "we could decrypt it, but we promise not to". That's not e2e. They continue…

> if those users can join the meeting after it has been established between Zoom-clients, it's not e2e.

I don't think that follows.

First, it's absolutely possible to design an E2E system where users can join the meeting after it started: https://signal.org/blog/private-groups/

Second, you can have your phone gateways be stateless and unprivileged: when a user calls up the phone gateway, it generates a new keypair. The user enters their PIN and the phone gateway derives a key from the PIN using your favorite password hashing algorithm, HMACs their public key with the PIN, and sends it to the existing participants. The other participants have the same PIN, so they can decide to let this public key join the call without allowing random callers to join. (I'm not sure if Zoom does this, but it's straightforward enough and it makes the phone gateways much less juicy of an attack target, especially because you can now reboot the gateways from read-only media and you don't need to provision them a secret, so I hope they do.)

Now we're left with the argument about whether it really counts as "end-to-end" if the plain-old-telephone-system part of the connection isn't encrypted, but also it can't be, so I'm not sure anyone reasonably expected it to be encrypted. Anyone who really wants "end-to-end" encryption can just make sure nobody joins their call by phone. (In the end, end-to-end encryption is a tool to make sure the right people join your meeting - i.e., anyone who cares about end-to-end encryption already cares about who the ends are.)

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

#104

Post by saagarjha »

lern_too_spel wrote: post #101
saagarjha wrote: post #90

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.

> 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 I took issue with a specific definition that precludes both products. I didn't say that both products use the same protocol. > you’re comparing it to (outdated, FYI) information Has the implementation changed in any way that makes it meet the defini…

> I took issue with a specific definition that precludes both products.

This isn’t the first time you’ve tried to compare Zoom and iMessage; it’s just that I chose this one to respond to.

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

#106

Post by dandelo53 »

geofft wrote: post #35
JumpCrisscross wrote: post #33

Zoom marketed end-to-end encryption. They didn't have end-to-end encryption. Parroting the "we used the term differently" line is counterproductive. They need to acknowledge the problem, appoint the CEO as the spokesperson and over correct [1]. If Zoom's CEO publicly apologized for the lies, fixed their marketing copy and offered refunds to anyone who felt misled, this problem would go away. [1] https://www.youtube.c…

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

Inferring device does encryption, while silently allowing data leakage in complex ways that are beyond the typical consumer is deceptive at best.

It provides a very weak link to the entire claim of end-to-end.

Security minded knows that you also need attribution and chain of command. Your example of hopping through hoops is your own doing, which you are free to do on your own. For free. This product is provided as a SECURE means of communication and it IS NOT.

You are not an attractive target. That is ok, usually preferred. That is not the situation for everyone. However I bet someone will using Zoom is likely to be a person of influence in a major industry of organization that you have an interest in. With a target in mind, you now have a goal: Find a way to convince zoom to send encrypted comms to any device within reach. Note it doesn't mean you NEED a device to be dumb. You just need the smart device to convize Zooms servers that is is "dumb" (or a land line, fax machine, etc). Once convinced it will happily send the data onward.

This is the type of problem that will eventually be exploited in a major way if their mixed messaging is not curtailed. Suggesting otherwise is only kicking that can down a longer road, off a bigger ciff.

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

#107

Post by geofft »

dandelo53 wrote: post #106
geofft wrote: 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…

Inferring device does encryption, while silently allowing data leakage in complex ways that are beyond the typical consumer is deceptive at best. It provides a very weak link to the entire claim of end-to-end. Security minded knows that you also need attribution and chain of command. Your example of hopping through hoops is your own doing, which you are free to do on your own. For free. This product is provided as a…

> This product is provided as a SECURE means of communication and it IS NOT.

Are you claiming that there are actual customers who believed that if they called up a Zoom conference via a phone number, their connection would be encrypted from their landline phone all the way to the other end, and were surprised to learn it was not?

> With a target in mind, you now have a goal: Find a way to convince zoom to send encrypted comms to any device within reach.

This attack has nothing to do with end-to-end encryption (i.e., it is equally possible against systems that are well-accepted as "end-to-end encryption," so if you're using this as a criterion, nothing is end-to-end encrypted.)

That doesn't mean I don't think it's a problem. That just means I think that words have meanings, and "end-to-end encrypted" is not a synonym for "secure under the threat model I care about," and never has been, for anyone.

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

#108

Post by geofft »

wilg wrote: post #92
pbhjpbhj wrote: post #70

Earlier quoted context omitted.

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!

Right,

- if it's an open-source client but it doesn't display fingerprints and you haven't modified it, you're stuck. (At least you know you're stuck, but you knew that already.)

- if it's an open-source client but you're trusting someone else's binary, they can attack you.

- if it's an open-source client but you're not trusting someone else's binary, you're not on the embargo list and so responsibly-disclosed bugs are effectively zero-days for you.

- if it's an open-source client but it's written in C, you have no practical way of auditing it against intentionally-malicious source code (i.e., for almost everyone, the cost of auditing it is higher than the cost of visiting your conversation partner in person).

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

#109

Post by geofft »

sweeneyrod wrote: post #69
geofft wrote: post #34

Earlier quoted context omitted.

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?

Data decrypted when it reaches Zoom's servers, e.g., sending video directly over TLS to a webserver that then sends it to someone else over TLS.

This is what Slack, Skype, Google Hangouts, etc. do.

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

#110

Post by ooboe »

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.

In the Jitsi thread (https://news.ycombinator.com/item?id=22758131) also currently on the front page, someone from Jitsi mentions that they do have a way around this and that they don't decode the video on the server:

"We use a technique called simulcast. It consists on making every participant "work a bit harder" for the good of the bunch.

That is, every participant sends 3 separate video resolutions to the server: 720p, 480p and 180p (this may change due to bandwidth constraints). Then the server will only forward the approopriate layer to each other participant. So, if you are only seeing me in a thumbnail it will only forward the 180p layer. If I become the active speaker (or you choose to pin me to the large view) the server will immediately switch to forwarding the 720p layer."

So s/All/Not all/. Note that Jitsi does not claim to have e2e encryption.

Post reply on HN