30 ms·

The facts around Zoom and encryption for meetings/webinars

170 points by arvindch 6y ago

f38zf5vdt 6y ago
> 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?
- swixmix 6y ago
  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/ 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 https://github.com/jitsi/jitsi-meet/issues/409
  - f38zf5vdt 6y ago
    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
    - swixmix 6y ago
      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?
      - f38zf5vdt 6y ago
        It's free if you use their servers (https://meet.jit.si/ 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-docker/ 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.
  - mtgx 6y ago
    Uh, I can't believe that their answer is "yes.....and our server has access to them." Which is it Jitsi team? You can't have your users' cake and eat it, too.
  - ahendriksen 6y ago
    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/ 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."
hedora 6y ago
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.
- prophesi 6y ago
  It wouldn't be controversial if they explicitly stated that, and took "End-to-end encryption for all meetings" off of their features page.
- cracker_jacks 6y ago
  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?
  - angry_octet 6y ago
    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.
- jiqiren 6y ago
gumby 6y ago
I love that the address one issue and ignore all the other security holes. They have a structural problem with taking security seriously.
- dangoor 6y ago
  They had a separate post about privacy/security in general: https://blog.zoom.us/wordpress/2020/04/01/a-message-to-our-users/ https://blog.zoom.us/wordpress/2020/04/01/a-message-to-our-u...
- techopoly 6y ago
  Sounds like most companies. Which is even more concerning
prophesi 6y ago
"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."
- netsharc 6y ago
  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."
  - deleted 6y ago
    [deleted]
- robbyt 6y ago
  "We never intended to deceive any customers when we invented a new definition of e2e encryption"
  - Spivak 6y ago
    "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."
innagadadavida 6y ago
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.
- liuliu 6y ago
  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.
  - jcrawfordor 6y ago
    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).
    - liuliu 6y ago
      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.
      - jcrawfordor 6y ago
        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.
wheelerwj 6y ago
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.
- Thorrez 6y ago
  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 https://news.ycombinator.com/item?id=22754699
  - luckylion 6y ago
    > 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.
    - Thorrez 6y ago
      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.
  - wheelerwj 6y ago
    > if you don't have any external connector attached, it in fact is end-to-end encrypted, It doesn't say that all.
tptacek 6y ago
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".
- geofft 6y ago
  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)
  - tptacek 6y ago
    I think you're right! I'm more interested in the double standard (and the dynamics of a pile-on) than the details.
    - geofft 6y ago
      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.
      - tptacek 6y ago
        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.
fierarul 6y ago
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.
- f38zf5vdt 6y ago
  When a product specifies "end to end encryption" my expectation is that the only function of the server is to pass the public keys from two clients around so they can Diffie-Hellman kx to achieve a mutually shared private key to encrypt their communications to each other, so that information flow is: client <--> client (no server knowledge of communications aside from the encrypted packets being passed back end forth) Not: client <--> server <--> client (server controls the encryption keys and can snoop on client communication at any time) Signal and Matrix Synapse/Riot is the former, Zoom and Jitsi are the latter. While it's true that the server could also MITM and provide false keys to each client, both Signal and Riot let you view the keys of the person you're communicating with so you can verify you're not being MITM'd.
  - geofft 6y ago
    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.)
softwaredoug 6y ago
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
- longtermd 6y ago
  You’re right. The competitors make as bold claims ;)
- tommoor 6y ago
  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.
  - angry_octet 6y ago
    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).
    - tommoor 6y ago
      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
      - angry_octet 6y ago
gregmac 6y ago
Zoom! What are you doing?! > To be clear, in a meeting where all of the participants are using Zoom clients, and the meeting is not being recorded, we encrypt all video, audio, screen sharing, and chat content at the sending client, and do not decrypt it at any point before it reaches the receiving clients. That is still not what "end-to-end encryption" means. From wikipedia[1]: > End-to-end encryption (E2EE) is a system of communication where only the communicating users can read the messages. In principle, it prevents potential eavesdroppers – including telecom providers, Internet providers, and even the provider of the communication service – from being able to access the cryptographic keys needed to decrypt the conversation. The fact that it's possible to decrypt is what makes this not "end-to-end encryption". Personally, I am totally fine with their implementation, I just wish they'd stop misusing the term. For the vast majority of users, everything being encrypted over-the-wire coupled with a reasonable policy (eg, employees cannot listen in on random meetings) should be totally acceptable. If there are people that that actually needed true end-to-end encryption and choose Zoom based on their marketing saying they had it, without doing validation, that's on them (though they're probably right to be upset with Zoom, too, for being misleading). Frankly, that set of people shouldn't be choosing anything they don't control and trust completely (code, hosting, updates, etc) which pretty much rules out any SaaS, so I suspect this set doesn't actually exist in the first place. Bottom line: Don't call it "end-to-end encryption" if you have access to the keys and can decrypt, even if you choose not to. Market that you encrypt everything in transit, and that employees aren't allowed to access streams. Be realistic in the potential weak points (someone hijacking or able to modify the Zoom infrastructure, PSTN interconnects, non-Zoom clients, etc) and what you do to mitigate those risks. [1] https://en.wikipedia.org/wiki/End-to-end_encryption https://en.wikipedia.org/wiki/End-to-end_encryption
- kreetx 6y ago
  This. They really should look into what end-to-end encryption means. As the parent says, they can implement their app however they please, but they should get their feature list straight.
  - TwoBit 6y ago
    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.
stonewareslord 6y ago
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
- deleted 6y ago
  [deleted]
JumpCrisscross 6y ago
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 https://www.youtube.com/watch?v=PB-AyvgE8Ns
- geofft 6y ago
  > 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?
  - JoeAltmaier 6y ago
    I understood they never had it for video. Which was included in their claim. So there's that.
    - geofft 6y ago
      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.
bubblethink 6y ago
>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.
president 6y ago
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.
- angry_octet 6y ago
  Who says there is not an invisible Connector? They have the keys. You have to assume every Zoom call is recorded by Zoom.
CivBase 6y ago
> 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.
- paul_f 6y ago
  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.
  - CivBase 6y ago
    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.
pureagave 6y ago
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.
gfodor 6y ago
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.
- detaro 6y ago
  The article specifically states that they coordinate the key through their servers.
  - gfodor 6y ago
    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"
    - detaro 6y ago
      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.
      - gfodor 6y ago
        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.
dmitrygr 6y ago
"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?
- detaro 6y ago
  Are they classified as something falling under CALEA?
  - dmitrygr 6y ago
    yes: https://apps.fcc.gov/edocs_public/attachmatch/FCC-06-56A1.pdf https://apps.fcc.gov/edocs_public/attachmatch/FCC-06-56A1.pd...
herf 6y ago
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.

170 points by arvindch 6y ago

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

swixmix 6y ago
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/ 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 https://github.com/jitsi/jitsi-meet/issues/409
- f38zf5vdt 6y ago
  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
  - swixmix 6y ago
    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?
    - f38zf5vdt 6y ago
      It's free if you use their servers (https://meet.jit.si/ 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-docker/ 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.
- mtgx 6y ago
  Uh, I can't believe that their answer is "yes.....and our server has access to them." Which is it Jitsi team? You can't have your users' cake and eat it, too.
- ahendriksen 6y ago
  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/ 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."

hedora 6y ago

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.

prophesi 6y ago
It wouldn't be controversial if they explicitly stated that, and took "End-to-end encryption for all meetings" off of their features page.
cracker_jacks 6y ago
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?
- angry_octet 6y ago
  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.
jiqiren 6y ago

gumby 6y ago

I love that the address one issue and ignore all the other security holes. They have a structural problem with taking security seriously.

dangoor 6y ago
They had a separate post about privacy/security in general: https://blog.zoom.us/wordpress/2020/04/01/a-message-to-our-users/ https://blog.zoom.us/wordpress/2020/04/01/a-message-to-our-u...
techopoly 6y ago
Sounds like most companies. Which is even more concerning

prophesi 6y ago

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

netsharc 6y ago
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."
- deleted 6y ago
  [deleted]
robbyt 6y ago
"We never intended to deceive any customers when we invented a new definition of e2e encryption"
- Spivak 6y ago
  "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."

innagadadavida 6y ago

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.

liuliu 6y ago
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.
- jcrawfordor 6y ago
  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).
  - liuliu 6y ago
    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.
    - jcrawfordor 6y ago
      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.

wheelerwj 6y ago

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.

Thorrez 6y ago
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 https://news.ycombinator.com/item?id=22754699
- luckylion 6y ago
  > 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.
  - Thorrez 6y ago
    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.
- wheelerwj 6y ago
  > if you don't have any external connector attached, it in fact is end-to-end encrypted, It doesn't say that all.

tptacek 6y ago

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

geofft 6y ago
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)
- tptacek 6y ago
  I think you're right! I'm more interested in the double standard (and the dynamics of a pile-on) than the details.
  - geofft 6y ago
    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.
    - tptacek 6y ago
      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.

fierarul 6y ago

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.

f38zf5vdt 6y ago
When a product specifies "end to end encryption" my expectation is that the only function of the server is to pass the public keys from two clients around so they can Diffie-Hellman kx to achieve a mutually shared private key to encrypt their communications to each other, so that information flow is: client <--> client (no server knowledge of communications aside from the encrypted packets being passed back end forth) Not: client <--> server <--> client (server controls the encryption keys and can snoop on client communication at any time) Signal and Matrix Synapse/Riot is the former, Zoom and Jitsi are the latter. While it's true that the server could also MITM and provide false keys to each client, both Signal and Riot let you view the keys of the person you're communicating with so you can verify you're not being MITM'd.
- geofft 6y ago
  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.)

softwaredoug 6y ago

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

longtermd 6y ago
You’re right. The competitors make as bold claims ;)
tommoor 6y ago
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.
- angry_octet 6y ago
  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).
  - tommoor 6y ago
    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
    - angry_octet 6y ago

gregmac 6y ago

Zoom! What are you doing?! > To be clear, in a meeting where all of the participants are using Zoom clients, and the meeting is not being recorded, we encrypt all video, audio, screen sharing, and chat content at the sending client, and do not decrypt it at any point before it reaches the receiving clients. That is still not what "end-to-end encryption" means. From wikipedia[1]: > End-to-end encryption (E2EE) is a system of communication where only the communicating users can read the messages. In principle, it prevents potential eavesdroppers – including telecom providers, Internet providers, and even the provider of the communication service – from being able to access the cryptographic keys needed to decrypt the conversation. The fact that it's possible to decrypt is what makes this not "end-to-end encryption". Personally, I am totally fine with their implementation, I just wish they'd stop misusing the term. For the vast majority of users, everything being encrypted over-the-wire coupled with a reasonable policy (eg, employees cannot listen in on random meetings) should be totally acceptable. If there are people that that actually needed true end-to-end encryption and choose Zoom based on their marketing saying they had it, without doing validation, that's on them (though they're probably right to be upset with Zoom, too, for being misleading). Frankly, that set of people shouldn't be choosing anything they don't control and trust completely (code, hosting, updates, etc) which pretty much rules out any SaaS, so I suspect this set doesn't actually exist in the first place. Bottom line: Don't call it "end-to-end encryption" if you have access to the keys and can decrypt, even if you choose not to. Market that you encrypt everything in transit, and that employees aren't allowed to access streams. Be realistic in the potential weak points (someone hijacking or able to modify the Zoom infrastructure, PSTN interconnects, non-Zoom clients, etc) and what you do to mitigate those risks. [1] https://en.wikipedia.org/wiki/End-to-end_encryption https://en.wikipedia.org/wiki/End-to-end_encryption

kreetx 6y ago
This. They really should look into what end-to-end encryption means. As the parent says, they can implement their app however they please, but they should get their feature list straight.
- TwoBit 6y ago
  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.

stonewareslord 6y ago

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

deleted 6y ago
[deleted]

JumpCrisscross 6y ago

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 https://www.youtube.com/watch?v=PB-AyvgE8Ns

geofft 6y ago
> 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?
- JoeAltmaier 6y ago
  I understood they never had it for video. Which was included in their claim. So there's that.
  - geofft 6y ago
    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.

bubblethink 6y ago

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

president 6y ago

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.

angry_octet 6y ago
Who says there is not an invisible Connector? They have the keys. You have to assume every Zoom call is recorded by Zoom.

CivBase 6y ago

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

paul_f 6y ago
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.
- CivBase 6y ago
  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.

pureagave 6y ago

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.

gfodor 6y ago

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.

detaro 6y ago
The article specifically states that they coordinate the key through their servers.
- gfodor 6y ago
  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"
  - detaro 6y ago
    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.
    - gfodor 6y ago
      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.

dmitrygr 6y ago

"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?

detaro 6y ago
Are they classified as something falling under CALEA?
- dmitrygr 6y ago
  yes: https://apps.fcc.gov/edocs_public/attachmatch/FCC-06-56A1.pdf https://apps.fcc.gov/edocs_public/attachmatch/FCC-06-56A1.pd...

herf 6y ago

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.