> 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.
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.
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.
As the parent says, they can implement their app however they please, but they should get their feature list straight.
Continuing to lie. Did you expect differently from this malware company?
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...
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.
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).
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...
(I might be missing something about either Zoom or Telegram)
(Encrypted messaging is a hard problem, especially when you have to deal with users with multiple devices which are offline intermittently, or users joining an established group chat. Telegram has taken the sensible approach of not trying to solve this.)
At any point, someone could go into Zoom's systems, get the keys to your chat, and monitor you, and you would have no way of knowing.
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 with When users join Zoom meetings using devices that do not inherently use Zoom’s communication protocol, such as a phone (connected via traditional telephone line, rather than the app) or SIP/H.323 room-based systems, Zoom’s encryption cannot be applied directly by that phone or device so if those users can join the meeting after it has been established between Zoom-clients, it's not e2e.
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 encryption design is to provide the maximum amount of privacy possible while supporting the diverse needs of our client base.
This statement is at odds with the statement that immediately follows.
> 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.
If you do not decrypt it at any point, then you are admitting you have no legitimate need to decrypt it. If you have no legitimate need to decrypt it, but are retaining the ability to decrypt it anyways, then you are not providing the "maximum amount of privacy possible". If you are communicating between two Zoom clients, then there does not seem to be a reason not to use true end-to-end encryption.
I'm 100% fine with Zoom offering solutions without true end-to-end encryption. The way they have described their "Zoom Connector" solution, I think they've already gone above and beyond most of their competitors. However, that absolutely does not excuse how they have deliberately mislead their users.
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.
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.
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].
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
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.
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?
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.
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.)
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
Basically Zoom is just using sophistry to avoid being straight forward about limitations, which reinforces my poor opinion of them.
Note that it disables certain endpoint options and other features - so only worth doing if you really need it.
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.
Hundreds of millions of people use Facebook Messenger for their everyday communications, which is not meaningfully encrypted at all other than by TLS. Similarly, Discord is also very popular, as is Skype. None of these offer privacy.
Most people have a very fatalistic view about their opportunities for privacy in their electronic communications.
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?
Which means, there is no end-to-end-encryption. Zoom knows the key but does not decrypt the data unless they need to to let a member join via phone. You need to trust Zoom that they keep their promise not to decrypt your communication, there is no technical hurdle.
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.
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 all these vendors
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.)
All of the group video providers will be decoding video on the server to achieve the reliability everyone wants.
There are also ways to send additive resolution streams -- a base stream and additional detail layers (multiresolution like JPEG2000).
"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.
Is everyone doing alternative facts now ? This was a relatively simple thing to clear up, if they wanted to clear it up. They can decrypt whatever they want. So it's not end to end. Claiming otherwise was disingenuous, but putting out some PR spin on top of that is doubly so.
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
"...and do not decrypt it at any point before it reaches the receiving clients"
Am I misunderstanding something? This doesn’t seem like it should be controversial.
Their blog post even says if zoom managing keys isn't good security for enterprise - they will have a new product (soon?) to host the keys in an enterprises DC instead.
I don't understand how some devices could be end to end encrypted in a meeting while some legacy devices in the same meeting are not. How could the legacy devices send and receive to the encrypted clients?
Obviously for un-trained users you often have the problem where someone transmits encrypted when they meant to talk in the clear, and vice versa. This is the reason for the 'plaintext' or 'ciphertext' side tones. If someone starts talking in the clear when they should not, another participant may choose to transmit over them, known as stepping on their transmission.
None of this requires there be a group key known by a central server.
I have no special insight into how Zoom implements it, that's just how this is normally implemented in a number of other situations (e.g. h.323 bridges).
You have to assume every Zoom call is recorded by Zoom.
Glad to hear they have the on-premise option anyway.
Is this a lie or have they not heard of CALEA?
In other words, "We deceived our customers with false advertising but we're never going to admit that."
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."
Everything from the text to the graphics are intended to mislead and obscure. I don’t think i’ve seen a company act in such bad faith since theranos was a thing.
It doesn't say that all.
No, it says that they don't decrypt it until it reaches the other client, not that they can't decrypt it.
So... privacy is a premium feature requiring you to self-host? Why not just run jitsi for free?
> Is Jitsi Meet end-to-end encrypted? #409
> ... "yes, https://meet.jit.si/ encrypts the communication, only the two clients and our server has access to them". ... [1]
> Is Jitsi Meet end-to-end encrypted? #409
> ... "yes, https://meet.jit.si/ encrypts the communication, only the two clients and our server has access to them". ... [1]
In fact, "yes, .. " is an answer to the question "is it reasonable to use Jitsi Meet from an untrusted wifi network?". It was written by a user of Jitsi and not one of the developers.
A developer answers "when talking on meet.jit.si your stream is encrypted on the network but decrypted on the machine that hosts the bridge."
