Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zoom meetings aren’t end-to-end encrypted, despite marketing

theintercept.com

Post reply on HN
Print view View original

261–270 of 351 posts

Re: Zoom meetings aren’t end-to-end encrypted, despite marketing

#261

Post by jonny_eh »

lvh wrote: post #223
biggc wrote: post #216

Earlier quoted context omitted.

What is a BAA?

A BAA is a Business Associate Agreement. It's a standard HIPAA document where an entity with PHI (typically a Covered Entity, which is an entity specifically mentioned by HIPAA, such as e.g. a healthcare facility) effectively puts a vendor on notice: we may stuff PHI in your service, you agree to abide by this set of rules and regulations. A big one is that the vendor agrees to disclose when they've been breached, an…

PHI: Protected Health Information.

I figured someone asking what BAA stands for doesn't necessarily know all the other acronyms.

Edit: Fixed definition!

Re: Zoom meetings aren’t end-to-end encrypted, despite marketing

#262

Post by marcosdumay »

sarakayakomzin wrote: post #90
michaelt wrote: post #41

Earlier quoted context omitted.

1. Clients negotiate end-to-end encryption session key between themselves the same way as a chat app would. 2. Each client sends the server two (or more) encrypted video streams, varying in bandwidth and keyframes per second, with unencrypted markers showing where they can be sliced and joined. If you can upload a 1080p stream, chances are you've got the bandwidth to send a 360p stream too! 3. Each client tells the s…

a few problems: >Clients negotiate end-to-end encryption session key between themselves the same way as a chat app would. how are you doing this exactly? a 50 way diffie-hellman that renegotiates every time a user leaves or joins? How do you plan on doing that without any substantial lag? >2. Each client sends the server two (or more) encrypted video streams, varying in bandwidth and keyframes per second you have man…

> how are you doing this exactly?

A master node negotiates a symmetric key that lasts for the duration of the call. The master is either selected by the server or in round of Paxos, and since everybody has the same key, if he leaves it just needs a new round of negotiation.

Re: Zoom meetings aren’t end-to-end encrypted, despite marketing

#265

Post by zahllos »

mtthwn wrote: post #52

I used wire before is opensourced parts of the backend. I thought it was well designed and interesting. They claim to be the only video conferencing with end to end encryption that is opensource. https://wire.com/en/features/encrypted-voice-video/ Has anyone followed wire more closely?

Yes.

Firstly, classical VOIP including ones involving video have two stages: a signalling protocol called session initialization protocol (SIP). Secondly they have a real-time protocol, or RTP. SIP is used so that clients can find each other over the internet. If they can punch through their firewall, great. If not they might need help from STUN servers. Once done, the clients then talk to each other using RTP directly, not via the central server.

In the SRTP variant, this involves using DTLS, i.e. peer-to-peer TLS.

Wire does calling, except the SIP part is replaced by the existing messaging system they already have: the double ratchet. So if you want to call, that's just another end to end encrypted state of the art message exchange to signal that fact and agree a key.

The original RFC for SRTP isn't great and many of those options are still supported in implementations. Here's the RFC for SRTP: https://tools.ietf.org/html/rfc3711#section-4 . This document would likely result in tptacek banging his head so much on his keyboard that he manages to write a perl script capable of mind control that runs wild, turns on its creator and turns him into a PGP and DNSSEC loving zealot (presumably the motivation would be spite for having been written in perl). Or with a little less hyberbole, the crypto is a product of the times in which that spec was written, and we'd do better now.

I mean... NULL cipher? We have that option already. It's just plain RTP without the S.

According to this survey of SRTP security: https://tools.ietf.org/html/rfc7201 some sane options (AES-GCM and to a certain extent AES-CCM, but AES-SIV would have been better) are available, defined in rfc 7714. I have found this post from 2017 indicating that GCM support exists in the webrtc library: https://groups.google.com/forum/#!topic/discuss-webrtc/fz3kh...

I can't see any evidence in the codebase right now that there's any attempt to do anything custom with SRTP for Wire (SRTP used because of WebRTC), so, I assume that they're simply using whatever is available by default for video/voice as provided by Electron and/or your browser.

SRTP also leaks metadata all over the show: https://webrtc-security.github.io/#4.3.4.

I can't find any evidence existing audits have looked into the security of the voice/video protocol. They appear mostly to have focused on: a) the X3DH/Signal Protocol implementation and b) a high level audit of the whole application.

So far we're just talking point-to-point. Things get fun when you want group chat: do you a) establish any-to-any multicast (can be encrypted e2e) and let clients composite the video onto their (possibly low powered phone) screen or b) provide and RTP mixer (mitm), that needs the raw unencrypted video to combine it and provide a unified stream? Presumably Zoom opted for the latter; as far as I understand it Wire etc have opted for the former.

I don't own any Apple Devices so it's hard to look into their offerings, but MDG in the article states they've managed it. For Text, having copied Signal, Wire have some claim to be the most secure platform (or rather, one of them). However, I suspect that actually everybody in this space sucks really badly and nobody is actually looking into it.

In short, the security of text messages is about as state of the art as you can get. The security of video/voice, for _all_ "secure messengers", likely leaks a bit of metadata at best, and might use some funky 2000s era crypto at worst.

tl;dr they're using exactly the same standards for voice/video as everyone else, no secret sauce.

Re: Zoom meetings aren’t end-to-end encrypted, despite marketing

#266

Post by pthatcherg »

mox1 wrote: post #94
mabcat wrote: post #13

End-to-end encryption has been named as a required feature for telehealth in Australia. Interest in telehealth has gone from zero to infinity over the past two weeks for obvious reasons. So I've been trying really hard to work out if Zoom is E2E, and reached the same conclusions as the article. First, it isn't, and second, Zoom are really going out of their way to obscure that fact. It's great that The Intercept is t…

How do you E2E encrypt a video stream and still allow adaptive bit rates? If the server can't read (decrypt) the video, it cannot re-encode the video at different bitrates for different clients. Or the Zoom client has to encode multiple steams and upload them locally...or it just downgrades to the bitrate of the slowest client... You get shitty video and E2E encryption or good video and transport encryption.

First of all, there are 2 different kinds of video calls: 1:1 and group calls. For 1:1 calls, e2e encryption doesn't cause any problem at all.

For group calls, it depends on how it's implemented, but many group calls are implemented using what's called a Selective Forwarding Unit (SFU) and the sending clients send multiple resolutions (either independent, called "Simulcast" or dependent, called "SVC"). In that case, the adaptation is done by the server in selecting which resolution to forward at any given time. This is fairly common practice in the industry. For example: https://github.com/jitsi/jitsi-videobridge and https://tools.ietf.org/html/draft-aboba-avtcore-sfu-rtp-00 and https://www.w3.org/TR/webrtc-svc/.

For those types of group calls, the server only needs to know the sizes of the various streams and which packet is for what stream. It does not need to see the decrypted media, so one can implement e2e encryption for such types of group calls. This is less common in the industry, but is possible. For example: https://support.google.com/duo/answer/9280240?hl=en

(I used to work at Google on WebRTC, Duo, and Hangouts, but now work on video calling at Signal).

Re: Zoom meetings aren’t end-to-end encrypted, despite marketing

#267

Post by floatingatoll »

lvh wrote: post #244
floatingatoll wrote: post #172

Earlier quoted context omitted.

It’s certainly no less safe than the backdoored-for-decades phone/fax networks used by medical professionals to discuss medical secrets with patients and send prescriptions to pharmacies. It’d be nice if it was more safe, but it’s hard to sink lower than a telco line.

You can send faxes to someone without the telco running a local webserver on your fax machine, and you don't run thousands of other applications on your fax machine, and your fax machine doesn't usually come with a nifty record feature, nor a camera and a microphone.

I hesitate to point this out, but quite a lot of fax machines come with a microphone.

(And, noting the prevalence of articles from a few years ago talking about "update your fax machine firmware", I suspect you could fuzz their telco line-parser for very interesting results!)

Re: Zoom meetings aren’t end-to-end encrypted, despite marketing

#268

Post by prophesi »

SkyPuncher wrote: post #205
DCKing wrote: post #193

Earlier quoted context omitted.

You could argue whether the attack on Zoom is warranted. But don't start revising history to make your point. E2E has never meant that. There's no such "old notion". I can't find any sources saying HIPAA would use that deviating definition. Most sources I see use Whatsapp as an example, which is E2E under the proper definition.

> I can't find any sources saying HIPAA would use that deviating definition. That's because HIPAA does not define any implementation details. Google "Hipaa end to end encryption" and you'll quickly realize the Hipaa world uses a much looser definition than the security world. "End-to-end" in the context of Hipaa is typically used to indicate encryption (specifically SSL/TLS) of on-the-wire data through the entire req…

From the actual HIPAA regulations, one must "Implement technical security measures to guard against unauthorized access to electronic protected health information that is being transmitted over an electronic communications network."

Then you can follow along the official HHS guide[0] to see if you're abiding by these rules. If the intended recipient of your protected health information is another client, then SSL/TLS would not be HIPAA compliant. If the intended recipient is the server, then SSL/TLS is totally fine.

As a sibling comment mentions, your company shouldn't be using random articles found through a search engine for HIPAA advice.

[0] https://www.hhs.gov/sites/default/files/ocr/privacy/hipaa/ad...

Re: Zoom meetings aren’t end-to-end encrypted, despite marketing

#269

Post by pthatcherg »

bad_user wrote: post #43
mabcat wrote: post #13

End-to-end encryption has been named as a required feature for telehealth in Australia. Interest in telehealth has gone from zero to infinity over the past two weeks for obvious reasons. So I've been trying really hard to work out if Zoom is E2E, and reached the same conclusions as the article. First, it isn't, and second, Zoom are really going out of their way to obscure that fact. It's great that The Intercept is t…

End-to-end encryption is hard to implement, might cost more processing or bandwidth or storage (depending on the product) and does not yield benefits for companies interested in processing user data. If it's not clearly advertised on the front page, _emphasized_ and not a foot note, then it's NOT e2e encrypted. Example: https://signal.org

There are 2 different kinds of video calls: 1:1 and group calls. For 1:1 calls, e2e encryption incurs negligible processing and bandwidth. Do you worry about the processing and bandwidth increase when using HTTPS/SSL? Probably not. Same goes for 1:1 calls.

For group calls, it depends on how it's implemented, but many group calls are implemented using what's called a Selective Forwarding Unit (SFU). One benefit of SFUs is that they take much less processing for the server than the other kinds (where the video is re-encoded by the server). For those types of group calls, e2e encryption can be implemented with negligible increases to processing and bandwidth.

However, you are correct that it is harder to implement correctly. And it does prevent certain features to be added to the product, such as recording and server-based processing of information (for example, meeting transcriptions).

(I used to work at Google on WebRTC, Duo, and Hangouts, but now work on video calling at Signal).

Re: Zoom meetings aren’t end-to-end encrypted, despite marketing

#270

Post by closeparen »

jonny_eh wrote: post #261
lvh wrote: post #223

Earlier quoted context omitted.

A BAA is a Business Associate Agreement. It's a standard HIPAA document where an entity with PHI (typically a Covered Entity, which is an entity specifically mentioned by HIPAA, such as e.g. a healthcare facility) effectively puts a vendor on notice: we may stuff PHI in your service, you agree to abide by this set of rules and regulations. A big one is that the vendor agrees to disclose when they've been breached, an…

PHI: Protected Health Information. I figured someone asking what BAA stands for doesn't necessarily know all the other acronyms. Edit: Fixed definition!

Protected, not Personal.
Post reply on HN