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

131–140 of 145 posts

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

#131

Post by angry_octet »

xeromal wrote: post #124
angry_octet wrote: post #117

Earlier quoted context omitted.

Can the clients not advise the server what bandwidth and packet loss rate they are seeing, so the server can adjust their traffic rate? There is no reason not to allow a signalling channel separate to the E2E encrypted data channels.

The server would then have to tell the streamer / talker to reduce their quality for that one client while degrading all other clients that have a fine connection right?

If you absolutely must have high frame rate for everybody then you might make that choice. But generally you could just drop B frames from the stream for the slow client, so they get a slower frame rate.

If you wanted to be fancy you could do distributed processing, whereby another node downscales and re-publishes the feed.

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

#132

Post by Spivak »

robbyt wrote: post #55
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'…

"We never intended to deceive any customers when we invented a new definition of e2e encryption"

"The business and marketing teams, who have never heard of the term e2e before, looked for a term to describe the feature of having every part of leg of the call encrypted, came up with e2e, and used it in the copy."

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

#133

Post by Spivak »

Thorrez wrote: post #122
wheelerwj wrote: post #115

Earlier quoted context omitted.

> if you don't have any external connector attached, it in fact is end-to-end encrypted, It doesn't say that all.

> 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. This seems to say it, but I guess as luckylion points out, e2e doesn't mean not decrypted in the middle, it means no one besides the ends has the key. So you're right, the design they say isn't really e2e encrypted.

Devil's advocate: if I take any e2e chat system and escrow the keys from the clients to my server is it still e2e?

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

#134

Post by cbsmith »

cameldrv wrote: post #87
cbsmith wrote: post #76

Earlier quoted context omitted.

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

Yes... and so what you're saying is it's possible for any web client, even one that Zoom runs, could enter into the conversation.

Wait, that's exactly how the product works...

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

#135

Post by paul_f »

CivBase wrote: post #48

> 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. So you knew that your users would misinterpret the term "end-to-end encryption" but chose to use it anyways. And you somehow expect us to believe you "never intended to deceive any of [your] customers"? > The goal of our encrypt…

I don't agree there is a common definition of end-to-end encryption. Ask a random, non-technical co-worker what they think it means and you might get an answer that matches Zoom's marketing claims.

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

#136

Post by lern_too_spel »

saagarjha wrote: post #127
lern_too_spel wrote: post #111

Earlier quoted context omitted.

Have I made a false comparison anywhere else, or was the comparison valid as in this case?

You keep drawing parallels between Zoom's end-to-end encryption and iMessage's, when there really is little to compare. iMessage is end-to-end encrypted because intermediaries do not have access to decryption keys; your "attack" relies on a malicious actor tampering with key distribution using a technique that requires even more setup than is described in the old article you've linked. On the other hand, Zoom has bee…

> You keep drawing parallels between Zoom's end-to-end encryption and iMessage's, when there really is little to compare

Once again, in none of my comparisons have I said they are doing the same thing. Please point to a specific comment I have made that you think is misleading.

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

#137

Post by lern_too_spel »

saagarjha wrote: post #128
lern_too_spel wrote: post #102

Earlier quoted context omitted.

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

Middlemen don't have a way of decrypting the data, because they don't have the keys to decrypt it. If they're malicious they can try to send you new keys to use, and only if you accept them will they then have the keys to decrypt your messages.

> and only if you accept them

Does iMessage give the user any way to reject them? Show me. Apple's own "Apple Platform Security Spring 2020" document does not claim any such thing. It says the device requests keys from IDS at the start of a conversation and just uses them.

The article I linked to above said that Apple fixed several other bugs the researchers pointed out but not that one, which other researchers had also described to Apple years before.

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

#138

Post by CivBase »

paul_f wrote: post #135
CivBase wrote: post #48

> 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. So you knew that your users would misinterpret the term "end-to-end encryption" but chose to use it anyways. And you somehow expect us to believe you "never intended to deceive any of [your] customers"? > The goal of our encrypt…

I don't agree there is a common definition of end-to-end encryption. Ask a random, non-technical co-worker what they think it means and you might get an answer that matches Zoom's marketing claims.

I feel like "end-to-end encryption" is a mostly self-explanatory term. All data passed from one end to the other is encrypted.

The point of encryption is to ensure that third parties cannot read your data. If a third party has the power to decrypt and read the data, then it's already misleading to advertise it as "encrypted". That would be like advertising a pair of boots as "waterproof" when they only actually prevent water from entering via the soles.

If the data is encrypted by one end, decrypted by a third party, and received at the other end unencrypted, then the encryption is not "end-to-end". I'm not sure how you could possibly interpret that part any other way.

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

#139

Post by sudosysgen »

tptacek wrote: post #118
0xy wrote: post #114

Earlier quoted context omitted.

This statement is simply false, Telegram has never claimed group chats are "end-to-end encrypted". Only secret chats are claimed to be and proven to be. https://telegram.org/faq#q-so-how-do-you-encrypt-data As early as 2017, they broadly and publicly advertised that they are NOT end-to-end encrypted 'by default'. https://telegra.ph/Why-Isnt-Telegram-End-to-End-Encrypted-by...

Your refutation of my claim is an article that claims Telegram's use of TLS encryption makes it more secure than its competitors, and links to another article going into even more detail about that ridiculous claim. I feel comfortable with where it leaves my argument standing.

We can debate that, but Telegram doesn't claim E2EE where it isn't the case.

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

#140

Post by Thorrez »

Spivak wrote: post #133
Thorrez wrote: post #122

Earlier quoted context omitted.

> 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. This seems to say it, but I guess as luckylion points out, e2e doesn't mean not decrypted in the middle, it means no one besides the ends has the key. So you're right, the design they say isn't really e2e encrypted.

Devil's advocate: if I take any e2e chat system and escrow the keys from the clients to my server is it still e2e?

I'm not sure what escrow means in this context. But if the server has the keys, I would say no, it's not e2e.

This aligns with the definition on Wikipedia too

> it prevents potential eavesdroppers – including telecom providers, Internet providers, and even the provider of the communication service – from being able to access the cryptographic keys needed to decrypt the conversation.

Post reply on HN