Google Seems To Have Abandoned End-To-End Encryption For 'Hosted' S/MIME Encryption In Gmail

Google announced that it implemented S/MIME (Secure/Multipurpose Internet Mail Extensions) encryption, with a twist, for its enterprise customers. That twist is that its implementation of S/MIME, which is typically an end-to-end encryption protocol, is centralized or “hosted” by Google. In other words, Google can see what’s in all of those S/MIME-protected emails.

S/MIME Protocol

The S/MIME protocol was first invented in 1995. A few years later, it also became an IETF standard (after a few more modifications to the original protocol). S/MIME aimed to be an end-to-end encrypted protocol that would replace the non-encrypted SMTP email protocol. It was also meant to be a little easier to use than PGP (Pretty Good Privacy), another end-to-end encryption protocol that was invented a few years before S/MIME.

With PGP, users have to share their public keys with each other prior to using end-to-end encryption, but with S/MIME, this key distribution is handled by a Certificate Authority that gives each user a certificate. Importing the certificate in the email client and signing email messages with it is what proves that the senders are who they say they are.

Google’s Hosted S/MIME

Google said that instead of supporting the standard client-side S/MIME protocol that allows users to encrypt emails end-to-end (meaning only the sender and receiver can read the emails), it will host all of the users’ certificates and private keys on its own servers.

This will allow the company to essentially read (with its computers) all communications that are protected by S/MIME. From this point of view, it’s no different than the way Gmail emails are encrypted today with TLS.

Google said that this will make it more convenient to enterprise customers to use S/MIME encryption, although without the benefit of end-to-end encryption. The company said that doing things this way allows it continue to stop phishing attempts and block spam email.

The fact that email companies wouldn’t be able to stop spam has long been a criticism of end-to-end encryption. However, WhatsApp seems to have managed quite well by employing techniques that don’t even require them to see people’s messages to block spam.

The techniques seem to involve a combination of verifying the identity of the sender and by tracking their behavior. For instance, if one user sends messages to 100,000 people, chances are that user is spamming. WhatsApp’s anti-spam solution is likely a little more advanced than in that example, but the point is stopping spam when end-to-end encryption is used is not as impossible as previously thought.

It’s Not All Bad

Although Google is essentially downgrading the security of the S/MIME protocol, the move still seems to be an upgrade over the existing, mainly hacked-together email encryption and authentication solutions.

The email protocol was never designed to be encrypted, so even today’s best improvements made to it can’t guarantee the security of the message in transit. This is especially true if the recipients use email services that don’t support the same encryption and authentication protocols that Gmail supports.

With S/MIME, the messages are encrypted with symmetric encryption as well, so it doesn’t matter what sort of hops it passes until the destination, as the messages will be unreadable to anyone intercepting them. They are also automatically signed by the senders, which will guarantee that the senders are who they say they are.

Of course, digital certificates are still vulnerable to certificate authorities going rogue or to being stolen from Google’s servers. The latter is something that may be quite difficult to achieve these days, but likely not impossible.

Is Google Giving Up On End-To-End Encryption?

Back in 2014, and soon after Edward Snowden made public the extent of the NSA’s mass surveillance, Google started working on an end-to-end encryption tool called, appropriately, “End-to-End.” The company seemed furious that the NSA broke into its network and monitoring every packet going through its unencrypted internal network.

From that point forward, it started aggressively adopting encryption everywhere it could add it, whether it was for internal or external communications, or for securing data at rest. One of those measures also involved starting End-to-End. This was a browser extension that would work with multiple email providers (Yahoo joined as well, but it later dropped it around the time it allegedly gave NSA access to its networks), and it would provide PGP end-to-end encryption to users that wanted it.

The project doesn’t seem to have been touched for almost a year (at least in its public code repository). After we contacted Google to ask about this a few months ago, the company declined to give a clear answer on whether it’s still working on this specific project.

Google did launch Allo with end-to-end encryption provided by the Signal protocol, but it’s not enabled by default like it is for the Signal app itself, or WhatsApp. There is also no easy way to make end-to-end encryption the default, if you’re not interested in using Allo’s AI assistant. “Incognito” chats have to be started manually with each contact. Unlike Signal and WhatsApp, Allo also doesn’t provide safety numbers that guarantee there’s no man-in-the-middle attack.

Avoiding Public Email Exposure

If companies want to avoid the type of hacks that hit Sony, the Democratic National Committee, and other organizations that exposed everyone’s emails, then end-to-end encryption is still the way to go. This may include the client-sided (non-hosted) S/MIME protocol or PGP, or even using a service such as ProtonMail.

For other companies that don’t worry as much about Google being hacked (again) and just want an easy to use, well known, and well supported encrypted email service, Gmail’s new hosted S/MIME protocol may still be an acceptable compromise and an upgrade over their existing email encryption hygiene.