The fact that they show end users (no pun intended) an "end-to-end encrypted" badge on the meeting window itself, and elsewhere explain how a Zoom server (not Zoom client) is what constitutes an "end" despite the whole rest of the electronic communication industry using "end-to-end" to refer exclusively to user agents, is bonkers.
Agreed. It's unlikely they stumbled onto an industry standard phrase like that alone, then innocently used it without knowing the generally accepted meaning. This is deceptive advertising.
This bothers me so much - as I have personally recommended zoom to many people and customers. People that have likely seen that I spend an unusual amount of time focused on computer security, backups, and care in communications.
If I remember correctly, zoom used to have on the front page - use this it's encrypted, and 'even used by us govt something-something' - so I assumed it was completely secure.
I actually refused to use other conference services much to the bemoans of many clients who already had other 'goto' software installed, used and understood - and convinced them that in order to talk turkey we needed to use the real secure zoom system.
It passed the smell test at the time for me because they also had paid plans which meant to me a legitimate business that did not need to slay privacy with ads and such, as they had a clear path to make money.
Now they are tarnished, and my reputation with several clients and doctors and others may be as well - as this is getting mainstream press (I think that's a good thing actually) - I'm livid about this.
I agree with below it is also fraud - and another commentator mentioned they changed to "your client connection is encrypted" is still deception imho.
Needs a big asterisk and real explanation of the lack of privacy.
I doubt non-technical users are savvy enough to find out about this problem and they probably won't remember to blame you for something clearly beyond your control.
I know it's the kind of thing that can randomly keep a person up at night, but I think you can probably safely forget about this awkwardness and move on.
Thing is - this story is all over the mainstream news. It's got multiple stories on the yahoo front page, it's reported via multiple sources in my fbook feed, but also with our regular tv news station.
People are seeing this about zoom that have never seen zoom.
People that I suggested use zoom are going to notice the word even if they would normally scroll past some gomeeting story.
any anyone who is within earshot of such 'non-tech news' is hearing how unsecure zoom is.
Sure most of my clients are unlikely to read HN at all, and most are unlikely to read tech crunch regularly if at all - but I bet some have TC or something similar in their fbook feed.
However people who don't even own computers are seeing this debacle.
So, anyone I've advised to use zoom for privacy and security, citing the encryption and use by US gov - is going to have to wonder - how do these things happen on a secure, private, encrypted system - must not be what it was purported to be by that guy Steve. Then they are going to wonder what kind of damage could be done with the info that was 'securely' shared with the service.
Because all the others I have been inspecting failed one of the big checkboxes almost immediately. Is it private? most no - skip. Is it easy to get started? the private private self hosted, not so much..
Zoom - private, encrypted, used by the us govt and easy to use.. So others trust and use, they have a firm business model - and a reputation not to lose. No others I found had this.
Sadly, my experience has been the opposite, because open-source stuff usually takes more work to run and is seldom as polished, and users hate that. I rarely, if ever, recommend open-source anything for end-user use. Zoom did well because it had the least hassle of any solution, hands-down. I'm not saying it's impossible to subscribe to a hosted open-source service that's as good, but it doesn't exist yet.
"Fraudulent", at least as far as I know, is reserved for "intentional deception". It could be that Zoom is indeed doing this intentionally, but without proof of it being intentional, I don't think we should assume so.
The IT guys in the industry know very well what constitutes an E2E encryption. Those two ends must be "trusted" which means it's either you yourself - your computer, or the other party which you want to talk to. Everything in between is third party and must get only encrypted data. If they redefine one of the "ends" as Zoom server, that's definitely intentional, blatant, and therefore fraudulent.
I'm not disagreeing that they are using E2E wrong, I fully agree with you there.
But just because someone uses a word wrong doesn't give you any proof about their intentions. See https://news.ycombinator.com/item?id=22767447 for further elaboration on that point.
Again, it's harmful to use words incorrectly, _especially_ when it comes to E2E, so they should rightly get flak for getting it wrong. You all seem to be so sure that it was intentional though, while I've seen the same problem so many times before in the industry without it being intentional. If you do have proof it's intentional, please share it with the rest of us so we can be on the same page.
Eh, haven't large companies leaked private details from their customers time and time again, in basic ways like forgetting that they have backups on S3 buckets with zero protection?
Being incompetent has nothing to do with the size or prominence of the company. Big/prominent companies fuck up/are sloppy all the time.
This is not a fuck up or negligence, Zoom deliberately used "end-to-end" with a completely different meaning than the rest of the world. I can't describe this as anything else than malicious and fraudulent.
Their intention was to deceive users that the communication was encrypted, when in reality it wasn't.
I guess you don't have experience working in a company with a marketing team that feel they can buzzword things in without checking with IT teams then.
I'm in no way saying it's impossible that Zoom did say E2E encryption while knowing that's not true, but I could imagine a scenario where a security person says "Yeah, we're encrypting connections to our backend" and a marketing person researching E2E and then saying to themselves "Yeah, sounds like we're doing E2E, let's write that", because this stuff happens all the time in the industry.
> Their intention was to deceive users
You sound so sure about their intentions, do you have any actual proof of this that others are missing? Again, I'm not saying it's impossible that their intention was to deceive users, but as an engineer, I always favor proof over guessing.
Not defending zoom here -- they done fucked up -- but there is a huge disconnect between the marketing folks and the technical folks. It's possible that E2E Encryption was something they planned on implementing but haven't, and the marketing department either didn't get the memo or didn't understand and still kept the wording.
If marketing misuses a term on the website because they didn't understand what it meant, that's their fault. If they listed a feature that hasn't yet shipped, that's their fault.
It's natural that there is a divide and marketing isn't expected to understand every engineering thing (nor the other way around.) If your job is to write words, though, you are responsible for the words you right.
That's not an excuse. Sooner or later it'll become a faux pas to mis-use basic security terminology. Obviously most of the public doesn't care about most of the terminology. But "end to end" has been trending for a decade at least.
I don't believe that's a thing. Thing like this will run over a lawyer's desk to make sure they're covered and won't get sued for billions of dollars, and they will make sure that it's legally sound, so they will check whether they have it, and they won't rely on "it's a planned feature maybe some day we will have it".
> 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.
The first problem is:
> Zoom currently maintains the key management system for these systems in the cloud.
Obviously, this compromises many of the benefits of e2e encryption. Having said that, it doesn't remove all of the benefits, and it's a (bad) precedent that has been set by other companies (eg. apple) where keys for end-to-end encrypted communication are backed up to the cloud.
The second problem is that Zoom has a second class of "client" called a "Connector" which runs in the cloud, and also has access to the keys for decrypting the stream. I definitely think that when one of these connectors is being used, it is false advertising to show the "e2e encrypted" status. However, there are clear technical reasons why these connectors are needed. Being able to dial into a meeting from an ordinary phone is important functionality that simply cannot support end-to-end encryption.
The interesting section to me is the later paragraph:
> 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.
In particular, being able to use your own key management system would make this truly end-to-end encrypted by any definition, even if you are still using Zoom's cloud infrastructure.
> other companies (eg. apple) where keys for end-to-end encrypted communication are backed up to the cloud
Backed up for iCloud users who might not know any better, but not backed up for people who take the time to learn how to guarantee the full protection of E2E by keeping iCloud off. The fact that the full benefit is available with little effort, albeit not obvious, creates a contrast to how:
> Zoom has never built a mechanism to decrypt live meetings for lawful intercept purposes
...but they easily could. Users can't just search for how to harden the Zoom encryption to the point of lawful intercept becoming impossible and find a simple solution the way they can with Apple.
> an on-premise solution exists today for the entire meeting infrastructure
...is not practical for most.
So, eliminating the E2E badge was the right move. The fact that it was there until now is shady.
It means that it's opaque to your ISP and other people on your network, which is at the very least useful for people using it at McDonald's or a university.
So, pretty much the opposite of all those people currently using it instead of going together to McDonald's or university?
On a more serious note, you would need to trust not one ISP if the video wasn't encrypted, but all the ISPs in the room simultaneously, and that is probably something even less trustworthy than Facebook.
They are using the same language as Apple talking about iMessage and FaceTime. Apple talks about end to end encryption, but one end is iCloud which is why you can get your messages simultaneously on all devices.
There is a big difference there though. In transit, iMessage and FaceTime backups are end-to-end encrypted, it's just the iMessage backups on iCloud that also store the key.
FaceTime chats, though, truly are end-to-end encrypted and the calls aren't backed up like iMessages are.
They merely mention that backups to iCloud happen automatically by default, and not that doing so means the default is that Apple can view and decrypt all your messages.
That's not true at all. iMessage is really end-to-end encrypted.
Two options impact it: "Messages in iCloud" re-encrypts and uploads messages to the user's iCloud account and stores the key in iCloud Keychain (also end-to-end encrypted).
Only when enabling iCloud backup will that key be revealed to Apple.
Yeah, the parent conversation was about whether iMessage is end-to-end encrypted. GP claimed that it cannot be due to it supporting multi-device sync, which is not true.
The quiet part is "American citizens of Chinese descent can't be trusted". This is as obvious of a dogwhistle as when people "innocently" point out that the CEO of some maligned Wall Street firm is Jewish and I have no idea why it's getting upvotes on this site.
This is not true. Don't spread FUD. Apple does not have the ability to read your messages. All messages stored on their servers are encrypted with keys that live only on the phone.
iMessage doesn't store your decryption keys on Apple's servers unless you opt into iCloud backup which is a whole different service and security concern.
Most people use iCloud backup. Even if you don't, your messages are still sent to Apple by the recipient. And Apple prohibits third party backup services.
> Apple does not have the ability to read your messages.
iCloud backup is an Apple service and it has the ability to read most of your messages even if you don't use it, which makes this statement categorically false.
This is completely ridiculous. iMessage is encrypted by my device and remains encrypted until it gets to the recipient device. That is what end-to-end encryption means.
That I may have given Apple my private key through a different message in no way affects that end-to-end encryption, because it is trivial to decide not to give Apple that key.
iCloud isn't some separate entity from iMessage. It's all Apple. And you have no option to use a different cloud backup provider.
You can decide not to give your keys to Apple, but you can't decide for all your friends to not give their keys to Apple, and the result is the same: Apple can read your messages.
And the marketing is so misleading that hardly anyone knows that Apple can read most iMessages.
Sorry, let's be explicit here, as you seem intent on muddying the issue. Where, other than the endpoints, is the message decrypted when people use iMessage? Your succinct answer to that will clear this up for everyone.
On GCBD's servers in China. Possibly on Apple's servers in the US if they are running a wiretap. Due to the way key distribution works for iMessage, it is trivial for Apple and GCBD to do so.
Your message, through several layers of indirection, relies on a security conference paper from 7 years ago[0] + the assumption that Apple haven't updated the protocol in 7 those years.
No, my message relies on the fact that people have been looking at iMessage for years, and nobody, least of all Apple, has said that the implementation changed in any way to prevent Apple from viewing the messages.
Here is another article from 2016, which shows that Apple patched iMessage to prevent attackers who don't have access to Apple's servers from reading the messages but still kept the ability to read the messages themselves. https://blog.cryptographyengineering.com/category/imessage/
Apple was aware that people knew it could decrypt iMessage messages this entire time, but Apple made no changes that would fix that. That should give you some idea of whether Apple intends to ever fix that.
Apple can, of course, do whatever it likes, up to simply recording the screen and sending that to weird & wonderful government agencies. Like almost everything in mainstream security, it comes down to who you trust. It doesn't mean it isn't E2E though.
E2E encryption simply means that messages are only decrypted at the endpoints. That certainly isn't true of iMessage in China, and it might not even be true for some users in the US — we have no way of knowing because the protocol makes no guarantee against it.
So basically the first and second parties themselves need to do all encryption and decryption without any help from the third party running the service. Which is the age old usability issue famously holding back the casual adoption of PGP. Hard enough with text... To do it with video conferencing would be quite the feat. Someday, though.
I have linked it several times in this thread. Here it is again:
"If you have iCloud Backup turned on, your backup includes a copy of the key protecting your Messages. This ensures you can recover your Messages if you lose access to iCloud Keychain and your trusted devices."
Only Apple can know exactly when or where or how often they decrypt people's messages from their backups, because once they have the keys they have the means to do it at any place and time, for any reason, without anyone's knowledge or consent.
What we know is that they can and do decrypt iMessages from iCloud backups in response to law enforcement requests[1]. This proves that they hold the keys, if their own support pages weren't enough evidence for you.
And even if none of that were the case, couldn't they just push out an update to the app or OS (just to the target, so other researchers debugging or watching traffic wouldn't know) which would cause the device to exfiltrate the cleartext anyway? Or always have had said feature?
"If you have iCloud Backup turned on, your backup includes a copy of the key protecting your Messages. This ensures you can recover your Messages if you lose access to iCloud Keychain and your trusted devices."
Let's not use sarcasm or sources..... Let's puzzle it out.
You don't use a password to encrypt your iCloud backups... They're specific to the hardware your backing up. If you have an itouch for example it's backups are separate from your phone.
So now you have these backups in the cloud and you lose your iPhone, you remote wipe it.
Now your new one arrives and you restore from backup... Your iMessage private keys are available to apple unencrypted .... Because you didn't need to provide a second factor of authentication for unlocking the backup you were just asked which one to use.
Apple and any reputable nation-state can read your iMessages with a subpoena ... If you use iCloud backups and not local backups with a password.
2) What about your iCloud account and password that are required to encrypt, store, access, and decrypt the backups there? Is that not a factor worth consideration?
Your password is not a factor worth considering. You can ask Apple to change it. That means they have the ability to change it. That means they have access.
This is both true and false. Apple stores keys on the device so they can't read your old messages, but say they want to start reading messages of a particular user, they can simply issue a new key and store it on the device and the server and start decrypting the new messages using it.
This is why WhatsApp for example notifies users when the key of the recipient changes, and they give you a way of verifying that the both keys at both ends are identical.
Tuxer said "keys," not "your decryption keys." Apple distributes the public keys that each party encrypts their message with, and they route the encrypted messages through their servers. They can trivially eavesdrop on conversations by simply providing a key from a key pair they generate to a participant and reencrypting messages using the other parties' public keys after deciphering the messages.
Yes, it does. The messages are 'end to end' encrypted in the iMessage service, but then iMessage backs up its encryption key in the iCloud backup service, defeating the point.
"If you have iCloud Backup turned on, your backup includes a copy of the key protecting your Messages. This ensures you can recover your Messages if you lose access to iCloud Keychain and your trusted devices."
That is true of any end-to-end solution. If you back up your private keys, anyone who has access to your backup would be able to access the encrypted messages. Remember, you can turn off iCloud backup if you're worried about Apple accessing your keys.
Ultimately, it's false to equate iMessage's encryption scheme, which is end-to-end, to an encryption scheme that requires a server to relay decrypted data.
Utterly false. Real end-to-end encryption would encrypt the backup with a key that is not available to the backup service (e.g. derived from a passphrase not sent to the server).
Of course this system has better usability, which is why Apple does it. But it's still a farce to call a system where Apple has the ability to decrypt the majority of messages "end-to-end" encrypted. The fact that it's through the backup servers instead of the iMessage servers makes no difference.
What's more, it's possible to do better without sacrificing usability. For several years Android has been end-to-end encrypting backups using the user's lock screen passcode, with protection against brute force attacks provided by hardware secure elements. https://security.googleblog.com/2018/10/google-and-android-h...
> The fact that it's through the backup servers instead of the iMessage servers makes no difference.
It makes a big difference. If I print out the texts I receive, it doesn't change whether the texting program is end-to-end encrypted. The same goes for backups. An unencrypted system-level backup doesn't mean that the program being backed up is failing at security.
It's bad that Apple doesn't let you encrypt your backups properly, but it's a separate issue.
What if the texting program has a built in feature to print the texts you receive and mail a copy to the company that wrote the program, and it nags you to enable this feature all the time, and most of your friends have it enabled? Because that's a lot closer to the scenario here.
> An unencrypted system-level backup doesn't mean that the program being backed up is failing at security.
iOS programs can choose how their data is backed up. iMessage isn't just getting its data stolen by iCloud accidentally. These backups are a feature of iMessage as much as iCloud. And besides, iCloud is made by the same company, it's not a separate entity.
> Would you say that no desktop app that saves its key can ever qualify as end-to-end encrypted?
I would say that no app can qualify as end-to-end encrypted if a large fraction of users send their data to the maker of the app in a form that can be decrypted by the maker of the app, regardless of the reason.
Turning off iCloud backup is not a genuine choice, because it means you lose everything if you lose or break your phone (there is no other way to back up your phone except iCloud backup, Apple does not allow third-party phone backup services).
There’s a good HN thread from earlier this year about that, but basically, you can disable iCloud Backup and enable Messages in the Cloud, so that all of the messages are still backed up and synced between your devices but the keys are not, so that Apple can not read them. Then you can back up to your Mac/PC instead.
But most end-to-end encrypted apps aren't configured by most of their users to send their messages and encryption keys directly to the author of the app. iMessage is.
Feel free to trust who you want but I don't think Apple should be able to get away with calling iMessage end-to-end encrypted when they have most iMessages stored on their servers and the keys to decrypt them.
> At some point you have to trust somebody, right?
It's possible to use an actual end to end encrypted app that doesn't have the keys to read your messages stored on their servers.
I think this article is a bit over my head, but if Apple never has possession of users' private keys, how are they able to recover iMessage conversations when a phone is lost/stolen (which I know they can do)?
