Google introduces end-to-end encryption for Gmail on the web
bleepingcomputer.com
bleepingcomputer.com
Previously you’d need an expensive third party product like Virtru, so it’s great news for users that this is just a bundled feature now.
“Security theater” is probably fair, as is much of the compliance regime. However this probably does make it harder for a back-office admin to accidentally/absentmindedly save files with PII to their machine in breach of policy, as the UI makes it clear the files/content are Top Secret.
The client side encryption/decryption process is described at https://developers.google.com/workspace/cse/guides/overview
If I got it right, Google generates a key and sends it to the external service that stores the keys of the user. That service uses a Google API with probably Google's and the user keys [1] to encrypt the message (and this is quite disturbing, imagine if every company would require key management services to use its own API - Office365, Apple, second tier mail providers, etc.) and finally Google stores the encrypted message. Similar procedure to decrypt.
At a first glance Google is not able to see the message, except that they provide the browser to most people and the OS too (Chromebooks and especially Android.) However we're back to monitoring the network packets for suspicious traffic to Google.
What I'm more concerned about is regulatory capture through compliance. If E2E messages become the new normal either clients like Thunderbird (desktop) or K9 (mobile) implement an interoperable E2E system or more sooner than later it will be impossible to use them to mail customers and maybe friends too. And uncountable IMAP / POP3 / SMTP libraries for a lot of different languages: they eventually have to display the message and encrypt it before sending it.
Of course I'm all in for encrypted email but let's hope everybody can jump on it no matter the mail client they use. I'd hate that the only choices left will be GMail, Apple and Office365 (if they'll be able to talk to each other.)
[1] https://developers.google.com/workspace/cse/guides/encrypt-a...
I think you are fundamentally misunderstanding what these regulations are. Regs get defined, then someone makes sure that the boxes are checked.
They are not the same thing as (often being orthogonal to) having a strong security posture, that being far too dynamic and technical to encode in regulations.
See https://latacora.micro.blog/2020/03/12/the-soc-starting.html for discussion of SOC2, which should give you an idea of what we are talking about.
First, that would require the regulating body to actually now what security is and how it works in the real world, in real companies.
Then, it would require having an open mind regarding the risks and forget about 30 years of long gone history. If you look at ISO27002 (derived from the British BS-7799 30 years ago) you will note that it addresses very general ideas without a link to the reality of the field.
If we had 5 rules that address real-world issues we would be light years ahead. Something like "a patch from teh vendor must be applied within 24 hours" (yes, one in a blue moon it will break things and slow down some fantasy "quarter end"), "MFA on all accounts used by humans" and 2-3 more like these.
Just ask the people doing actual security 9-12 and then "compliance" 13-17, two totally disconnected activities.
I don't understand the hype around end-to-end encrypted software where you have to trust the organization behind the software to not steal your data through their complete control of the endpoints.
E2EE has value in the case where it (at least in principle) allows you to remove something from the list of trusted entities. Signal on the desktop is one such case, where E2EE lets us avoid trusting the Signal organisation.
Besides, they can afford better lawyers than Signal.
Take the case of WhatsApp. Without E2EE, you have to trust the platform (Apple) and the people behind the app (Facebook). With E2EE, you still have to trust Apple, but you also still have to trust Facebook, since Facebook controls the endpoint and you have no insight into what it does or if there are any back doors. The same applies to Signal obtained from the App Store or (AFAIK) Google Play. And Apple's E2EE stuff is obviously not adding anything, since we're already trusting them as the OS vendor.
Something like Signal on the desktop is different though. There, we still have to trust the OS vendor, but we and anyone else can inspect the source code, verify that it does what it's supposed to and doesn't have any back-doors, compile it for ourselves, and then we can exchange messages without trusting Signal. In the case of Signal on the desktop, E2EE lets us distrust the Signal organisation, which has value even though we still need to trust our OS and our hardware.
You could argue that we should trust the Signal organisation. That's not unreasonable, but that still makes E2EE no better than normal client-server encryption a la TLS and the promise of a solid no-logging policy.
(We could also discuss the feasibility of verifying that there are no back-doors purely from reading source code and how well a back-door could be hidden. But that's sort of a tangent.)
https://github.com/signalapp/Signal-Android/blob/main/reprod...
It is doable.
Telegram has a procedure you can run to verify the binaries, also from the Apple App Store.
Yes, it requires a jailbroken phone, but it is doable.
(But unlike Signal Telegram also haven't been caught with glaring zero days or caught sending images to anyone except the intented recipient the last fee years.)
Point-to-point-encrypted means it can theoretically[1] be read by the vendor (Telegram in this case) or anyone who can coerce the vendor. This is the standard for mail, online banking etc.
The reason for providing both end-to-end-encrypted and point-to-point-encrypted is that point-to-point-encryption is significantly simpler, which makes it easiee to create useful and or cool features.
[1]: vendors can do a nunber of things to make it hard/next to impossible for employees and others to access data, like for example restricting access to user data to service accounts, only allow debugging access in special circumstances and auditing such debugging access.
Telegram used to claim they solve it by sending/storing encrypted data through/in different data centers from the keys, and keeping these days centers in different jurisdictions. Done properly should mean that two or more employees across the company would have to conspire to get access to customer data, or two or more judges in different countries would have to demand data.
But unlike with end-to-end-encryption we have to take their word for it.
My most understanding reading is that you mean Telegram receives the data in plain text at their servers.
That reading implies that they don't do this whole "encrypted data one way, keys another way" thing. (If we know they don't do that I am interested in knowing.)
But a number of people here on HN will read it as "Telegram sends data unencrypted", which is definitely incorrect.
Even if you trust Telegram's e2e it's not on by default. Secure chats are second class and missing lots of features (plus glitchy, I lost multiple entire chat histories), so almost no one uses them.
I have not seen anyone postin any reason to not trust their end-to-end-encryption, so this shortens to a criticisms of point-to-point-encryption, which is (abd I'm feeling generous here) as about as useful as criticism of postcards.
Note, I'm not going after you but after the HN tradition of trashing Telegram.
It doesn't require breaking e2e either to make an impact, since no one I know uses secret chats on the regular anyway
Durov claiming in 2014 to assist Russian government in fighting 'extremism' (we all know what it means) is enough for me. I couldn't find any debunking, clarification or walking back those words.
As for closed groups I think they claim they don't have access and police have to get someone on the inside.
As for cooperating with Russian authorities in particular, Telegram has a history of open confrontation with Russian authorities, and for a long time had to maintain a proxy network for Russian residents.
Today we also see that both Russians and Ukrainians use Telegram to reach out, but I suspect at least Ukrainians use something else between themselves.
That Russians and Ukrainians use Telegram is the exact issue here! Tons of my fellow Russians and I imagine most Ukrainians use Telegram to exchange statements that literally make them extremists or just criminals in the eyes of Russian gov, the very gov Durov declared collaboration with to get unblocked in the country where TG has the most users, they do it every day and without the impaired secret chats feature.
How do you think the secret chat is impaired?
Source on this? Signal can't even send messages to users with their phones off. Telegram (like WhatsApp) will buffer the message on the server (to the best of my knowledge) and can relay that message quite some time after. Signal clearly provides E2EE chats and group chats, so I'm not sure why that's stated here. For point-to-point, my understanding is that the functionality is extremely limited here and that you can't actually chat. That's what I found googling anyways. While Signal doesn't have this, there is an open feature request for something like this[0], but traction is often low on topics like these. Maybe if HN users were as passionate on Signal forums as they were here we'd get more of these features? Who knows. Devs may just ignore those too.
> But unlike Signal Telegram also haven't been caught with glaring zero days or caught sending images to anyone except the intented recipient the last fee years.
I'd actually like a source on this. I'm not aware of any Signal zero days... ever. Or hearing about Signal users receiving wrong messages. I have heard about several zero days with Telegram though.
That is exactly what Signal has done for years (if not from the beginning?). It's why there's a distinction between one vs. two checkmarks on a sent message:
https://support.signal.org/hc/en-us/articles/360007320751-Ho...
You can use another to run it on for daily use.
(I think it's not likely to be the case but if we are going all the way then it is what it is.)
Yes, eventually you'll be unable to install the latest versions of some apps on your increasingly-older-by-the-day version of iOS, but presumably some recent-enough version of iOS is jailbreakable at all times.
I mean different versions of the app can be shipped targeting different iOS versions, in which case it'd be a race.
At this point (attacks can only be done against users of the newest versions of the OS, and you still risk getting caught, squandering the whole operation) I say I cannot see how it is worth it.
On both phones the keyboard software "listens" to what you type, how else would it function?
Is there a reason Google and Apple couldn't change their deploy flow to pull from a git repository? As in:
1. Developer pushes to a specific remote (or pushes a specific tag or branch)
2. Apple/Google run the build on their systems, sign it, etc
3. If passed, the app deploys and the published app is annotated with the specific git hash (which can also be displayed in the app store)
For open source, it gives the public verification ability.
For closed source, it is still useful for internal verification. I work adjacent to some mobile teams and most still do builds on a developer's desktop and upload that. I am working towards getting CI for everything, partly to reduce dependence on any one developer's system (eg: I hear things like "Only Tom knows how to do builds to give to Apple, but he's out today") and partly for security. As much as I believe we don't have developers with malicious intent, there's still no way to know that a build uploaded from a developer's desktop really is what's in source control.
Because doing so isn't something they'd realistically care about. They'd still have to maintain the existing flow for closed-source apps (the vast majority of them) that don't want to give outside parties access to their source code, so this would just mean more work for them.
Another big downside is that app authors would not be signing the final product with their own keys. That would have to be done by Google/Apple, so authors would lose a bit of control over future distribution of their app.
[0]: https://developer.android.com/guide/app-bundle/code-transpar...
However, you have reduced the attack surface to the organisation distributing a signed and compromised version of their software to your phone. This is much less likely than any admin in the company looking at your stuff, or anyone who can hack into the company.
Don't let the perfect be the enemy of the good.
After thinking about it for a bit, I find that argument rather convincing in the case of Signal: very few people would be in a position to add code to the distributed binary without it ending up in the git repo. So with E2EE, we still have to trust the organisation overall, but we don't have to trust any individuals with access to the servers, and the open-source nature lets us avoid trusting any of the individual app developers other than the person/group responsible for producing the final binaries.
It's slightly less convincing in the case of WhatsApp or this GMail thing though. You don't have to avoid a back-door ending up in the git repo, you just have to make it past code review. So in that case, with E2EE, we still have to trust the organisation overall, we have to trust the individuals with access to the app source-code, but it lets us avoid trusting any individuals with access to the back-end.
Still a win I suppose. Just a pretty far cry from how I usually see it advertised, which is more like "thanks to E2EE you don't even have to trust them".
And just to be clear, Signal says that they try to reduce the trust on them to as little as possible. Not zero trust/trustless. They sell "low trust" instead.
I don't understand what "low trust" means. It makes sense to talk about removing trust for individual employees in the organization, but when we're using a client distributed as a binary with no way to verify the source code used to compile it, we're forced to place 100% of our trust in Signal as an organization. Is that "low trust"?
Your messages are only as secure as the least secure part of the network. In an absurd example, that other client could take your messages and publish all conversations straight to Twitter in the public. Effectively rendering the encryption pointless. While this is an absurd example, there are things people do that aren't drastically different, including unencrypted plain text backups.
> I don't understand what "low trust" means.
Trust isn't a binary option of: I trust this person/thing/group vs I don't trust it. There is a spectrum. The question is not "do you trust x?" but "how much do you trust x?" This is more obvious with people you deal with in your daily life. There are people you trust with some things but not others. I am willing to bet that you don't have two sets of people in your life: those that you're a complete open book with and those you are a closed book with. You share different pages with different people and this is okay. Signal's mission is to read as little of that book as possible while maximizing your security and privacy. That is low trust. I'm actually not even aware of a zero trust system in existence. All the ZKPs I know still require a trust in the setup process, so aren't completely trustless. Either way, you still need to trust that things aren't improperly implemented. Even if you check it yourself, you have to trust that you yourself didn't make a mistake. Trust is not binary, but a spectrum. There is no global optima and we need to be aware of the trade-offs being made.
Wait, are you talking about malware clients now? Because the original example was a client which does what its user wants to. Nothing can save you if the human at the other end wants to do something evil with the messages you send them, you don't need to use a modified client to share screenshots on Twitter.
> [The trust thing]
I suppose I don't see what the difference is though. Signal has complete control of the app, which means they have full access to all my messages if they want. Where does the "low trust" come in? How is it different from, say, Facebook Messenger, where Facebook also has access to all my messages?
Not necessarily malware, but borderline malicious. I would consider someone uploading our chats in plain text (even to their backup) a "malicious" actor, even though they are probably naive. The point I'm making here is that modified clients can be harmful to _your_ security and that open sourcing a program makes it easier to modify in a way that does this. There are trade-offs here.
> I suppose I don't see what the difference is though.
I'm sorry, you don't see the difference between a binary outcome and spectrum? There just are very few things in the world that are actually binary. People trying to convince you that they are are typically bad actors.
> Signal has complete control of the app, which means they have full access to all my messages if they want.
Under what mechanism? The upside of an open sourced app is that you can actually verify that they don't have such a mechanism. That's where the low trust comes in. That they show evidence of their claims. They release court documents detailing exactly what they've released to governments[0], in combination with the ACLU. Which now means the ACLU is putting their reputation on the line as well. There's a lot of 3rd party actors that put their reputations on the line here and Signal going out of their way to demonstrate that they have nothing to hide. "Don't trust us, this is all the code here. Check it yourself."
While I agree with the concern here, is there an alternative mass market model in which software can be distributed in a way that ensures no one but the user controls the device? I mean mass market, so the barrier is that my tech illiterate grandma has to be able to install this with the help of my tech illiterate parents.
Signal has reproducible builds
https://github.com/signalapp/Signal-Android/blob/main/reprod...
Also, wasn't Zoom sued for bastardizing the concept of "end-to-end encryption" to mislead people?
https://www.businessinsider.com/zoom-ftc-lawsuit-end-to-end-...
They're either stored in your choice of third party service or you can host it yourself if you really want.
I don't see if the private half of the key is shared with the web app to decrypt the cypher text, or if the cypher text is sent to the key service which responds with plain text.
> I also wouldn't be surprised if the shit only works in Chrome.
I don't see any evidence of this in the documentation. I can't think what API it would require beyond the widely adopted fetch API.
> Also, wasn't Zoom sued for bastardizing the concept of "end-to-end encryption" to mislead people?
I don't see any reason to think this is much different from any other end-to-end system. All the mobile end-to-end apps require you trust the code they run on your device. As described this requires you to trust the JavaScript they run on your browser.
> I don't see if the private half of the key is shared with the web app to decrypt the cypher text, or if the cypher text is sent to the key service which responds with plain text.
I checked out the ref for that encryption API. Seems like the service stores the key, and the API exposes encrypt/decrypt calls:
https://developers.google.com/workspace/cse/reference
So yeah, go trust that third-party provider, or if you have the technical skill, set up your own. Since most people would do the former, this is basically back to square one, and to call this "end-to-end" is misleading.
The idea of storing your keys on an Internet-facing server baffles me too. It will 100% get hacked sooner or later.
I'm not sure I agree that this is misleading. Google, who is storing the data, never holds the key. Likewise, the key provider never holds the data. To compromise the data you'd need to compromise both gmail and the key provider at the same time. The fact that organizations are delegating the key management is an implementation detail.
> The idea of storing your keys on an Internet-facing server baffles me too. It will 100% get hacked sooner or later.
I mean you can separate it out. You just need to implement the API on an internet-facing server.
Most thick client update mechanisms make this more difficult (but certainly not impossible) thus greatly increasing the risks of embedded malware being detected.
Signal, for example, is reproducibly built, so you can diff the source of each new update and then verify that you get the same binary. This gives you very good assurance that your audit of those diffs is valid to the binary on your phone.
I doubt that someone who has invested the time in developing code-auditing skills also values their own time so little that they'd audit and build their chat client. And if they're willing to farm auditing out to someone else, or to vouch to other users of the app, then they've lost the plot.
Not saying such a person couldn't exist. But the intersection in the Venn diagram seems small.
I'm way more worried about all the dirty little fingers on the hundreds of Rust crates, Python packages, Java libraries, and NPM packages that get slurped, unreviewed, into so much software these days. (But I'm still not actually going to do anything about it.)
Is the main news that S/MIME encryption can now happen in the browser instead of Google’s backend?
I thought Google was targeting using email content... Also this will impact their ability to use AI for things like spam filtering and smart labeling
"You upload a user’s S/MIME certificate and wrapped private key using the Gmail API, with the service account private key file. For each user"
If this is end to end encryption why are you uploading a private key to Google? Am I confused?
> When you open Gmail, you'll see ads that were selected to show you the most useful and relevant ads. The process of selecting and showing personalized ads in Gmail is fully automated. These ads are shown to you based on your online activity while you're signed into Google. We will not scan or read your Gmail messages to show you ads.
I don’t believe a random external sender will be able to send an E2E encrypted email. Or at least not in a way that would be readable by the recipient.
"What's encrypted in Gmail:
Email body and attachments, including inline images
Not encrypted in Gmail:
The header of the email, including subject, timestamps, and recipients lists"
Subjects is a concession to search and filters. Nobody is trying to shove PHI into a subject line... doesn't seem like a big deal imo.
https://signal.org/blog/sealed-sender/
I guess another example of why it's hard to retrofit email for security and privacy.
lol
https://support.google.com/a/answer/13069736?visit_id=638068...
This does not affect non-corporate Gmail users...
All that to say, this is something at least some people have thought would be useful for some time, and it's nice to see some people getting access to that functionality.
(Now work for Google, not on anything remotely related to Gmail, remarks are my own, etc etc.)
But to the best of my knowledge, he graduated without suggesting we all start using his extension to take over the world, and I've not found any suggestions it was published.
What I like about Google’s announcement is that even though this is only enabled now for Workspaces, if Google opens this to all GMail users then a large percentage of e-mail will be gmail to gmail encrypted.
This is what disappointed me about ProtonMail: they didn’t have a critical mass of users. I only had one other non-work friend who used ProtonMail.
Those things are client-side encryption. End to end implies more than the one end. Which is a good thing. Who would want to have to compare a key fingerprint just so they could securely store files in the cloud? With client side encryption the identity management comes for free...
That’s a pretty hard sell for power users…
Too little, too late, we will never regain what was lost.
I guess since gmail is JS on the client side, some smart programmer can unpack the code and show that the crypto is sound.
But until then it's only claims
So if you care about that you can't trust any webmail. Instead use Thunderbird/mutt/whatever and GPG/PGP, like you could for the last 20+ years.
From evil compilers to source/binary modification in flight to supply chain attacks, it is probably impossible to prove secure operation of open (or closed) source.
All we have are mitigations and risk reduction. If the bar is provably perfect security, nothing can meet it.
Seriously. It is not possible to prove 100% security. Between human, electrical, hardware, firmware, and software vulnerabilities, there is always a gap.
i'm starting to wonder if this is actually just a coincidence...
i couldn't find this for years either