Zoom meetings aren’t end-to-end encrypted, despite marketing
theintercept.com
theintercept.com
It's great that The Intercept is taking a look at this, because it's absolutely beyond the capabilities of healthcare practitioners and the professional bodies to get to the bottom of. There's a ridiculous amount of confusion here, compounded by "you need to get the HIPAA version because HIPAA means privacy".
https://www.newscientist.com/article/2140747-laws-of-mathema...
"“The laws of mathematics are very commendable, but the only law that applies in Australia is the law of Australia,” said Turnbull.
Turnbull’s comments came as he proposed a new law to force tech companies to give security services access to encrypted messages."
"The UK home secretary Amber Rudd has previously called encryption “completely unacceptable” and the UK prime minister Theresa May has said that the big internet companies give terrorists “safe spaces” to communicate."
Going to have to get over this first :/
Ironically, the UK government in fact uses Zoom for all its meetings depsite privacy and security implications. Saudi Arabia, take note.
Ref: https://www.businessinsider.com/coronavirus-boris-johnson-zo...
Of course, in the UK, calling Tory back-benchers "a little silly" is an understatement.
What if Huawei was Russian, would it still be "a little silly"?
(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!)
That depends entirely on whether the handset is physically disconnected by the on-hook switch, or if a firmware exploit could remotely enable it.
Threat modeling a fax machine in the era of fuzzing-RCEs is a particularly interesting thing to consider.
"we have a high concentration of research and development personnel in China, which could expose us to market scrutiny regarding the integrity of our solution or data security features"
[0]: https://www.sec.gov/Archives/edgar/data/1585521/000119312519...
But note that if you have an Australian employee (unless they are a sole trader / contractor) you must already have an Australian subsidiary of your company (for tax and superannuation reasons).
Don't get me wrong, I am absolutely opposed to this legislation and think it is a draconian overstep of government power which (despite the PR spin doled out by the government) was absolutely not necessary for effective law enforcement. But it's best not to fall into the trap of overstating what the law actually allows the government to do.
Yes, IIRC she also said wanted to enter a dialogue about this "with the people that know the right hashtags"!
Heh, that reminds me of the Indiana Pi Bill[0], where the state tried to legislate the value of pi to be 3.2.
WhatsApp does claim that videos are end-to-end encrypted as well, although given Facebook announced they'll implement client-side agents for processing user data and given its proprietary nature, I avoid WhatsApp for anything very sensitive as well.
To the best of my understanding, they say that it is https://support.google.com/a/answer/7582940?hl=en
EDIT: On rereading they actually just say that it is encrypted, not neccesarily end-to-end encrypted.
Perfectly fine...
>SHA-1
You missed the important bit:
>SHA-1 HMAC
Also perfectly fine...
SHA-1 is deprecated but it's good enough for this application for the near future.
Disclaimer: Working at Google, in the same org as Duo.
https://www.kbv.de/media/sp/Liste_zertifizierte_Videodiensta...
Discussing your heart disease or skin condition is sensitive, but it's not as sensitive as discussing deeply personal thoughts or inner monologues.
Private consultations not billed through public insurance is not quite as regulated though.
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
A OTP might be mathematically simple, but logistically it's very hard - you have to safely distribute the key and that key must be at least as long as the message you're passing.
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).
Anybody know much about that one?
TIL: there is a quality below SD.
If your doctor is on the free plan, it is highly pixelated, and because they offer a hippa-compliant free plan, most providers are on the free plan.
They had a 3-4 hour outage recently. Assuming because of the number of new free users.
[1]: https://www.wired.com/story/australia-encryption-law-global-...
It looks like the situation has not been fully thought through and the government is creating a Kafka trap when its laws.
No. My assumption is that certain communications are required to be end-to-end encrypted, unless the individual is under surveillance. All end-to-end encrypted communications providers are required to have a mechanism in place for disabling and MITMing e2e communications. It stops being e2e encrypted for the duration of that surveillance.
I suppose it's possible that a foolhardy government (I'm not Australian, so I can't say for sure what they've done) would word the laws in such a way that they can't technically be achieved, but there's no reason why they have to be. The laws aren't bad laws because they are logically impossible to fulfill (if they are), they're bad laws because they violate the individual's right to privacy.
Note that the law might also prohibit the government from surveilling communications between patients and licensed health professionals. In that case it would be quite possible to mandate no-exceptions e2e for those communications, and a mechanism for disabling e2e. e2e that is never disabled is always e2e.
The law didn't contemplate that you would use a service but not want that service to access your data.
Not in the phrase "end to end encryption", which is specifically used to refer to schemes and services where the service provider does not have the ability to access the communications (a-la Signal).
If that wasn't the case then any site with TLS would be called "end to end encryption".
> The law didn't contemplate that you would use a service but not want that service to access your data.
This law in particular does. The only restriction (relevant here) is that TCNs must not result in the creation of a "systemic vulnerability". The meaning of this term is not outlined in the legislation -- my understanding is that it is meant to mean something like "backdooring OpenSSL and thus making most of the internet insecure" rather than "backdooring all communications using a particular service provider". If that understanding is accurate, then it's a meaningless restriction.
You can't operate an E2E encrypted communication service in Europe without breaking the law.
caveat: I'm not sure whether this has actually been adopted/ratified by either the EU or member states yet.
This lets the tech company comply with the law, without the tech company itself gaining access to the plaintext.
So use a solution that doesn't put a company in the middle. Use open source, E2E encrypt with keys secured by the user and not central server and you are good. One solution available now - Signal.
Despite the heat being laid on Zoom, they have no choice. Any platform that does mixing to produce a composite image with Picture in Picture like Zoom does has no choice. That includes Hangouts, Skype and so on. They do it to save bandwidth - something I've been grateful for.
Possibly you can save on BW by server processing - far from "no choice" however.
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.
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).
Suppose you have a block of 4 pixels, represented by 4 24-bit values. Instead of sending the 4 pixel values, send one 24-bit value that is the average of all 4 pixel values, and then the actual 24-bit values for 3 of the 4 pixels. The receiver can figure out the 4th pixel from those 3 and the average.
Send the average values and the groups of 3 discrete pixel values in logically separate streams, separately encrypted.
If something transporting this needs to lower the bandwidth, it can just drop the E2E discrete pixel stream, leaving just the E2E average stream. The receiver can then use that average value for all 4 pixels, in effect getting a video that is 1/2 the resolution both horizontally and vertically.
This scheme only gives you two rates: Full resolution and 1/2 x 1/2. No doubt you could do systems based on block sizes other than 2x2, and with multiple levels of averaging, that would give a wider range of fall backs.
Actual state of the art video encoding is, I believe, based on things like the discrete cosine transform, which represents an image as a sum of cosines of various various frequencies.
In this kind of representation the higher frequencies correspond to higher resolution detail in the image. I'd expect that you could do an E2E transmission scheme were you have different encrypted streams for different frequency ranges. Like with my far less sophisticated or clever 2x2 averaging scheme above, you could simply drop the streams for higher frequencies and the receiver would be able to reconstruct a lower resolution image, but unlike my 2x2 averaging scheme this would have much finer drops in resolution.
So you still send 4*24 bits? what's the point?
> If something transporting this needs to lower the bandwidth, it can just drop the E2E discrete pixel stream, leaving just the E2E average stream. The receiver can then use that average value for all 4 pixels, in effect getting a video that is 1/2 the resolution both horizontally and vertically.
But you need knowledge of this protocol, so the sender is the only one able to do this. In that case just encode the downsampled resolution and send that, no tricks needed.
It's that server that wants to be able to dynamically downgrade outgoing feeds based on the bandwidth between it and the meeting participants, which can vary from participant to participant.
Alice, for example, might be on a symmetric gig fiber connection with consistent and low latency. Her client can send a high resolution feed to the server. Bob might have no trouble with receiving that, but Carol might be on slower, less stable connection, and need a lower resolution version.
If you aren't trying to do E2E encryption, you can handle this by having the server deal with taking the high resolution feed from Alice and generating a low resolution feed and then sending the other participants whichever is the best version they can handle. That works because without E2E encryption the server actually has access to the video, so it can do things like resample and re-encode.
If you are using E2E though then the only parties that should have access to the video itself are the meeting participants. The server should not have access to the video except in encrypted form.
The problem then is how to encode and encrypt a video stream in such a way that a server that is copying that stream between a sender and one or more recipients can alter a copy of the stream in such a way as to reduce the resolution even though it does not have access to unencrypted video?
A couple of nits to pick:
> in Australia. Interest in telehealth has gone from zero to infinity over the past two weeks
Slight exaggeration; wouldn't you call the royal flying doctors service telehealth? And HIPPA is a US law.
Nit: HIPPA is not a US law, but HIPAA is. ;-)
Touché! I'm even HIPAA trained and have to deal with it all the time yet I chronically make that error. I can't even see it when proof reading. Ouch.
Basically, if you are a family doc that's been thrown into the telehealth ringer, you can get started with everyday tools for video chat, like Facetime, Google Hangouts, Skype, etc - regardless of that tool's Hipaa compliance.
Overtime I do expect they'll want to see providers transition to compliant solutions, but they understand thousands of doctors, some of whom have never delivered telemedicine, can't simply audit and on-boarding a new provider overnight.
[0] https://www.cms.gov/newsroom/fact-sheets/medicare-telemedici...
edit: Server-client communication does need to be encrypted which zoom does.
Even though a lot of online sources suggest BAAs are only for Covered Entities, that's not strictly speaking true. The standard form document doesn't require the buyer to certify they're a CE. It makes tons of sense for vendors of CEs, themselves bound by BAAs, to bind _their_ vendors to BAAs! If there's a decent chance your customers put PHI in your service, there's a decent chance they put PHI in your support system, and they don't really care if your support system is something in-house or Zendesk when that happens. There's also a good chance that PHI might end up in your logging system, and from there in your Slack instance, and... before you know it everyone's signed a BAA with everyone.
The life-hack consequence for that is that you can just collect BAAs from anyone who will sign them and now you have disclosure timeline guarantees.
I figured someone asking what BAA stands for doesn't necessarily know all the other acronyms.
Edit: Fixed definition!
depends on your definition of "guarantee".
what you really have is externalisation of risk.
A contract which defined how protected health information will be dealt with by the provider and how HIPAA provisions will be followed (ie: provider will do X but you need to do Y to be compliant).
https://www.hhs.gov/hipaa/for-professionals/covered-entities...
Not that you shouldn't, of course. And you better have an excuse for not doing it (e.g. we don't re-encrypt after the load balancer terminates TLS is a common one). But doctor's offices fax stuff to each other all the time, and that certainly is not encrypted. Perhaps you're thinking of a HITRUST control?
(Minor nit: HIPAA, not HIPPA.)
Generally, Hipaa does require transport encryption from the client to the server processing the request. The importance here is SSL/TLS should be terminated at the app server.
I believe this is a similar problem with financial trading systems with ETS.
If this is e2e to the physicians home, how does the telehealth system do all these add in functions?
At least in the US, the requirement have been understand to use secure transport everywhere. Folks keep on saying HIPPA requires e2e but I've literally not seen anything that looks like that out there in the actual market for this - the enterprise paying the big bucks usually wants features that are incompatible with e2e as far as I can tell.
How is this "clear" that it is not E2E?
This is hard.
So even if Zoom is E2E, this is checkbox compliance. (if my assumptions are correct for the reasons behind it)
https://zoom.us/docs/doc/Zoom-hipaa.pdf
> Meeting data transmitted across the network is protected using a unique Advanced Encryption Standard (AES) with a 256-bit key generated and securely distributed to all participants at the start of each session.
It does not guarantee that the key is withheld from the server, which is unsurprising given that e.g. the recording and chat history features are implemented server-side.
EDIT: For comparison, the Australian government provides a telehealth platform that clearly states it does not allow the server to inspect the call video/audio:
https://help.vcc.healthdirect.org.au/about-healthdirect-vide...
> Data shared in actual calls between participants is only ever available in decrypted form to the participating endpoints of the call. All other intermediaries that forward the call can only see encrypted data.
For those looking to hold Zoom accountable, the question to ask is: “Does your country’s law permit Zoom’s servers to be considered an ‘endpoint’ capable of decrypting a telehealth call?”.
https://support.zoom.us/hc/en-us/articles/207652183-HIPAA-Bu...
Sure, they're legally in the green perhaps. But this is not E2E, it is not the decades-long definition of E2E, and this is ultimately deceptive marketing.
> Matthew Green, a cryptographer and computer science professor at Johns Hopkins University, points out that group video conferencing is difficult to encrypt end to end. That’s because the service provider needs to detect who is talking to act like a switchboard, which allows it to only send a high-resolution videostream from the person who is talking at the moment, or who a user selects to the rest of the group, and to send low-resolution videostreams of other participants. This type of optimization is much easier if the service provider can see everything because it’s unencrypted... This isn’t impossible, though, Green said, as demonstrated by Apple’s FaceTime, which allows group video conferencing that’s end-to-end encrypted. “It’s doable. It’s just not easy.”
Group videoconferencing is inherently centralized through a server that needs to analyze video/audio not only for signals as to who's talking, but also mix normalized audio and re-encode streams not just for lower thumbnail resolutions, but for clients with different bitrates.
I don't doubt that FaceTime finds a way to do this, but everyone is using Zoom instead because its performance is way better. I'm not entirely sure that all the necessary signal processing can be done performantly client-side, especially when you're allowing for a wide variety of endpoints (WebRTC, phone calls, etc.). You certainly can't mix encrypted audio (at least to the best of my knowledge?), for instance, which means increased bandwidth to everyone to handle overlapping speakers (someone interjecting "could I just say something?" while two other people are talking).
Also, handling key management for groups of people where you don't have the bandwidth to re-encrypt the stream separately for each receiver is very complex too, and in the end you're basically just going to have to trust that Zoom itself can't access the keys. Because usually Zoom will be able to, so that it can handle phone dial-ins.
But regardless... while Zoom should absolutely advertise full encryption, Zoom should absolutely not advertise end-to-end encryption. That's bad, and harms user trust in security overall when advertised technical terms become meaningless.
Which is why, when I was consulting, I did not promise these things, nor did I say things that could be easily misunderstood to imply them.
It's not ideal for a number of reasons.
https://www.howtogeek.com/fyi/daily-news-roundup-mac-exploit...
> Worse yet, uninstalling Zoom doesn’t remove the web server. The web server can reinstall Zoom on its own as well. So if you visit a malicious link, it can reinstall Zoom, join you to a call, and start your webcam, all without any interaction from you.
What the &@$##!! How long has Zoom been around, how did it become popular (or did it ever), and why are people still using it?
I've resolved to not using Zoom - when it was suggested at work I just posted links to the issues (mostly gotten from HN actually) so we decided against it.
The Intercept didn't care about Zoom a few months ago and wouldn't have without Corona.
The 2019 Zoom vulnerability[1] was a much bigger deal and did get picked up by the media. Zoom already had a terrible reputation before COVID-19.
Now the issues are a smaller deal but are still being picked up.
Most people I work with haven't even heard about Zoom until those last months when they've been forced to use a teleconference for the first time in their lifes. They also probably didn't even hear about the issue last year too.
You may not be convinced even after you attributed to my argument but it won't change anything about the facts.
Edit: since I can't post in god knows how long due to the wonderful stfu tech here on hn here are sources for german media:
https://www.google.ch/search?q=zoom&complete=0&source=lnms&t...
It's all over and I find it very curious that you've not been able to find anything in Danish media even though it looks the same for the english speaking outlets.
I searched around a little and neither this nor the recent Facebook story have been covered by Danish non-tech media at this time.
EDIT: The story is still new, it might get coverage later this week.
They just were not as popular as they are these days which makes them much more newsworthy and which is why we're seeing constant new articles about them now about issues that have been there for a long time but which were not newsworthy a few months ago.
Edit: no, I'm not defending them. I just explain why they are all over the news these days.
This is what people need these days and this is why Zoom is so popular.
And to be honest, most business stuff is by unencrypted e-mail, so I don't see how a TLS encrypted Video Chat increases their exposure.
Finally, the chance of someone, even zoom, recording and analyzing all the video conferences ever to somehow get important info from a video conference seems pretty low anyway. Unless you're worried about the NSA, and even then, it seems like they'd have a way into WebEx etc also, so even on risk.
At this point, it seems reasonable to go by what works for people. And Zoom works.
But privacy is not about those privileged enough to where privacy doesn't matter.
I don't care that you don't care. Privacy matters.
I was part of a startup Sococo some 8 years ago. We had end-to-end encryption right out of the box. Plus video, document sharing, chat. All encrypted, end to end with rotating keys. Up to 100 people in a meeting, sharing and chatting indiscriminately.
Its gone now, and the new folks are starting way down the feature ladder from where we were. It's disappointing. Now its 'good' if you can get 6 in a conference.
I hear Zoom can support large meetings. So they may be doing something right.
You could see a virtual layout of rooms and where you could knock and see who was in which room. It was such an innovative approach and a wow moment that is really rare. I miss Sococo until today and have never found anything like it again.
I got to know your CEO over dinner in Boston and am not surprised he threw it all under the bus. My boss at the time who introduced us tuned out to be a major scam artist who got rich peddling grey market pharmaceuticals online but claimed it was from selling a pre-web chat/gaming platform to Murdoch - he was also infamous for being the main investor of StartCom which we all know what happened to them (WoSign). The 2 guys got on like a house on fire.
Also, resilience thru network changes and weird packet behavior. Back then we encountered home routers that would drop 50% (every other) UDP packets! And reorder UDP, which is very much better to survive and recover than to drop.
As I recall, our product would let you walk around with your laptop, roaming from Wifi to Wifi, plugging and unplugging your wired connection, and it would switch seamlessly to the new network, all streams intact.
That was a cool product. Sigh.
Yesterday by comparison half the people on a Skype meeting had to dial into an audio bridge with their cell phones because their computer audio didn't work for no fucking reason, and screen sharing kept lagging unless restarted every so often.
The good marketing for zoom is that webex is awful.
100% this. We switched to zoom as stay home orders came out. And only because it worked 100% every time, with little to no fiddling. The non-tech literate employees at my place are patting themselves on the back for being able to set up and host a zoom meeting. Because it's one button.
And that's why they're used so much. They are the literal definition of it just works. People aren't worried about anything else right now.
Engineers code shitty apps to fill requirements. Lie to project/product managers about what is complete, or have a "good enough" attitude. Managers communicate to marketing that Zoom is end to end encrypted.
What do people like about zoom?
Schools like it because it can handle hundreds of participants in a single meeting and you can pay for extras to handle over a thousand.
I tried multiple other tools over time, zoom was the first one where all attendees had it working on all systems without problems.
1. It's actually cross-platform:
- Still can't use Webex across Linux, Windows and Mac in 2020.
- Same goes for Skype, plus half the users who have Skype don't realise it's Linc and the two are completely different.
2. It's far more bandwidth efficient than things like Slack.
The codecs are much more resilient, this applies (from what I can tell) to all the embedded options that are just using the browser.
3. It's going to be around.
- Google Hangouts has previously been renamed and deprioritised. They also dropped their low-bandwidth codecs and cpu usage went through the roof in my personal experience.
I'm unclear on some of the items against Zoom. But there's a lot of hate and emotion around it in the last 10 days - my sense is that some people have an axe to grind - I'm always cautious of a crowd with pitchforks.
No extra software to download, no jumbling around with meeting codes, no "are you the meeting leader" bs. Straightforward and simple UX.
The “pitchforks” are people who pay attention and do not trust Zoom for established reasons. We are now forced to use it because I guess business in 2020 requires the ability to look like you’re on a beach in your sweat pants.
Have you tried just running webex in a browser? Works fine for me on Chrome in windows or linux
Instead I think it's that Zoom is better: easier to join, it can show you more faces at once, more controls for the meeting owner, lower CPU usage, etc.
(Disclosure: I work for Google, speaking only for myself)
Crazy theory, so just hear me out for a second. Maybe the fact that they do some things that violate security is the reason that "it just works". I'm not saying Zoom shouldn't do better here, I'm just saying that there are probably legitimate product/business reasons.
From Steve Yegge's platform rant:[0]
Like anything else big and important in life, Accessibility has an evil twin who, jilted by the unbalanced affection displayed by their parents in their youth, has grown into an equally powerful Arch-Nemesis (yes, there's more than one nemesis to accessibility) named Security. And boy howdy are the two ever at odds.
But I'll argue that Accessibility is actually more important than Security because dialing Accessibility to zero means you have no product at all, whereas dialing Security to zero can still get you a reasonably successful product such as the Playstation Network.
Hangouts hides people in meetings with more than about 5, so psychologically you don't even realise they are there.
Like it's fine to point out that the bar has been raised in the security community and that the term E2E now requires that only the participants be able to decrypt the content and they should change their copy but it ignores the fact that E2E in healthcare means exactly what Zoom is doing. In the HIPPA world providers are trusted entities.
Do you have any links for E2E being used in this "older" way?
E2E encryption was always clearly defined as "only the two communicating parties can access the information". Using the term "E2E encryption" in other ways is deliberately confusing. Edit: and pretending that E2E encryption meant something else in some unspecified past is revising history.
No, thanks.
However, I think the real value of mitm is more to do with redistribution of streams and muxing to reducing total bandwidth over that required by a full e2e encrypted p2p mesh. I.e one upload vs one per peer (although this could also be done with e2e encryption with multiple recipients and simply routing through the service) and potentially a single download too (depending on how the muxing is done), rather than one per peer (but this couldn’t be done with e2e encryption).
Then the other client can download the video via the same e2e tunnel.
However, I take issue with your opening ad hominem abuse. People are looking for abuses of trust. That has nothing to do with “being mad at zoom.” That has everything to do with uncovering dishonest behaviour that is detrimental to the industry.
You positioning it as some kind of emotional crusade does a disservice to people who care about important matters like informed consent.
All that being said, the factual information you shared is valuable, and I thank you for it.
“All Zoom communications are encrypted-in-transit. We do process them on our servers to provide features like X, Y, or Z.”
Would they lose even one sale if they said this?
That is the literal meaning of the phrase "end to end"... There is not much room for ambiguity there
I interpret end-to-end encrypted to mean only the participants have access to the content, the intermediary couldn't spy on my calls even if they wanted to. This appears to NOT be the case with Zoom.
This is not the case. End-to-end encryption was popularized as a computing term in the 90's with PGP, and it meant that when sending eg email messages, no computer or server in the middle could decrypt the content. Only the the personal computers of the sender and recipient could. The computing field always used the term that way.
If you think about the expression "end-to-end", it carries its own meaning. The only way you could become confused about this is by exposure to totally crazy marketing spiel that will sell you black as white.
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.
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 request process. Practically this means on-the-wire data needs to be protected all the way to the underlying app service.
For example, if you're running Rails with Docker. SSL/TLS transport needs to be present all the way to the container. A load balancer (or other device) is allowed to terminate/re-encrypt as long as on-the-wire data remains protected.
Several people have tried to "google it" and tried to find alternative definitions of end-to-end encryption in the context of HIPAA and have so far failed. If end to end encryption really does mean something else in the context of HIPAA, what is your evidence/source?
The problem is people are trying to find definitions for things that Hipaa literally doesn't define. You won't find a definition for "end-to-end" because Hipaa doesn't actually define it. "end-to-end" is an implementation detail. Hipaa does not define or green-light implementations.
This is both a blessing and a curse of Hipaa.
On the blessing side, it means companies can use tools they see fit and follow industry best practices as long as they can demonstrate the compliance of those tools. This is great because it means companies don't need to wait for Hipaa to explicitly say "you can now use TLS 1.x" or "this widely accepted algorithm is cool for disk encryption".
On the curse side, it means there's no explicit guidance and a lot of leeway. It's on individual companies to demonstrate their implementation patterns are secure.
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...
Trust me. I am not. I'm simply trying to demonstrate colloquial usage of the term within the Hipaa community.
> 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.
This is not correct, though. Both of those use cases CAN be fine. They can both also NOT be fine.
* Client-to-client (assuming we're talking about a computer client) over SSL/TLS is completely fine if the usage case allows for it. You don't need a server involved to exchange ePHI.
* Conversely, client-to-server does not automatically make the use case allowable.
And sorry, I meant client-to-client with the assumption that there's a server between the two. And sure. I think it's safe to assume that SSL/TLS is perfectly fine for a client-to-server situation. But like I said, let the company read the actual regulations and consult their IT team.
I guess when they're being one of the most popular video conferencing platform right now, it invites attention. Doesn't help that people are Zoombombing, and their privacy track record certainly does not help.
I mean, nice new unicorn, but very shady dealings ala Facebook. Not a good look.
https://en.wikipedia.org/w/index.php?title=Section_230_of_th...
In what context is E2E used within HIPAA in any other context than "not accessible by intermediaries"?
Having no experience with HIPAA but plenty with PCI DSS, where E2EE is used only in this regular sense, it is easy to find public HIPAA compliance checklists which are very explicit about the end-to-end part and hard to find anyone that would allow Zoom-like uses.
Also surely one of the limitations here is technical / usability. One of the big features of Zoom is transcoding streams from all manner of devices and sending them to all manner of devices. Doing this on the fly is still computationally demanding and not feasible for consumer devices (or the E's in the true E2E model).
It’s how the outrage made operates
Having been a really happy user of Zoom for more than couple of years - I have referred many friends to use it succesfully. Despite that it looks like Zoom has legit issues that are surfacing. However I have to say it cannot be ruled out there might be some negative PR going on too since I can't help see using any Zoom alternative! Everything else pretty much sucks.
It puts the negative reporting on all other tech companies that start to see success in context.
If you have a level of technical sophistication, you can see the shades of grey in all security. So maybe this usage of E2E can be overlooked in HIPAA or other threat contexts. But a wider array of people, including senior decision makers in sensitive organizations believe that E2E means ‘gooder’. :)
When I look at it through this lens, I’m not comfortable with the implications of their marketing message. I’m not sure this makes Zoom a demon, but I definitely trust them less as a result. Is that reasonable or am I overreacting to something? If I am, I would love to know where I’m wrong!
So if you ever encounter a system that has the ease of use feature where you don't have to verify the identity of the other participant(s) with something like a identity fingerprint number then you already know you do not have all the protection that e2e encryption can provide. This is particularly relevant in a case like Zoom, where all the data goes through servers that Zoom controls making a MITM attack trivial.
So we really should of known that Zoom doesn't provide complete e2e encryption already just from the lack of the identity check.
Skipping the identity verification step seems to be common these days. Even Signal does that by default, but they at least make the verification of what they call "safety numbers" fairly easy and straightforward.
Added: So can true e2e encryption ever be practical for conferences involving a large number of participants? Perhaps Zoom is claiming the impossible... The issues surrounding the addition of OMEMO encryption to XMPP conferences make for an entirely relevant example. What do you do if one of the participants is not known to all the others? There are lots of possible answers to that question.
Added2: >The only feature of Zoom that does appear to be end-to-end encrypted is in-meeting text chat.
I don't see how this can be true either based on the same thinking.
It means only that you don't know for sure who the other party is. You are only put at risk if there is an active MITM attack in progress.
Depending on your threat model that's an enormous change.
Web of trust can give an illusion of scaling because it uses sleight of hand to persuade you to accept transitivity of trust. If you see someone who took this seriously you'll find that almost all contacts show as "unverified" (when I've had PGP setups in the past that's what happened). If they just click blindly along accepting trust transitivity then everything is "verified" but based on trust beliefs that have no basis in reality.
The sleight of hand goes like this. You trust Alice. Alice says this is Bob and she trusts Bob. The correct inference is that this is indeed Bob (Alice says so and we trust her) but we still don't trust Bob. PGP tries hard to persuade you that you in fact now trust Bob. Bob says another contact is Carol, and he trusts Carol. The correct inference is null, we don't trust Bob so we don't care what Bob says. But PGP encourages us to accept that this is Carol and we should trust Carol too.
Many conference 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 conference 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).
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?
Wickr.com is another similar service that claims to be end-to-end encrypted, but again I haven't seen much about them at all.
It would be nice if The Intercept and other journalists would include these actually E2E-encrypted alternatives besides the Mac/iOS-only FaceTime.
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.
Don't have real E2E encryption? Don't say you do. Don't wave away a giant security vulnerability as "a feature". Don't explain monitoring and tracking as something you need to do for advertising when you don't show advertising.
Their product may be superior in quality compared to the competition but their Marketing and PR teams comes across as bush league at best.
The only incident I can give them any credit for is the Facebook reporting. They handled that well in my opinion by admitting the problem existed and immediately resolved that issue.
Kloudless is currently promoting security solutions on their twitter timeline.
I'm not really seeing how this is relevant or how the post is justified. People edit their profiles all the time, and have a right to. It's up to them what they want to put in there. This comment seems to be crossing into personal attack and a mild sort of doxxing. Please don't go there on HN.
Also, please don't repost comments that were flag-killed (https://news.ycombinator.com/item?id=22738656).
The first one was about an advertisement pixel, which everybody is doing but for some reason surfaced only for Zoom.
The second one is end-to-end encryption, which is not expected at all for VC apps. NOBODY does it!
According to the article Apple does end-to-end encryption for video conferences. Also other providers are not lying about it like zoom does.
Irrelevant. That as nothing to due with the fact that they say they are. Zoom is being completely dishonest, and as some other commented here, some orgs like in health care area, have E2E encryption as requirement, Zoom says they have, but don't. It's literally fraud.
"Achieve HIPAA (signed BAA) and PIPEDA/PHIPA compliance with complete end-to-end 256-bit AES encryption."
2. end-to-end has several meanings, for users it means what Signal does, for machines it means TLS is securing edges.
Google Duo does.
1. https://support.goto.com/meeting/help/security-faqs-g2m05001...
Most devices now do video encoding/decoding in a dedicated hardware unit, so those additional streams will have a vastly disproportionate impact on performance and power consumption. Some desktops and high-performance laptops support multiple streams, but most mobile devices don't. It's feasible, but very much non-trivial.
But i am happy theres media attention for this exact topic because it was dishonest all the time and people have chosen zoom over other solutions because zoom is the only one claiming end to end encryption.
From the Jitsi Meet README:
> WebRTC does not (yet) provide a way of conducting multi-party conversations with end-to-end encryption. Unless you consistently compare DTLS fingerprints with your peers vocally, the same goes for one-to-one calls.
WebRTC uses an external signalling channel to negotiate ICE candidates, codecs, and necessary information to establish a media communication. Once this is done, the visio/audio conference is P2P and encrypted from the caller to the callee: how is this not E2E? (Genuinely curious, not criticizing)
That is, if you're not using a TURN relay server, which is easy enough to know.
Maybe you meant that multi-party (one-to-many or many-to-many) calls are not E2E. Again I'm not too sure I understand: it is possible to have multi-party conf calls: each participants can encrypt its media stream and send it to the N-1 other participants. Obviously this costs a lot of CPU (for multiple encryption) and a lot of uplink because the same stream is sent N-1 times. But it is __possible__, and certainly viable with only 3 or 4 participants, provided people have a decent connection (WebRTC uses adapative bitrate streaming [0] to compensate for bandwith usage).
Then again, I know that generally, with WebRTC people would use MCU [1] when dealing with many-to-many conf calls, and then I agree it breaks E2E. But for the other mentioned cases, WebRTC is E2E, isn't it?
Again, I'm genuinely curious about this, not trying to criticize or undermine.
Thank!
> WebRTC does not (yet) provide a way of conducting multi-party conversations with end-to-end encryption. Unless you consistently compare DTLS fingerprints with your peers vocally, the same goes for one-to-one calls. As a result, your stream is encrypted on the network but decrypted on the machine that hosts the bridge when using Jitsi Meet.
> The Jitsi Meet architecture allows you to deploy your own version, including all server components. In that case, your security guarantees will be roughly equivalent to a direct one-to-one WebRTC call. This is the uniqueness of Jitsi Meet in terms of security.
But the web standard not being there yet doesn't prevent someone from making a mobile or desktop app with e2ee conferencing, like Duo does: https://support.google.com/duo/answer/9280240?hl=en.
(I used to work at Google on WebRTC, Duo, Hangouts, and WebCodecs, but now work on video calling at Signal).
[0]: https://wire.com/en/ [1]: https://github.com/wireapp [2]: https://medium.com/@wireapp/video-conferencing-end-to-end-en...
https://twitter.com/matthewchampion/status/12449891398896640...
This is important because the company could be compelled to release such videos if subpoena'ed, or they could also simply be hacked.
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 server which other call participants they'd like to see, and the server sends them the appropriate encrypted streams, switching between low and high bandwidth as appropriate.
>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 managed to double your egress for almost no value.
Only compared to the current, unencrypted version. For E2E encryption, the alternative, as I see it, is pushing out an encrypted video stream per recipient. He has reduced his egress from O(n) to O(1).
By doing whatever Signal and Whatsapp do to support 50-person encrypted group chats.
> you have managed to double your egress
Not at all.
Firstly, the whole point of having two streams is to accommodate viewers with different bandwidth requirements, so the second stream will be a fraction the size of the first. If I'm already uploading HD video at 5 Mbps, and I start also sending an SD stream at 1 Mbps, my egress has risen by only 20%.
Secondly, the h264 spec provides for 'Scalable Video Coding' [1] where a high quality stream can have a lower quality 'subset bitstream' allowing a high-quality video to be converted to low quality by selectively dropping packets. So your egress might not rise by even 20%! Although this h264 feature is less widely used, potentially raising engineering costs.
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.
The real test is peer-to-peer or not.
I think that's the problem being described. That is not end-to-end encrypted. It is, however, encrypted.
Zoom simply needs to drop the "end-to-end" part.
Basically you would join a meeting by going to zoom.us/meeting-id-number#secrethashtag
The "secrethashtag" is never sent to the server, but can be accessed by javascript on the client end. Im not sure if this would be acceptable for security nuts though, as I am sure they would make the argument zoom could insert some nefarious js to intercept the url fragment.
It's not a standard. If you want compliance to a standard then create/adopt/require one. When you go by marketing materials all you have is "Trust us, everything will be fine"
The encryption that Zoom uses to protect meetings is TLS, the same
technology that web servers use to secure HTTPS websites. This means
that the connection between the Zoom app running on a user’s computer
or phone and Zoom’s server is encrypted in the same way the connection
between your web browser and this article (on https://theintercept.com)
is encrypted. This is known as transport encryption, which is
different from end-to-end encryption because the Zoom service itself
can access the unencrypted video and audio content of Zoom meetings.
If Zoom implements proper E2E like Facetime, would it be more laggy, less able to handle meetings of more than 50 people, etc.? Will the general user experience degrade noticeably?
Why did zoom suddenly become so popular? It's not like there's a shortage of options.
From what I understood it only saves your own private messages in the log. So the only time you could get in trouble is if you exported the log and then shared the file with others without removing your private messages. So just like you took a screenshot and didn't censor the parts you wanted to keep hidden.
Hardly the massive scandal that some people on Twitter seemed to try to make it.
Edit: now that the title has been modified, I feel I need to add back context. Zoom claims to support end-to-end encryption when it doesn't. That is dishonest.
Secure and reliable
End-to-end 256-bit AES encryption, data sovereignty, and role-based access control"
Right on the front page. So, it would seem dishonest, yes.
Not excusing Zoom here—they should know better.
If you think about it for hosted services that provide non-trivial functions for your data, you'd see the definition of e2e we apply to messenging apps would never apply.
For some reason, the title was trimmed an hour after submission to omit the "misleading marketing" part.
The ranking also appears to have artificially been lowered. Now it is below some other posts that are older and with fewer points.
It was posted around 08:00 UTC. In my experience it is generally very hard to get traction for a post that is posted before ~14:00 UTC. This is a site with lots of US users, and it’s still early on the west coast (07:18 PDT).
This post managed to climb to the top despite that, probably because Zoom is a company that is interesting to techies, the article is from a well-regarded news source (at least in this crowd), it covers misleading marketing, it’s a bit related to Covid-19 and it also touches the topic of E2EE.
#2: https://imgur.com/a/qgKQWxU
Sudden Drop to #13: https://imgur.com/a/6beWUHG
Who expected that? There are so many privacy concerns with zoom... not surprising they don't encrypt meetings.
"The following in-meeting security capabilities are available to the meeting host: Secure a meeting with end-to-end encryption"
https://web.archive.org/web/20200331095358/https://zoom.us/s...
Edit: I do not understand the reason for the downvotes. I am not defending the practice but am just describing their potential line of explanation. Please let me know explicitly if my comment is technically incorrect. Also, I would be interested what other vendors claim, who probably use similar technology under the hood.
I believe zooms reputation as being more likely to 'just work' in part hinges on that,