Live data from Hacker News

The facts around Zoom and encryption for meetings/webinars

blog.zoom.us

31–40 of 145 posts

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

#31
Does anyone know how this could technically be possible? For a meeting with all Zoom clients they say they use E2E. When a new participant joins, they are immediately added to the meeting.

Is a new pubkey key generated and passed to existing participants? Is there one shared symmetric key that is sent to the new participant? What stops zoom from "adding a participant" and allowing themselves to decrypt the meeting? Is there no server-side transcoding done at all?

It's obvious phone enabled calls can’t be E2E

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

#32

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 term which none of their programmers would have ever signed off on.

If you have a citation for a FAX machine company misapplying the phrase "end-to-end encryption" to their product during the coronavirus outbreak (or any other time for that matter) I'd be interested to see it.

Edit: clarification

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

#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.com/watch?v=PB-AyvgE8Ns

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

#34
post #26
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)

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 do. There's been no shortage of genuine security problems with Zoom (and an apparent lack of security culture) but I think we've now gotten to e.g. "you can use Zoom to trigger a Windows design flaw that's been around for years" or "when you set up a meeting anyone can join, anyone can join the meeting" or whatever, and the media is happy to pick that up.

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

#35

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 get it. (People who want end-to-end encryption between phone calls from unmodified phones want something self-contradictory.)

I'm not sure I'd call that "They didn't have end-to-end encryption." Would you say that my IRC OTR session with my friend isn't end-to-end encrypted because I connect to irssi running in a screen session on a remote host and the e2e doesn't go all the way to my laptop?

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

#36

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…

> Is there any evidence that other teleconferencing solutions meet or exceed what's described in this blog article?

Did they market themselves as end-to-end encrypted?

Zoom has security problems. This isn't one of them. This is a marketing, and more fundamentally, potential culture/honesty problem. (Best case, it's one of attention to detail. Marketing didn't understand a term, used it and nobody looked back.)

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

#37
post #35

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…

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

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

#38
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."

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

#39
post #34
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…

There's a backlash in vulnerability research circles, because we've all had to deal with systems that are much, much worse (Webex, for example). I'm not a fan of Zoom or anything, but the concerns they're generating about security are unbalanced and not especially reasonable.

But, again: we've had long threads on HN "debating" the notion that Telegram is E2E-encrypted by dint of TLS to Telegram's servers, as if that was a legitimate proposition. Because Telegram has a cheering section, and Zoom, it seems, does not.

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

#40

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…

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 fingerprint without notification.) But we still call those "end-to-end encrypted," right?

Is there a meaningful end-user difference between a design where you have to ask the server for your peer's public key and the server promises to be honest, and a design where the server generates a shared secret and then promises not to use it?

(Note that this question is completely orthogonal to whether the client or server are source-available - unless you can modify the client to display peer fingerprints, merely knowing that you're going to have to trust the server doesn't really change anything.)

Post reply on HN