SendGrid recently announced support for TLS encryption for all the email we send as part of #ResetTheNet. While this is a huge step forward for stopping bulk surveillance (spying on everybody), it does little to stop targeted surveillance (spying on a particular person of interest).
Bulk Targeted vs. Targeted Surveillance
SMTP with TLS protects “data in motion,” meaning that when you submit email to SendGrid using TLS, it is encrypted from your mail server to our mail servers. We then process your message, and send it onward to its recipients. If your recipients’ mail server supports TLS, we will send the message over an encrypted connection, ensuring that any passive surveillance devices along the way will only see ciphertext.
Thus, SMTP with TLS defeats passive bulk surveillance techniques such as the NSA tap at AT&T’s backbone facility in San Francisco.
However, a determined attacker who has the technical means  to perform an active attack on the traffic could man in the middle (MITM) the TLS connection. This allows her to present her own certificate and key, thus permitting her to decrypt and capture the ciphertext before re-encrypting it and forwarding it on to the legitimate destination server.
To defeat active attacks against SSL and TLS, we need end to end, or “data at rest” encryption. Public key encryption solutions for email have been around since the 90′s. The first really successful implementation was Pretty Good Privacy (PGP), created by Boulderite Phil Zimmerman back in 1991. PGP was the focal point of the crypto wars and at one point Phil famously published the source code as a hardback book via MIT press and distributed it under First Amendment protections of speech. PGP never really saw commercial success, either because the technology was too hard to use, or the powers that be didn’t want to see its usability improve. GNU Privacy Guard (GPG) is a GPL licensed (compatible) alternative to PGP that is under active development.
S/MIME, or Secure Multipurpose Internet Mail Extensions is a set of RFCs originally developed in 2004. S/MIME leverages X.509 certificates instead of PGP keys. What’s interesting about S/MIME is that while it’s relatively obscure, it has enjoyed native support from popular mail clients like Outlook, Mail.app, and Thunderbird for years, while you still can’t use PGP in any of those mail clients without third party plug-ins. Apple even introduced native support for S/MIME encrypted email on iPhone/iPad/iTouch back in 2012 with the release of iOS 5.
One major critique of S/MIME is that its security model depends on trusting public Certificate Authorities, which have suffered serious compromises that undermine the whole system. In fact, the public PKI on which the entire Internet depends is only as strong as its weakest link. This topic is beyond the scope of this discussion, but suffice to say that your browser depends on the public PKI, so for most people, S/MIME and publicly trusted certificates should provide reasonable security. If you are a dissident or activist and believe that you are subject to targeted surveillance, you can still realistically use S/MIME with self-signed certificates. However, you should make sure you verify the certificate fingerprints for the parties you communicate with out of band, just like you would verify PGP key fingerprints.
Google and “End-to-End”
Google made headlines earlier this month when it announced a new section of its Transparency Report that specifically highlights concerns around email security. They went further and released code for an alpha Chrome plug-in that will provide PGP/GPG style end to end crypto support for Gmail.
Now that you know a bit about PGP/GPG and S/MIME, which one should you choose? As we mentioned above, Outlook, Thunderbird, Mail.app and iPhone/iPad have native support for S/MIME, so we will walk you through getting that set up in our next post.
 The ability to mangle packets, e.g. a privileged physical position in a network topology, or the ability to control BGP and/or DNS.