The facts around Zoom and encryption for meetings/webinars(blog.zoom.us)
blog.zoom.us
The facts around Zoom and encryption for meetings/webinars
https://blog.zoom.us/wordpress/2020/04/01/facts-around-zoom-encryption-for-meetings-webinars/
144 comments
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.
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.
> 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.
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.
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.
As the parent says, they can implement their app however they please, but they should get their feature list straight.
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.
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.
"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.
> Zoom! What are you doing?!
Continuing to lie. Did you expect differently from this malware company?
Continuing to lie. Did you expect differently from this malware company?
> 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/
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/
> 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.
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.
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.
> 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.
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.
> 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.
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.
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 been actually decrypting traffic as a key part of their service and yet called it end-to-end.
> 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.
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.
It's not outdated; Apple still controls the key distribution and the users cannot verify how many recipient key sets there are.
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).
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).
> 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.
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.
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.
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.
If this pisses you off, it's worth noting that Telegram group chats have the same property, and that Telegram argues forcefully (and falsely) that what they're doing does meet the definition of "end-to-end encryption".
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...
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.
The central point of your comment was false and invented. You have claimed they made assertions they absolutely never made.
I don't see how the TLS claim is relevant, your comment is still wrong. It also misrepresents their argument, that competitors using cloud backup is less secure than not doing so because it introduces a very untrusted third party (Google Drive is not E2EE).
Their claim that E2EE + Google Drive backup is not secure seems pretty valid to me, not that it's related to the inaccuracy of your comment (it's still a false statement, and pretty egregious considering it's never been claimed).
Why are you putting words in their mouth?
I don't see how the TLS claim is relevant, your comment is still wrong. It also misrepresents their argument, that competitors using cloud backup is less secure than not doing so because it introduces a very untrusted third party (Google Drive is not E2EE).
Their claim that E2EE + Google Drive backup is not secure seems pretty valid to me, not that it's related to the inaccuracy of your comment (it's still a false statement, and pretty egregious considering it's never been claimed).
Why are you putting words in their mouth?
We can debate that, but Telegram doesn't claim E2EE where it isn't the case.
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 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.
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.
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.
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.
If what Zoom is doing in the first diagram is end-to-end encryption, what would non-e2e encryption for that set up look like?
Data decrypted when it reaches Zoom's servers, e.g., sending video directly over TLS to a webserver that then sends it to someone else over TLS.
This is what Slack, Skype, Google Hangouts, etc. do.
This is what Slack, Skype, Google Hangouts, etc. do.
Telegram only uses end-to-end encryption for "secret chats" and voice calls. Group chats and standard person-to-person chats are not end-to-end encrypted, and I don't believe Telegram has made any claims to the contrary.
(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.)
(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.)
Encrypted messaging is a solved problem, and even WhatsApp manages end-to-end group chats. Telegram does not, but claims in its FAQ that "All Telegram messages are always securely encrypted" (it is referring explicitly to group messaging). Telegram is far more misleading than Zoom is, but again, Zoom lacks the cheering section. Maybe if they released a ZoomCoin.
Fair point on the FAQ. At least they didn't explicitly misuse the term "end-to-end"?
That being said, I'm not certain encryption is an entirely solved problem for the case of multiple devices, including web clients, or for large public groups. (WhatsApp only supports a single client -- their web interface attaches to the phone -- and their group chats are limited to 256 members.) I'm not sure it can be solved under the current model Telegram uses for authorizing devices, as the server can authorize a device to access an account, and any non-secret chats it was involved in, without the involvement of any previously signed-in devices.
That being said, I'm not certain encryption is an entirely solved problem for the case of multiple devices, including web clients, or for large public groups. (WhatsApp only supports a single client -- their web interface attaches to the phone -- and their group chats are limited to 256 members.) I'm not sure it can be solved under the current model Telegram uses for authorizing devices, as the server can authorize a device to access an account, and any non-secret chats it was involved in, without the involvement of any previously signed-in devices.
Zoom does not do end-to-end encryption. End to end encryption means that only the end user can decrypt the message. Zoom central can decrypt the message, because they hold the keys. They mostly don't bother, but that's just an optimisation.
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.
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.
> Zoom does (what appears to be) end-to-end encryption if you have four native Zoom clients in a meeting.
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.
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.
> if those users can join the meeting after it has been established between Zoom-clients, it's not e2e.
I don't think that follows.
First, it's absolutely possible to design an E2E system where users can join the meeting after it started: https://signal.org/blog/private-groups/
Second, you can have your phone gateways be stateless and unprivileged: when a user calls up the phone gateway, it generates a new keypair. The user enters their PIN and the phone gateway derives a key from the PIN using your favorite password hashing algorithm, HMACs their public key with the PIN, and sends it to the existing participants. The other participants have the same PIN, so they can decide to let this public key join the call without allowing random callers to join. (I'm not sure if Zoom does this, but it's straightforward enough and it makes the phone gateways much less juicy of an attack target, especially because you can now reboot the gateways from read-only media and you don't need to provision them a secret, so I hope they do.)
Now we're left with the argument about whether it really counts as "end-to-end" if the plain-old-telephone-system part of the connection isn't encrypted, but also it can't be, so I'm not sure anyone reasonably expected it to be encrypted. Anyone who really wants "end-to-end" encryption can just make sure nobody joins their call by phone. (In the end, end-to-end encryption is a tool to make sure the right people join your meeting - i.e., anyone who cares about end-to-end encryption already cares about who the ends are.)
I don't think that follows.
First, it's absolutely possible to design an E2E system where users can join the meeting after it started: https://signal.org/blog/private-groups/
Second, you can have your phone gateways be stateless and unprivileged: when a user calls up the phone gateway, it generates a new keypair. The user enters their PIN and the phone gateway derives a key from the PIN using your favorite password hashing algorithm, HMACs their public key with the PIN, and sends it to the existing participants. The other participants have the same PIN, so they can decide to let this public key join the call without allowing random callers to join. (I'm not sure if Zoom does this, but it's straightforward enough and it makes the phone gateways much less juicy of an attack target, especially because you can now reboot the gateways from read-only media and you don't need to provision them a secret, so I hope they do.)
Now we're left with the argument about whether it really counts as "end-to-end" if the plain-old-telephone-system part of the connection isn't encrypted, but also it can't be, so I'm not sure anyone reasonably expected it to be encrypted. Anyone who really wants "end-to-end" encryption can just make sure nobody joins their call by phone. (In the end, end-to-end encryption is a tool to make sure the right people join your meeting - i.e., anyone who cares about end-to-end encryption already cares about who the ends are.)
[deleted]
> 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 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.
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.
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.
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.
But that's not the question here. That's only talking about when there is a connector involved. For a zoom-zoom only chat, if my encryption works by:
* I generate a key * I give it to you and another party * You and the other party then chat through my service * I pass the messages between you but don't bother to decrypt them
Does that count as end-to-end encryption? At any time, I could decide to decrypt the message (even months later if it is logged).
* I generate a key * I give it to you and another party * You and the other party then chat through my service * I pass the messages between you but don't bother to decrypt them
Does that count as end-to-end encryption? At any time, I could decide to decrypt the message (even months later if it is logged).
Since it’s a technical term being used to communicate technical information, it really doesn’t matter what a nontechnical person would think it means.
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.
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.
> 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
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
> 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
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
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.
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.
> 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.
Oh, I missed your sarcasm originally. I agree that it’s meaningless.
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.
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 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.
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...
Wait, that's exactly how the product works...
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?
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?
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.
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.
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.
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.
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.
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.)
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.)
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.
Even worse, the same could happen if it's an open source client!
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).
- 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).
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?
>Is there a public key associated with Apple account
with each device
https://manuals.info.apple.com/MANUALS/1000/MA1902/en_US/app...
with each device
https://manuals.info.apple.com/MANUALS/1000/MA1902/en_US/app...
> 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
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
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.
Basically Zoom is just using sophistry to avoid being straight forward about limitations, which reinforces my poor opinion of them.
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.
Note that it disables certain endpoint options and other features - so only worth doing if you really need it.
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
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
This problem will probably go away anyway.
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.
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.
> 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?
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?
> 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.
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.
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.
How is that meaningfully different from a system like Signal or iMessage where you need to trust Zoom that when they say "this is Bob's fingerprint" they're actually giving you Bob's fingerprint and not their MITM key? They still need to keep their promise, there still is no technical hurdle.
(Signal gives you the option to verify fingerprints out-of-band but their UI discourages using it; iMessage doesn't even do that. I mean, maybe the answer is we collectively decide to stop calling iMessage end-to-end-encrypted....)
(Signal gives you the option to verify fingerprints out-of-band but their UI discourages using it; iMessage doesn't even do that. I mean, maybe the answer is we collectively decide to stop calling iMessage end-to-end-encrypted....)
Inferring device does encryption, while silently allowing data leakage in complex ways that are beyond the typical consumer is deceptive at best.
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.
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.
> This product is provided as a SECURE means of communication and it IS NOT.
Are you claiming that there are actual customers who believed that if they called up a Zoom conference via a phone number, their connection would be encrypted from their landline phone all the way to the other end, and were surprised to learn it was not?
> 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.
This attack has nothing to do with end-to-end encryption (i.e., it is equally possible against systems that are well-accepted as "end-to-end encryption," so if you're using this as a criterion, nothing is end-to-end encrypted.)
That doesn't mean I don't think it's a problem. That just means I think that words have meanings, and "end-to-end encrypted" is not a synonym for "secure under the threat model I care about," and never has been, for anyone.
Are you claiming that there are actual customers who believed that if they called up a Zoom conference via a phone number, their connection would be encrypted from their landline phone all the way to the other end, and were surprised to learn it was not?
> 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.
This attack has nothing to do with end-to-end encryption (i.e., it is equally possible against systems that are well-accepted as "end-to-end encryption," so if you're using this as a criterion, nothing is end-to-end encrypted.)
That doesn't mean I don't think it's a problem. That just means I think that words have meanings, and "end-to-end encrypted" is not a synonym for "secure under the threat model I care about," and never has been, for anyone.
I understood they never had it for video. Which was included in their claim. So there's that.
OK, that would be serious flaw, and also the current blog post states clearly that they do, so if that's a lie, then we have a much bigger problem on our hands than whether they should be using the term "end-to-end encryption."
> 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.
> 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.
Well, it says they "do not decrypt it" not that they "cannot decrypt it".
Sure, but they're making a claim that they cannot decrypt it without you noticing. If a Zoom employee wants to monitor your call, they'll show up as a participant. If you have a 5-person meeting and nobody is joined by phone, and there are 5 people on the call plus one phone bridge, you know some eavesdropper (perhaps Zoom, perhaps someone who's good at guessing conference IDs) has joined.
(I would hope their system is architected in such a way that clients enforce this and do not trust the server for the participant list. If they don't, then I'd take issue with that part of their blog post. But also I'd argue that in practice systems like Signal or iMessage can MITM your traffic if you really want, so I'm not convinced this is meaningfully worse for users even so....)
(I would hope their system is architected in such a way that clients enforce this and do not trust the server for the participant list. If they don't, then I'd take issue with that part of their blog post. But also I'd argue that in practice systems like Signal or iMessage can MITM your traffic if you really want, so I'm not convinced this is meaningfully worse for users even so....)
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 all these vendors
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
> 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.)
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.)
Or is it that Zoom is so ubiquitous, that they get the scrutiny? But every other vendor doesn't get this level of scrutiny?
> every other vendor doesn't get this level of scrutiny?
One, that doesn’t excuse false advertising. Two, yes, it makes more sense to scrutinise things everyone uses than things nobody does.
Growing pains are nothing new. How a culture reacts to such pains is informative.
One, that doesn’t excuse false advertising. Two, yes, it makes more sense to scrutinise things everyone uses than things nobody does.
Growing pains are nothing new. How a culture reacts to such pains is informative.
The video must be decrypted to do the scaling, transcoding, and dynamic bitrate adjustment for different platforms and network speeds – there's no way around this.
All of the group video providers will be decoding video on the server to achieve the reliability everyone wants.
All of the group video providers will be decoding video on the server to achieve the reliability everyone wants.
The clients can dynamically adjust their sending rate and resolution. It is pretty easy to downgrade your video when not talking. Its also possible to number and label the encrypted frames (I frames or B frames), allowing decimation for low bandwidth clients without recoding, which is expensive and slow.
There are also ways to send additive resolution streams -- a base stream and additional detail layers (multiresolution like JPEG2000).
There are also ways to send additive resolution streams -- a base stream and additional detail layers (multiresolution like JPEG2000).
Clients already do this yes, but to achieve the reliability that zoom is renowned for you also need to dynamically adjust what is sent _TO_ individual clients
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.
If you wanted to be fancy you could do distributed processing, whereby another node downscales and re-publishes the feed.
In the Jitsi thread (https://news.ycombinator.com/item?id=22758131) also currently on the front page, someone from Jitsi mentions that they do have a way around this and that they don't decode the video on the server:
"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.
"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.
The Zoom article we are discussing here claims they do not do that.
You’re right. The competitors make as bold claims ;)
>The Facts Around Zoom and Encryption for Meetings/Webinars
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 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.
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
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
[deleted]
If Zoom literally doesn't decrypt the packets in flight to re-encrypt them, it means they don't have peerwise keys for each client. So (as a non-expert) they're either now lying about something else (and in fact, the data is decrypted on the server temporarily in memory, and re-encrypted for each peer using a distinct key, akin to a WebRTC SFU) or there's a shared secret key between all clients, which is a major security deficiency.
The article specifically states that they coordinate the key through their servers.
So which of the two is it? A shared secret key among all clients, or individual keys per client. If its the latter, which would be smart, this line is a lie:
"...and do not decrypt it at any point before it reaches the receiving clients"
"...and do not decrypt it at any point before it reaches the receiving clients"
It doesn't make sense to encrypt the traffic differently for the individual users, since you would need to send multiple copies of the stream if the server can't do it (which is also a big downside of all the P2P solutions). It's not smart design for large-scale video chat.
A shared key or different keys per sender (which I don't think adds anything, but I might be missing something) both do not require the server to decrypt/reencrypt, and thus fairly sure that's what they are doing if this is anywhere close to accurate.
A shared key or different keys per sender (which I don't think adds anything, but I might be missing something) both do not require the server to decrypt/reencrypt, and thus fairly sure that's what they are doing if this is anywhere close to accurate.
WebRTC SFUs encrypt traffic differently to the individual users. Each outgoing packet needs to be encrypted with the receiver's negotiated keys, is my understanding. If it was a shared key, then presumably that key could be negotiated among the peers using public key exchange, unbeknownst to the server, and then all traffic be e2e encrypted, which it isn't. I have minimal understanding of what protocols Zoom uses out of the box, but if they don't support e2e encryption, it seems to me they need the keys on the servers for a reason, and the only legit reason would be to trans-crypt the packets.
It's a lot easier to implement central key management than a fully e2e system, especially if they do need the key for many meetings anyway on some of their systems.
[deleted]
[deleted]
In fairness, it sounds like it’s end to end encrypted until a legacy device connects.
Am I misunderstanding something? This doesn’t seem like it should be controversial.
Am I misunderstanding something? This doesn’t seem like it should be controversial.
It wouldn't be controversial if they explicitly stated that, and took "End-to-end encryption for all meetings" off of their features page.
you're missing the fact they manage all the keys. So it isn't E2E encryption... Each client should generate their own key and exchange it with all the other clients directly. Zoom is collecting all the keys in their cloud.
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.
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.
Is the end to end encryption removed for all clients when a legacy device connects?
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?
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?
It is possible if you think about it beforehand -- genrally you use a tone and/or a visual indicator to show that a transmission is in the clear (unencrypted). Other clients can then have a mechanism to allow speaking in the clear (sometimes requiring PTT -- press to talk). When encrypted transmission is ongoing, the gateway to the encrypted net may output a 'talk tone' that indicates the channel is busy. In this way a low grade client can join the conference, but they hear nothing but beeps (for a pure voice circuit) or see a busy indicator (for IP circuits) until someone wants to talk to them. When they talk, it is unencrypted till it reaches a gateway, after which it is either encrypted with the gateway key or passed unencrypted. (For radio broadcasts you just hear crackle or nothing.)
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.
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.
Don’t all these products need to do this if one of the participants is using a regular phone? It’s just impossible to support phone dial in otherwise.
They claim to do end to end encryption if there are no phones on the call.
it is unclear how key exchanges can be handled securely in these cases. The post seems to suggest Zoom cannot insert itself as middleman ("without showing on the participant list"). But that contradicts directly to how these "connectors" work.
The connectors appear in the participant list - this is a pretty common architecture for all kinds of communications bridging solutions. When someone joins a meeting by phone, Zoom spins up a service that 'assumes the identity' of that phone user to join the meeting (incl. negotiating keys). So, the Zoom service is now a participant in the meeting, but you do know that since a user appears in the participant list.
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).
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).
Thanks, that makes sense. I am not familiar with Zoom the product to know the connectors show up in participant list.
I think even if proper e2e channel established, without authentication (Zoom just allows you to join any meeting with a token, like every other Hangout product), the key exchanges with other participants will be very automated. There seems to be very limited security guarantee if anyone can send you a public key in exchange for the current session key to participate in a meeting to begin with.
I think even if proper e2e channel established, without authentication (Zoom just allows you to join any meeting with a token, like every other Hangout product), the key exchanges with other participants will be very automated. There seems to be very limited security guarantee if anyone can send you a public key in exchange for the current session key to participate in a meeting to begin with.
Right, and this is kind of the key problem that Zoom is having to solve right now. The only material you (used to) need to know to join a meeting was a 9-ish digit meeting ID, and since that meeting ID entitles you to negotiate keys, it more or less nullifies encryption guarantees (except the post-hoc guarantee of the meeting host being able to see if something was up).
I would point out that this is in no way unique to Zoom, though. In fact, after the changes Zoom made in response to all of these issues, Zoom probably has the highest by-default level of meeting security of just about any product out there.
I would point out that this is in no way unique to Zoom, though. In fact, after the changes Zoom made in response to all of these issues, Zoom probably has the highest by-default level of meeting security of just about any product out there.
So essentially any time a Zoom Connector is involved, Zoom has access to the meeting contents since they own the keys. It would be interesting then to know what percentage of all Zoom calls involve a Connector.
Who says there is not an invisible Connector? They have the keys.
You have to assume every Zoom call is recorded by Zoom.
You have to assume every Zoom call is recorded by Zoom.
I've gone from a big fan of Zoom to now a skeptic. I'm wondering if Zoom might turn out to be the CPP's version of Crypto AG.
Does anyone know if using the "browser client" breaks encryption? I have been trying to use it to avoid issues with the native app, but if it turns on server-side decryption, that's kind of a big tradeoff.
Glad to hear they have the on-premise option anyway.
Glad to hear they have the on-premise option anyway.
"Zoom has never built a mechanism to decrypt live meetings for lawful intercept purposes"
Is this a lie or have they not heard of CALEA?
Is this a lie or have they not heard of CALEA?
Are they classified as something falling under CALEA?
"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're never going to admit that."
In other words, "We deceived our customers with false advertising but we're never going to admit that."
"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."
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."
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."
[deleted]
I love that the address one issue and ignore all the other security holes. They have a structural problem with taking security seriously.
They had a separate post about privacy/security in general: https://blog.zoom.us/wordpress/2020/04/01/a-message-to-our-u...
Sounds like most companies. Which is even more concerning
wow!! zoom you were better off not having written that blog. you guys are some shady assholes.
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.
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.
In my opinion they seem better off from this blog post. For example yesterday I read this comment[1] and it seemed to say Zoom always decrypts the content on the servers, in which case it's very bad to say it's "end-to-end encrypted". But this blog post explains that if you don't have any external connector attached, it in fact is end-to-end encrypted, no false advertising. When you have an external connector attached it seems to me very difficult if not impossible to make it end-to-end encrypted, so it's reasonable that it's not. The problem is that they continued to say it was end-to-end encrypted even in that case when it's not and not possible to do so.
[1] https://news.ycombinator.com/item?id=22754699
[1] https://news.ycombinator.com/item?id=22754699
> if you don't have any external connector attached, it in fact is end-to-end encrypted,
It doesn't say that all.
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.
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.
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.
[deleted]
> But this blog post explains that if you don't have any external connector attached, it in fact is end-to-end encrypted, no false advertising.
No, it says that they don't decrypt it until it reaches the other client, not that they can't decrypt it.
No, it says that they don't decrypt it until it reaches the other client, not that they can't decrypt it.
I now agree with your point that it's not really e2e encrypted, because they never claim they don't have the key.
But I don't think "can't decrypt it" is necessarily a requirement for e2e encryption. Maybe can't decrypt it with a passive attack. With an active attack it's possible to decrypt even e2e encrypted stuff assuming there's no out of band key exchange. Most Zoom users won't bother with an out of band key exchange.
But I don't think "can't decrypt it" is necessarily a requirement for e2e encryption. Maybe can't decrypt it with a passive attack. With an active attack it's possible to decrypt even e2e encrypted stuff assuming there's no out of band key exchange. Most Zoom users won't bother with an out of band key exchange.
> For those who want additional control of their keys, an on-premise solution exists today for the entire meeting infrastructure, and a solution will be available later this year to allow organizations to leverage Zoom’s cloud infrastructure but host the key management system within their environment. Additionally, enterprise customers have the option to run certain versions of our connectors within their own data centers if they would like to manage the decryption and translation process themselves.
So... privacy is a premium feature requiring you to self-host? Why not just run jitsi for free?
So... privacy is a premium feature requiring you to self-host? Why not just run jitsi for free?
Doesn't Jitsi have the same problem? The solution is the same: Run your own server. End to end encrypted videoconferencing does not scale easily without a server.
> 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]
[1]: https://github.com/jitsi/jitsi-meet/issues/409
> 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]
[1]: https://github.com/jitsi/jitsi-meet/issues/409
To me, this quote gave the impression that Jitsi developers similarly (and falsely) claim that it is end-to-end encrypted:
> 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."
> 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."
Yes... but in one case the software is entirely FOSS and readily deployable via a docker image. The Zoom server is not FOSS, or even accessible through their GitHub.
https://github.com/jitsi/docker-jitsi-meet
https://github.com/jitsi/docker-jitsi-meet
Right. Let's assume I refuse to take on the responsibility of a videoconferencing server. What are my options to get Jitsi Meet? Can I pay a company to set up and maintain it? Or do I have to hunt for a videoconferencing engineer?
It's free if you use their servers (https://meet.jit.si/), but then you're back to square one in that you don't own the encryption keys.
Scaleway shows how easy it is to configure and deploy on a cloud host:
https://www.scaleway.com/en/docs/deploy-jitsi-meet-with-dock...
Whether or not your cloud hosting is secure is a separate issue altogether. :)
I'm not saying that it's E2EE on Jitsi either, but at least the implementation is transparent.
Scaleway shows how easy it is to configure and deploy on a cloud host:
https://www.scaleway.com/en/docs/deploy-jitsi-meet-with-dock...
Whether or not your cloud hosting is secure is a separate issue altogether. :)
I'm not saying that it's E2EE on Jitsi either, but at least the implementation is transparent.
> 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