31

During the COVID-19 pandemic, many of us are working from home using meeting apps like Zoom. It's all over the news that Zoom is lacking in its E2E encryption. Let's assume we're using Zoom and can't switch apps.

Considering only the traffic, how can we make these meetings secured/encrypted?

The solution can be hard on 1 group (the company using Zoom) but should be easy on the users (employees of the company). My 1st thought here is to have the company set up a VPN server (in the company or with a 3rd party) and have everyone connect to the VPN before joining a meeting.

13
  • 4
    To downvoters: Please leave a comment explaining why you think this question doesn't show any research effort, is unclear or not useful.
    – user163495
    Apr 9, 2020 at 11:41
  • 16
    "secured/encrypted" against what threats? VPN only addresses a part of the problem. What problem do you want to solve?
    – schroeder
    Apr 9, 2020 at 11:53
  • 3
    I did not understand VPNs and models with 3rd parties enough when I asked this question... Apr 9, 2020 at 12:59
  • 5
    Ultimately, if you're really worried about the video conferencing app, either find a more respectable provider or host your own. There are a few self-hosted video conference solutions out there, such as Jitsi. I have not used these so I cannot recommend anything yet. Apr 9, 2020 at 13:17
  • 2
    Both ends must talk in code Apr 9, 2020 at 20:58

4 Answers 4

73

You cannot magically secure applications like Zoom without changing the application and the infrastructure it relies on.

The missing end-to-end encryption you want to have fixed is due to the basic architecture of Zoom, in which media streams are processed and mixed together on a central server (which is owned by Zoom). Only this architecture actually allows it to perform well without stressing bandwidth and CPU of endpoints when many users are involved. With E2E instead the requirements for CPU and bandwidth at each end would grow linearly with the number of users and thus would quickly overwhelm clients.

These kind of restrictions apply to any video conferencing solution. This means that you will not get real E2E with any other solution too, at least not if you want conferences which scale to many users without having excessive requirements regarding bandwidth and CPU power. The best you can get is that you control the central mixing and forwarding server yourself and thus don't need to trust a third party.

Even the broken AES ECB mode could not be fixed without changing application and infrastructure since the server actually expects the encryption to be a specific way and if you change it the communication will fail.

Usage of a VPN would not magically solve the problem. The data would still need to be processed on the servers owned by Zoom.

19
  • 9
    @nick012000 That’s not E2E. And also requires Zoom to support your chosen method of encryption at their end - which they won’t. Remember that people want a way to video-chat with groups of people WITHOUT Zoom being able to see the contents of the stream - which reduces Zoom to being just a “dumb” packet-router (I.e. you could replace the video-chat stream with an arbitrary file-transfer stream and they wouldn’t be able to tell) - in which case just use IPv6 with IPSec and a simple P2P streaming app (can’t easily use IPv4 with home users due to NAT). Zoom’s value is in their convenience.
    – Dai
    Apr 10, 2020 at 2:06
  • 2
    @TheD: "Zoom’s value is in their convenience." - that's only one value. The other value is that Zoom is actually mixing the data for which it needs to access the streams. But without this mixing every endpoint would need to receive all audio and video from the current participants which means bandwidth requirements for each endpoint increase linearly with the number of streams and CPU must be able to handle all these streams too. This site has a good comparison of Mesh vs. SFU vs. MCU architecture for conferencing. Apr 10, 2020 at 8:20
  • 3
    @TheD: A MCU merges the media from all endpoints, so the bandwidth and CPU requirements on each endpoint are independent from the number of participants. In your proposal the requirements on each endpoint are still dependent on the number of participants, no matter if multicast or not. Multicast does not make any difference on the endpoint, it makes only a difference on routers shared by multiple endpoints. Basically your proposal is better than a dumb mesh but it still has more requirements to the endpoints than a MCU. Apr 10, 2020 at 9:37
  • 1
    @FedericoPoloni: I think you've missed the point of the question. This is about somehow fixing the insecurity of Zoom without changing the app and while providing the original functionality. Your idea either makes changes to the app necessary or does not longer provide the functionality. Apr 10, 2020 at 19:55
  • 1
    You could have an E2E encryption video call by sharing a key between all connected clients. Only the key-exchange between those needs to be scaled by number of participants, not the actual encryption of the video. (Of course, if you want a server to mix data together and doing stuff like "show the video of whoever is currently speaking big, and the others small", then it doesn't work without the server having the key.) Apr 10, 2020 at 23:43
5

TL;DR: Specifically for Zoom, take a look at Zoom Meeting Connector

First off, to get it out of the way, encrypted is not the same as secure, and secure can be vague depending context.

As schroeder♦ have commented, you need to be clear on what you are actually trying to achieve, what threats you are defending against. Only then you may determine if a solution really solve your problem. It might turn out E2E encryption isn't what you actually need, or want. And like Steffen Ullrich said, you can't just magically add that without significant changes to both its application and infrastructure.

Fortunately, in the case of Zoom, there is a relatively easy way out (depending on you actual needs). Zoom allows you to run your own server for streaming audio and video, while still using Zoom server for other management tasks.

(From https://support.zoom.us/hc/en-us/articles/201363113-Meeting-Connector-Core-Concepts)

Zoom offers a public or hybrid cloud service. In the hybrid cloud service, you deploy meeting communication servers known as the Zoom Meeting Connector within your company's internal network. In doing so, user and meeting metadata are managed in the public cloud while the meetings are hosted in your private cloud. All meeting traffic including video, voice and data sharing goes through the on-premise Zoom Meeting Connector.

Meeting connector

This way, the conference data stays in a server you control. Even if you makes call from outside internal network, the traffic is still encrypted in transit and only decrypted on (your) meeting server. Deployment should not be difficult for a corporate IT team, though might be challenging for laymen. If you want the privacy of E2EE, this is about as close as you can get without actually changing the software or rolling you own service.

2

While it is not possible to make E2E encrypted connections with Zoom, your company can probably use an open-source and self-hosted solution like Jitsi. It encrypts the connections between the participants and the server, and only the participants and the server will have the data unencrypted.

So, because you can host the server wherever you want, if you control both the clients and the server you control your data.

Of course, if you use an instance that you don't control, you have to make trust in the instance owner. Similarly, if you use Zoom Meeting Connector , you still have to trust Zoom to not leak - voluntarily or not - your audio. (not saying they will - that's just a possibility)

(From a usability point of view, Jitsi is quite similar to Zoom, although not as feature full, but it works really well)

-4

A somewhat trite answer - don't use zoom's native software..

Instead - look around for the "dial-in number" and call the meeting using a regular telephone.

Downsides, you won't get the video stream, and the user creating the meeting has to be in credit and a paying customer. These are not available in the free accounts.

https://support.zoom.us/hc/en-us/articles/201362663-Joining-a-meeting-by-phone

Also consider that other participants in the meeting may remain vulnerable, so your words could still become exposed. And any meeting recording will carry your input too.

10
  • 6
    That does not provide E2E either. The audio is still centrally processed by Zooms server. Apr 10, 2020 at 5:24
  • 7
    Moreover the incoming call is trivially snooped for an analogue landline, easily snooped for a digital one, and relatively easily snooped these days for GSM. So this makes security worse than Zoom over IP rather than better.
    – abligh
    Apr 10, 2020 at 7:43
  • 16
    Other ideas along the same lines: Don't use Zoom at all. Don't use videoconferencing software. Don't try to communicate with people outside your home. Just don't say a word anymore. People won't hear what you are not saying. Problem solved.
    – Relaxed
    Apr 10, 2020 at 8:09
  • 2
    What threat is this supposed to address? Why is the phone number supposed to be better? You do not explain that part at all. And since it is all going to Zoom anyway, I'm not sure there is a benefit when the OP is considering the transmission as the subject under threat.
    – schroeder
    Apr 11, 2020 at 20:24
  • @Relaxed that's a separate answer, not a comment on this answer.
    – Criggie
    Apr 12, 2020 at 1:18

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .