Now that Google is shooting to be their own CA, couldn't they mass-generate S/MIME certificates for all their users?
Even if the sender and receiver is Google-hosted, they could still encrypt mail, so it's encrypted at rest if it's copied from a user's gmail account to their local mail via pop/imap? And, since Google would be generating the private key, they could also decrypt it server-side in their secure environment, do whatever scanning for advertising/spam classification, and still deliver the same product?
As other users have pointed out, if you're trying to protect against an adversarial Google, you've already lost by using gmail. If you're going to trust them with message composition software, and transport, just go in whole-hog.
As far as I can tell, Google seems to have their security ducks in a row, and take this stuff seriously. Deployed correctly this could be another "raising the bar" event on email security, and help mitigate against servers still not requiring tls/ssl on port 25.
Not only should they mass create keys for all accounts, but they should make (other/more) keys available for any purpose. An open system where most email addresses come with a set of keys would enable many types of encryption systems (file sharing, login, messaging, etc...) Users would still have keys managed by Google (or IT, or their webmail host) so they don't have to understand key management, and they'd have someone to call when things break.
> To use hosted S/MIME, companies need to upload their own certificates (with private keys) to Gmail, which can be done by end users via Gmail settings or by admins in bulk via the Gmail API.
So this is just to give the illusion of privacy and security then?
It gives protection against eavesdropping of messages in transit, so it's better than nothing (Even SSL+SMTP allows email relays to see the email in the clear). However it does not protect against an attacker who gets into your GMail, does not protect against warrents/NSLs/subpoenas against Google, does not protect against your domain admin accessing your message.
If you want to protect against an adversarial Google, you shouldn't be using Gmail at all.
If you want to protect against an adversarial nation-state, well, power to you, but it's an uphill battle. Use PGP, not S/MIME, and pray that everyone else knows how to use it perfectly, making no mistakes at any point ever.
S/MIME or other payload encryption is strictly better than SMTP STARTTLS alone because adversaries can easily defeat STARTTLS if they stand in the middle of the connection. Being so positioned will not allow them to disable S/MIME.
It's been several years since I experimented with this, but I recall that S/MIME on an iPhone was much easier to setup than GPG anywhere else, including the desktop. I think I used a USB transfer, but googling now shows guides that allow emailing a password encrypted p12 file.
CA and Web of Trust both require verifying the key fingerprints of yo want to be serious about it, but smime was much more easy to use overall.
Even if the sender and receiver is Google-hosted, they could still encrypt mail, so it's encrypted at rest if it's copied from a user's gmail account to their local mail via pop/imap? And, since Google would be generating the private key, they could also decrypt it server-side in their secure environment, do whatever scanning for advertising/spam classification, and still deliver the same product?
As other users have pointed out, if you're trying to protect against an adversarial Google, you've already lost by using gmail. If you're going to trust them with message composition software, and transport, just go in whole-hog.
As far as I can tell, Google seems to have their security ducks in a row, and take this stuff seriously. Deployed correctly this could be another "raising the bar" event on email security, and help mitigate against servers still not requiring tls/ssl on port 25.