[gregmac]

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 system of communication where only the communicating users can read the messages. In principle, 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.

The fact that it's possible to decrypt is what makes this not "end-to-end encryption".

Personally, I am totally fine with their implementation, I just wish they'd stop misusing the term. For the vast majority of users, everything being encrypted over-the-wire coupled with a reasonable policy (eg, employees cannot listen in on random meetings) should be totally acceptable.

If there are people that that actually needed true end-to-end encryption and choose Zoom based on their marketing saying they had it, without doing validation, that's on them (though they're probably right to be upset with Zoom, too, for being misleading). Frankly, that set of people shouldn't be choosing anything they don't control and trust completely (code, hosting, updates, etc) which pretty much rules out any SaaS, so I suspect this set doesn't actually exist in the first place.

Bottom line: Don't call it "end-to-end encryption" if you have access to the keys and can decrypt, even if you choose not to. Market that you encrypt everything in transit, and that employees aren't allowed to access streams. Be realistic in the potential weak points (someone hijacking or able to modify the Zoom infrastructure, PSTN interconnects, non-Zoom clients, etc) and what you do to mitigate those risks.

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

[sameyepatch]

What I understand from that statement is that the data travels encrypted and each client does the encryption/decryption duty, not that they are able to decrypt the data at any point but decide not to.

I guess that using "we" in their statement is a tad misleading and can make people arrive at conclusions.

But that's just my point of view, it could still mean they can decrypt at any point.

EDIT: Someone else made the point of the other channels that do not support Zoom's encryption. I read about it in the article but I did not put two and two together. I guess I spoke too soon, seems Zoom can decrypt data at will after all.

[uoaei]

> What I understand from that statement is that the data travels encrypted and each client does the encryption/decryption duty, not that they are able to decrypt the data at any point but decide not to.

Those two things are not mutually exclusive. It reads to me like they are implicitly acknowledging that client-side "private" security keys aren't really private but are also stored elsewhere in Zoom's system.

[kreetx]

This. They really should look into what end-to-end encryption means.

As the parent says, they can implement their app however they please, but they should get their feature list straight.

[TwoBit]

Zoom knows exactly what end-to-end encryption means, and always has. Most likely their marketing group didn't like their engineering group telling them this nice buzzword didn't apply and intentionally chose to misuse it.

[SkyPuncher]

You see the exact same thing with HIPAA.

"End-to-end" is often (incorrectly) used to simply describe SSL/TLS protection from web browser to server. Not technically wrong, but also not how most developers understand the term.

[sneak]

> Zoom! What are you doing?!

Continuing to lie. Did you expect differently from this malware company?

[lern_too_spel]

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

[dspillett]

> By that definition, iMessage is also not end-to-end encrypted because

True, if true (I've not checked the iMessage details), but unimportant.

Whether or not iMessage is end-to-end-encrypted by the actual definition of end-to-end-encryption, does not change the fact the Zoom's communication is not end-to-end-encrypted by the actual definition of end-to-end-encryption while they are persisting in claiming that it actually is.

If they held up a blue ball and said "our ball is bright green", that would be incorrect. If someone else held up a yellow ball and said "our ball is bright green" that would not make Zoom's statement any more correct.

[saagarjha]

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.

[lern_too_spel]

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

[saagarjha]

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

[lern_too_spel]

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

[saagarjha]

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 been actually decrypting traffic as a key part of their service and yet called it end-to-end.

[ThePowerOfFuet]

It's not outdated; Apple still controls the key distribution and the users cannot verify how many recipient key sets there are.

[saagarjha]

For one, iMessage (and FaceTime) will now tell you if a new device is added.

[ThePowerOfFuet]

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

[lern_too_spel]

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

[saagarjha]

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.

[lern_too_spel]

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