[fierarul]

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, these attacks are starting to be annoying. From what I've seen all Zoom's reply is bang-on and they will come out of this even stronger.

[gregmac]

> 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 and decrypt streams, if they wanted to, which is why you can't call this "end-to-end encryption" [1].

[1] https://en.wikipedia.org/wiki/End-to-end_encryption

[close04]

> The problem is Zoom could intercept and decrypt streams, if they wanted to

And we have the spirit of encryption to guarantee they, or a third party who infiltrated/hacked them, won't.

>> and in that spirit, we used the term end-to-end encryption

[lukevp]

The spirit of encryption? What does that mean? End to end encrypted means from one client through all networks and servers to the other client, no one can decrypt the traffic. Anything besides that is not end to end.

[close04]

It means nothing but this is what Zoom tells us we have. Encryption given "in the spirit" of their intentions.

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

[lukevp]

Oh, I missed your sarcasm originally. I agree that it’s meaningless.

[cbsmith]

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.

[cameldrv]

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.

[cbsmith]

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

[tw04]

So don't claim you do end-to-end encryption? And don't put a green lock signifying end-to-end encryption in the client when you aren't actually doing end-to-end encryption?

You act as if they're the innocent victim here. They literally made indicators and showcase them in the client to signify encryption when they aren't doing it. If you send your kids to school and the teacher says they're being fed everyday, but then you find out a year later that kids with allergies just don't get lunch, you're OK with that? Or would you expect them to tell you UP FRONT about the caveats?

[saiongole]

Not disputing your core point but I think its important not to confuse the green padlock with end-to-end encryption. It only tells you that the data is sent over a secure connection to the server. The transmitted data itself is not encrypted.

[jamesaepp]

I'm not sure what you mean by the "transmitted data itself is not encrypted". The payload (the packet above layer 5) is encrypted. The distinction people need to make is who the _confidentiality_ applies to. The communications are not confidential between the callers/callees. The communications are only confidential between Zoom servers and the users. The provider sees all.

I think you understand this but maybe you didn't word it quite correctly. Never confuse confidentiality with encryption is the take-away that we as an industry need to do a better job telling our users about.

Edit: Well the communication isn't ONLY confidential between users & zoom but I'm simplifying for point of brevity.

[f38zf5vdt]

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:

client <--> server <--> client (server controls the encryption keys and can snoop on client communication at any time)

Signal and Matrix Synapse/Riot is the former, Zoom and Jitsi are the latter. While it's true that the server could also MITM and provide false keys to each client, both Signal and Riot let you view the keys of the person you're communicating with so you can verify you're not being MITM'd.

[geofft]

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

[pbhjpbhj]

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.

[wilg]

Even worse, the same could happen if it's an open source client!

[geofft]

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

[cpeterso]

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?

[gruez]

>Is there a public key associated with Apple account

with each device

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

[jancsika]

> 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

[angry_octet]

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.

[thoraway1010]

If you need more encryption you can sign up for their HIPPA service.

Note that it disables certain endpoint options and other features - so only worth doing if you really need it.