Client-side encryption for Gmail in Google Workspace is now generally available(workspaceupdates.googleblog.com)
workspaceupdates.googleblog.com
Client-side encryption for Gmail in Google Workspace is now generally available
https://workspaceupdates.googleblog.com/2023/02/client-side-encryption-for-gmail-generally-available.html
99 comments
To me this feature looks like a box ticking exercise with an eye toward government contracts. Microsoft has it so Google needs it too in order to avoid looking less secure to decision makers who may not know whether or not it will ever be needed.
Sure, it ticks this exact box that the help article mentions:
> Your organization operates in a highly regulated industry, like aerospace and defense, financial services, or government.
> Your organization operates in a highly regulated industry, like aerospace and defense, financial services, or government.
This is not just tick a checkbox and it is done. Enabling it is non-trivial as it requires setting up a whole bunch of stuff, like integrating with a third party key service provider (or setting up your own).
I didn't mean to say anything about how hard it is to implement.
What I'm saying is that the point of implementing this feature may not be that it's expected to be tremendously useful for a lot of actual users.
Rather I think the point is to not leave the "has client-side encryption" box unchecked in any comparison charts or scoring systems that may influence purchasing decisions.
What I'm saying is that the point of implementing this feature may not be that it's expected to be tremendously useful for a lot of actual users.
Rather I think the point is to not leave the "has client-side encryption" box unchecked in any comparison charts or scoring systems that may influence purchasing decisions.
> Also to be available it must first be enabled by a workspace admin, then by the end user.
Just out of curiosity, why would you expect anything different?
Just out of curiosity, why would you expect anything different?
I'm very surprised it isn't force enabled by the admin, with the end user having no say in the matter.
Admins of many orgs don't like letting the user have options for things like security.
Admins of many orgs don't like letting the user have options for things like security.
The feature is meant for especially sensitive documents, you wouldn’t want it turned on for everything in the organization because it limits useful features like search and printing. More mature products like Azure Information Protection let you require encryption for certain documents based on policy, but that doesn’t seem to be part of what Google is announcing here.
> you wouldn’t want it turned on for everything in the organization because it limits useful features like search and printing
Some organizations would want to prioritize encryption over search/printing. (Also, there's no reason search and printing couldn't work with encryption.)
Some organizations would want to prioritize encryption over search/printing. (Also, there's no reason search and printing couldn't work with encryption.)
It's more of an issue that people have to interact with vendors outside their direct ecosystem, who maintain different email systems. I can have all the PKI infrastructure I want, if my contracting officer has to coordinate payment of a $10M or $100M deliverable with a foreign company with different laws around encryption, I may have no choice but to send some things unencrypted until we can mutually agree on certain processes.
At the very least, I can confirm that ProtonMail and Apple's Mail clients let you search through the message contents of encrypted email. I'm sure there's a performance hit, and admins wouldn't be able to search through the encrypted emails of their Workspace users, but that's a much more reasonable tradeoff.
I'd be interested to know the implementation... Most search-over-encrypted-documents implementations either don't scale well (eg. require the client to do all the indexing and upload the encrypted index), or have reduced privacy (allowing the server to infer which words are in which document).
> require the client to do all the indexing and upload the encrypted index
Or just require the client to do the indexing and the searching, and not upload the index anywhere.
Or just require the client to do the indexing and the searching, and not upload the index anywhere.
Yep. Not sure how Apple/Proton implement it, but that's exactly what Tutanota does. https://tutanota.com/blog/posts/first-search-encrypted-data
And when you log in from a new device...? Do you now need to wait days while 1000,000 emails from the last decade are all downloaded and indexed?
That's an issue with or without client-side encryption. Even with IMAP, you have to download the message before its contents can be searched. While subject/sender/recipient can be searched instantly with IMAP, regardless of encryption.
This is a limitation of your client or server. Not IMAP.
No, it's a limitation by IMAP that is rectified by the server/client.
Maybe if you have that many emails and 3G only and can't load a backup for some reason.
Yeah, It's understandable that they would use this as a differentiator, but in reality, we all gain when encryption is rolled out more broadly.
Who is "we" in this context?
Similar to Microsoft 365 - you need a higher end subscription there too.
idiotsecant(1)
That is not Generally available:
Availability
* Available to Google Workspace Enterprise Plus, Education Plus, and Education Standard customers
* Not available to Google Workspace Essentials, Business Starter, Business Standard, Business Plus, Enterprise Essentials, Education Fundamentals, Frontline, and Nonprofits, as well as legacy G Suite Basic and Business customers
* Not available to users with personal Google AccountsAt Google, generally available means it's no longer in testing. It's a development lifecycle term.
Not just at Google, MS also uses GA when something is sold, no need for it to be free.
Yes I think if you work at a software company "GA" as a status in release management has a well-understood meaning - "general availability." However stating something is "generally available" in the headline only to followed by the lede that states it's actually only GA for a premium tier of product users feels a bit disingenuous if not click-baity.
> At Google, generally available means it's a feature that about to be killed off.
;-)
;-)
That's weasel word marketing.
They know the majority of their users are going to think 'generally available' is exactly what it sounds like, not their made up meaning.
https://en.wikipedia.org/wiki/Weasel_word
They know the majority of their users are going to think 'generally available' is exactly what it sounds like, not their made up meaning.
https://en.wikipedia.org/wiki/Weasel_word
If a restaurant near you says their new menu is generally available, do you turn up looking for a free meal without a reservation?
The Google announcement is pretty direct about the plans the feature is included with, and how to enable it.
The Google announcement is pretty direct about the plans the feature is included with, and how to enable it.
While the education plans aren't publicly available, apparently there is no minimum for Enterprise Plus accounts. Theoretically, an enterprising (unless nonplussed) individual could indeed get this feature at I think $30/mo.
Buy a school sounding domain, copy existing school web site -> get an education plan.
> That's weasel word marketing.
Bit of both, maybe.
Internally GA means released to at least some end users without caveats like "in beta".
Marketing are just repeating that. Maybe they are being deliberately disingenuous, or maybe they are just parroting a phrase they don't understand.
Bit of both, maybe.
Internally GA means released to at least some end users without caveats like "in beta".
Marketing are just repeating that. Maybe they are being deliberately disingenuous, or maybe they are just parroting a phrase they don't understand.
[deleted]
Generally Available in software terms means out of beta, i.e. launched.
Whether it is available to everyone for free, requires a specific plan etc. is not part of the determination.
Whether it is available to everyone for free, requires a specific plan etc. is not part of the determination.
i think i read all the blog posts and announcements, yet i can't for the life of me find a technical explanation of what exactly this does.
it looks like it could be like s/mime, or possibly a scheme for encrypting the contents of messages stored in gmail accounts. where are the keys stored? what is the threat model?
can anyone enlighten?
it looks like it could be like s/mime, or possibly a scheme for encrypting the contents of messages stored in gmail accounts. where are the keys stored? what is the threat model?
can anyone enlighten?
Can you only send encrypted messages to recipients who also use Google? If it isn't S/MIME then as far as I'm concerned it almost isn't email. Anyone can already make encrypted ZIP files or other proprietary encrypted attachments and send them via email. If it's not S/MIME, it feels like just a convenience layer on top of that.
It’s primarily for industries with strict regulatory/compliance requirements on managing sensitive data. The more detailed description is at [1]. Keys are stored in a cloud service, admins and end users use SSO to retrieve a key whenever they need to access an encrypted document. This is supposed to let companies do things like enforce rules on forwarding or printing sensitive emails, revoke access to particular documents if needed, and reduce the scale and risk of leaks if Google or an individual user account was breached. Of course, it’s not perfect in practice.
[1] https://support.google.com/a/answer/10741897
[1] https://support.google.com/a/answer/10741897
ok so it's basically like 0bin for google apps storage. that's a step in the right direction... it's confusing because they present it in the context of email.
although i suppose that's probably what customers are most worried about. corporate scandals tend to frequently be rooted in leaked internal communications.
although i suppose that's probably what customers are most worried about. corporate scandals tend to frequently be rooted in leaked internal communications.
Good for gmail.
These days, people really should get their own domain and host there email there. If you do not know how to do this, there are plenty of cheap hosting companies you can use.
And if you want to encrypt, use gnupg or that thing Thunderbird now uses. I am a mutt user and gnupg with mutt is rather easy.
These days, people really should get their own domain and host there email there. If you do not know how to do this, there are plenty of cheap hosting companies you can use.
And if you want to encrypt, use gnupg or that thing Thunderbird now uses. I am a mutt user and gnupg with mutt is rather easy.
> These days, people really should get their own domain and host there email there
It seems to be a giant pain in the ass, and might be impossible in some circumstances
https://cfenollosa.com/blog/after-self-hosting-my-email-for-...
It seems to be a giant pain in the ass, and might be impossible in some circumstances
https://cfenollosa.com/blog/after-self-hosting-my-email-for-...
What if you want email you send to make it to the inbox of gmail, 365 users?
I suppose jeremyjh@ meant emailing someone with a Google account kind of defeats the purpose of self hosting as your message is now at Google's hands. Self hosting probably makes more sense if people you're emailing are self hosting too.
Most hosted mail services have no issues getting to mailbox. I've used Gandi, Mailbox, FastMail, and never have any mails flagged as spam.
Deliverability is only an issue when self hosting (particularly for home IPs)
Deliverability is only an issue when self hosting (particularly for home IPs)
I mean, at least for me it hasn't been a problem. I currently self host mail on a VPS and everything's awesome. YMMV
>never have any mails flagged as spam
You don't know this for certain, no one can unless you monitor both ends.
You don't know this for certain, no one can unless you monitor both ends.
Then get a legit-looking domain name and hope you don't get algorithmically deranked. It's literally a gamble.
Sure, if that's your hobby. I used to do that, but there are other things you can do with our time too. So now I use ProtonMail with my own domain.
As a fellow mutt user, I only had to fiddle with the config over 10 years ago. After that, you are only reaping the benefits of your time investment.
You must use your own domain with Google Workspace, which is what the post is about.
The email allow-lists will be a problem.
Went into this thread thinking "how will HN find an angle where this is a bad thing?". Was not disappointed.
> client-side encryption for Gmail is now generally available for Google Workspace Enterprise Plus, Education Plus, and Education Standard customers.
So nothing for power users?
So nothing for power users?
This is purely marketing AFAIT. I don't see how it provides any protection against the 5 eyes or having one's google account breached. The encryption/decription is done with javascript code served to your browser by google (= can be hijacked/changed/…)
The only way to do client side encryption is PGP on a native client distributed by a third party.
The only way to do client side encryption is PGP on a native client distributed by a third party.
It is encrypted by the key service and not by google: https://support.google.com/a/answer/10801691
can be self hosted.
can be self hosted.
I think the primary benefit is that in theory you can cut Google off at any time. If you disable the key service they can no longer decrypt your data. So if you decided that Google is no longer trustworthy you can leave and they can't access your data.
Of course this is sort of an odd game where you need to cut their access off before they backdoor it, so you have to somehow predict that Google is going to become malicious and beat them to the punch. If you a reacting to something that they are doing it likely isn't helping much.
Another possible advantage is that you could potentially have logging on key access which could give some idea of data usage. So if Google starts requesting keys for all of your stored data then you can be suspicious that they are siphoning up your data. (Or doing some background maintenance? Who knows?)
In practice this is probably mostly checkbox theater where it is a feature that Google and their users can list.
Of course this is sort of an odd game where you need to cut their access off before they backdoor it, so you have to somehow predict that Google is going to become malicious and beat them to the punch. If you a reacting to something that they are doing it likely isn't helping much.
Another possible advantage is that you could potentially have logging on key access which could give some idea of data usage. So if Google starts requesting keys for all of your stored data then you can be suspicious that they are siphoning up your data. (Or doing some background maintenance? Who knows?)
In practice this is probably mostly checkbox theater where it is a feature that Google and their users can list.
I wonder which tool we can use to decrypt the exported messages before importing them into a local (mbox, maildir) or remote message store (IMAP.) At worst we can use the JS code Google sends us, but extracting it from the gmail JS bundle is probably non trivial.
Except that we've got two decades of evidence of people regularly fucking up PGP leaking the contents of entire email threads. If the only thing that works is PGP then nothing works.
If the key is encrypted with your password, I don't see how that compromises security by a lot. If they adapt the javascript to break encryption on a large scale, that would sooner or later come out.
Yes, they could target specific people, deliver different javascript and break their encryption, but in general it's still a huge security gain. It makes it impossible for Google to handover E-Mails retrospectively to police or spy agencies.
Yes, they could target specific people, deliver different javascript and break their encryption, but in general it's still a huge security gain. It makes it impossible for Google to handover E-Mails retrospectively to police or spy agencies.
[deleted]
Not saying much. Same is true about any e2e encrypted messaging (Telegram, Signal, etc.)
There's no way to tell if they are intercepting your messages clientside, and you'd have to monitor all the network traffic (which would be encrypted with their keys) to detect exfiltration.
There's no way to tell if they are intercepting your messages clientside, and you'd have to monitor all the network traffic (which would be encrypted with their keys) to detect exfiltration.
No. Signal is not redownloaded from Signal each time you launch the app, unlike javascript web apps.
You're 100% sure they didn't already ship the code and have the ability to flip a flag to enable message interception per user?
Or the ability to execute arbitrary external code?
Or the ability to execute arbitrary external code?
Signal's feature flags are public as the client is open source and anyone can retrieve the feature flags from the server.
You can also run your own self-built client (alternative implementations are available) and forward the messages securely any way you wish.
Such subterfuge would not remain undetected.
Signal is e2ee in ways that iMessage and WhatsApp are not.
You can also run your own self-built client (alternative implementations are available) and forward the messages securely any way you wish.
Such subterfuge would not remain undetected.
Signal is e2ee in ways that iMessage and WhatsApp are not.
>I don't see how it provides any protection against the 5 eyes or having one's google account breached.
It isn't supposed to protect you from government agencies. Really what this feature is, is 1) e2e of email, and 2) integration with an external enterprise key management service.
#2 means that at very least, your org will have access to your keys and therefore all encrypted mail, and if they have access to that, then they are open to things like subpoenas from law enforcement.
It isn't supposed to protect you from government agencies. Really what this feature is, is 1) e2e of email, and 2) integration with an external enterprise key management service.
#2 means that at very least, your org will have access to your keys and therefore all encrypted mail, and if they have access to that, then they are open to things like subpoenas from law enforcement.
Wonder if there's a browser plugin that can calculate SHA 256 checksum for a page and all linked JS - to help verify that the encryption/decription code has not been compromised.
WhatsApp build something like that: https://engineering.fb.com/2022/03/10/security/code-verify/
Does it work with mailing lists?
Edit: Found out that it doesn't: https://support.google.com/a/answer/10741897#zippy=%2Cwhich-...
Edit: Found out that it doesn't: https://support.google.com/a/answer/10741897#zippy=%2Cwhich-...
I'm surprised it took them this long. Outlook/Exchange has supported IRM protected emails since 2007. Little things like these show why Microsoft has an unassailable lead in enterprise software and Google, despite all of its resources, is forever playing catch up.
Maybe they're trying to penetrate more the Enterprise market where usually people are very nervous about not having on-prem e-mail and full control of the data.
This is supposed to give them some guarantees that the data is locked&safe outside of their premises.
This is supposed to give them some guarantees that the data is locked&safe outside of their premises.
[deleted]
Naturally they have reinvented the proprietary wheel instead of implementing PGP, so that their domesticated users are nicely corralled in their walled garden.
Can't find anything about key rotation. How do they crack that nut?
My understanding is that you create a new key in the external key management service, re-encrypt all applicable data in Workspace with the new key and then revoke/delete the old key. All this is API-based, of course, so it can be automated.
(Testing Cunningham's Law here)
(Testing Cunningham's Law here)
Title is misleading.
> Not available to users with personal Google Accounts
> Not available to users with personal Google Accounts
[deleted]
Not available to users with personal Google Accounts.
Why not?
Why not?
I’m speculating about how this works, but it probably doesn’t make sense for general-purpose email.
For emails between members of one workspace/domain, you can conceptually perform key exchange to implement client-side encryption. You also don’t have spam concerns within members of a workspace.
There’s no general way to do key exchange between different email domains, and you do have spam concerns (which to address requires scanning the content).
There’s no protocol for doing such things over different email domains in a way that’s compatible and interoperable across software stacks. This technology is proprietary, and would make spam challenging to deal with (which again is not a problem within one workspace).
It’s also not clear to me whether this is really client-side encryption, so much as encryption at a layer higher than the email stack. (It’s pretty hard to do client-side encryption in the browser, in a way that matches user expectations. How do you store/retrieve the encryption key?)
For emails between members of one workspace/domain, you can conceptually perform key exchange to implement client-side encryption. You also don’t have spam concerns within members of a workspace.
There’s no general way to do key exchange between different email domains, and you do have spam concerns (which to address requires scanning the content).
There’s no protocol for doing such things over different email domains in a way that’s compatible and interoperable across software stacks. This technology is proprietary, and would make spam challenging to deal with (which again is not a problem within one workspace).
It’s also not clear to me whether this is really client-side encryption, so much as encryption at a layer higher than the email stack. (It’s pretty hard to do client-side encryption in the browser, in a way that matches user expectations. How do you store/retrieve the encryption key?)
OoenPGP.js is open source and developed by ProtonMail
https://openpgpjs.org/ https://github.com/openpgpjs/openpgpjs
A number of Chrome (and I think also Firefox) extensions include their own local copy of OpenPGP.js for use with various webmail services, including GMail.
WKD (and HKP) depends upon HTTPS without cert pinning, FWIU: https://wiki.gnupg.org/WKD
A number of Chrome (and I think also Firefox) extensions include their own local copy of OpenPGP.js for use with various webmail services, including GMail.
WKD (and HKP) depends upon HTTPS without cert pinning, FWIU: https://wiki.gnupg.org/WKD
How does an email client use WKD?
1. A user selects a recipient for an email.
2. The email client uses the domain part of the email address to construct which server to ask.
3. HTTPS is used to get the current public key.
The email client is ready to encrypt and send now.
An example:
https://intevation.de/.well-known/openpgpkey/hu/it5sewh54rxz33fwmr8u6dy4bbz8itz4 is the direct method URL for "[email protected]How/where exactly does it store the user's private keys?
The initial reaction that I have to client-side encryption with a web browser is: how does the client fetch/obtain the encryption key? (For signing outbound messages, or decrypting/verifying inbound.) Local storage wouldn't be appropriate as the sole storage for something like an asymmetric keypair, and it wouldn't provide the behavior that users expect: being able to log in and use a service from any web browser.
No one interacts with a web browser in such a way that it would be appropriate for the browser's local state to be the sole storage of something important like a private key. So this necessitates a service that the client interacts with during login to fetch its private key.
If you can log in with a browser, then that implies that you're fetching the key from somewhere. In the context of hosted Gmail, then that means that Gmail will be storing and providing your key. In which case it's nominally client-side encryption -- and the system that stores and provides your key might be totally separate from the email systems (and tightly controlled) -- but it's still not what I'd think of as client-side encryption generally. It's not really client-side encryption if the service that you're using to store data is the same service (from your perspective) as the one that stores/provides your key (those responsibilities might be separated from an implementation perspective, but they aren't from a user's perspective).
The service can employ various techniques like encrypting its copy of my private key using a symmetric key derived from my passphrase (and then discarded) -- and this decryption could perhaps be done client-side in the browser -- but ultimately the service still has the ability to obtain my key (at time of next login, if not any time).
If the service that provides a client-side encryption key could be divorced from a particular use-case -- e.g., if I could use my own pluggable key-providing service with Gmail, which my browser uses to fetch my key on login -- then the model would make a bit more sense. (You'd still have to trust a service like Gmail not to steal your key, but at least you don't have to trust it to store the key as well.)
Would it be possible to implement a standardized pluggable key server model? It seems plausible. Imagine that there was a standard HTTP protocol for this purpose, kind of like how WebAuthN is standardized. I log into Gmail, link it to my key server <https://keys.jcrites.example.com>, verify the connection, and then when logging into Gmail, then the web page is allowed to make HTTPS calls to <https://keys.jcrites.example.com> to either fetch my asymmetric key, or alternatively make calls to decrypt or encrypt specific content.
In the former case, it implements client-side encryption using a key server I control, while trusting Gmail not to misuse the key; in the latter case, it implements encryption using a keyserver that I control, and makes remote calls for each encryption operation. In that case Gmail would never have my key, although while browsing Gmail.com it could probably make arbitrary requests to the key server to perform operations using the key -- but you could log what operations are performed.
The initial reaction that I have to client-side encryption with a web browser is: how does the client fetch/obtain the encryption key? (For signing outbound messages, or decrypting/verifying inbound.) Local storage wouldn't be appropriate as the sole storage for something like an asymmetric keypair, and it wouldn't provide the behavior that users expect: being able to log in and use a service from any web browser.
No one interacts with a web browser in such a way that it would be appropriate for the browser's local state to be the sole storage of something important like a private key. So this necessitates a service that the client interacts with during login to fetch its private key.
If you can log in with a browser, then that implies that you're fetching the key from somewhere. In the context of hosted Gmail, then that means that Gmail will be storing and providing your key. In which case it's nominally client-side encryption -- and the system that stores and provides your key might be totally separate from the email systems (and tightly controlled) -- but it's still not what I'd think of as client-side encryption generally. It's not really client-side encryption if the service that you're using to store data is the same service (from your perspective) as the one that stores/provides your key (those responsibilities might be separated from an implementation perspective, but they aren't from a user's perspective).
The service can employ various techniques like encrypting its copy of my private key using a symmetric key derived from my passphrase (and then discarded) -- and this decryption could perhaps be done client-side in the browser -- but ultimately the service still has the ability to obtain my key (at time of next login, if not any time).
If the service that provides a client-side encryption key could be divorced from a particular use-case -- e.g., if I could use my own pluggable key-providing service with Gmail, which my browser uses to fetch my key on login -- then the model would make a bit more sense. (You'd still have to trust a service like Gmail not to steal your key, but at least you don't have to trust it to store the key as well.)
Would it be possible to implement a standardized pluggable key server model? It seems plausible. Imagine that there was a standard HTTP protocol for this purpose, kind of like how WebAuthN is standardized. I log into Gmail, link it to my key server <https://keys.jcrites.example.com>, verify the connection, and then when logging into Gmail, then the web page is allowed to make HTTPS calls to <https://keys.jcrites.example.com> to either fetch my asymmetric key, or alternatively make calls to decrypt or encrypt specific content.
In the former case, it implements client-side encryption using a key server I control, while trusting Gmail not to misuse the key; in the latter case, it implements encryption using a keyserver that I control, and makes remote calls for each encryption operation. In that case Gmail would never have my key, although while browsing Gmail.com it could probably make arbitrary requests to the key server to perform operations using the key -- but you could log what operations are performed.
Looks like you are correct: WebUSB and WebBluetooth and WebAuth don't already cover HSM use cases?
/? secure enclave browser
But WebCrypto: "PROPOSAL: Add support for general (hardware backed) cryptographic signatures and key exchange #263" https://github.com/w3c/webcrypto/issues/263
/? secure enclave browser
But WebCrypto: "PROPOSAL: Add support for general (hardware backed) cryptographic signatures and key exchange #263" https://github.com/w3c/webcrypto/issues/263
The year is 2023.
There is no info on how it works! It looks more like a marketing stunt!
How the key is generated, where it is stored, and which encryption is used.
How the key is generated, where it is stored, and which encryption is used.
It’s in the references below the blog post
https://support.google.com/a/answer/13069736?hl=en
https://support.google.com/a/answer/13069736?hl=en
Also to be available it must first be enabled by a workspace admin, then by the end user.