I had a bit of curiosity today while going through my email, wondering about how secure it was. As I logged back in to some sites requiring two-factor authentication due to my recent 2-F-Apocalypse after losing my Chrome cookies, a few were set up to send verification links through email. A few questions I didn’t know the answer to popped into my head: Is that safe? How secure is email today anyway? And down the rabbit-hole I went…

Anecdotally, I’d say that almost all messages I receive from real people (and most messages from mailing lists or companies) are transmitted securely to my Gmail (where you can check on the transport encryption status). Here’s an example of an email sent insecurely, and how you can tell whether a message you are about to send is going to be sent securely:

On Google’s Transparency Report for Safer email, the current numbers for Gmail’s outbound and inbound messages that are transported securely (encrypted) as of this writing are 87% and 81% respectively.¹

Is that good? Does that mean we’re >80% safe now? What does that even mean?

I’ve always thought of email as being inherently simple and insecure. After all, email runs on the 35-year-old “Simple” Mail Transfer Protocol (SMTP). Having spent the last decade as a CTO of a health information technology company dealing with Protected Health Information (PHI) and constantly scolding my clients for sending PHI over email (frowned upon, though surprisingly not always illegal under HIPAA), I wondered if my beliefs about the insecurity of email were still true. Those beliefs were grounded in the days before encryption was available over SMTP² (pre-2000) and when many more organizations ran SMTP servers internally. Before Yahoo! Mail & Hotmail were created in the late 90’s and Gmail burst onto the scene in 2004, nearly every small internet service provider (who most people got their email from at the time) and small- or medium-sized organization had an email server sitting in a closet somewhere running the email server software of the day³, which was insecure by design. This distributed nature of the internet’s email server infrastructure made it resilient but ultimately resistant to change. How do you convince a million server operators to update their email software to something more secure when it’s not technically broken? I would have imagined even a very simplified graph of the zillions of email servers on the internet back in 2000 to look something like this:

Fast forward to today, where almost every person and nearly every small- or medium-sized organization outsources their email to one of the big email providers (Google, Microsoft, Yahoo, AOL etc.). Not only that, but senders of bulk email also regularly outsource that task to one of a short list of professional email platforms (Mailgun, Mailchimp, Sendgrid, Amazon SES, etc). I’d wager a guess that the percentage of email being sent and received by the big email services is increasing, and that a very simplified graph of email being sent today would look more like this:

With such a large percentage of email under the control of a smaller cadre of email services, you’d think that the small number of “big guys” would be able to agree upon a way to send email securely, force the rest of the small fish to go along with them, and that our email would be secure today (and maybe even encrypted end-to-end!). While that may happen someday, here are a few harsh truths about the current state of affairs:

1. Email transport encryption is still voluntary and optional. As the Google Transparency report showed, ~20% of email today is still being transported totally unencrypted. That means that any simple attacker with read access to the network between the email server of the sender and that of the email recipient has the capability to read the entirety of the message.
2. Because transport encryption is optional, even the other ~80% of encrypted email traffic may be subject to a man-in-the-middle downgrade attack, so under many circumstances a sophisticated attacker with interception access to the network between the sender & recipient servers has the capacity to strip the encryption and read the message.

While that doesn’t sound very good, forces are in motion to improve the situation:

1. A proposal published in 2015 (RFC 7672) called DNS-Based Authentication of Named Entities Transport Layer Security (DANE TLS) would use Secure DNS (DNSSEC) to specify and require email server encryption, but adoption of that proposal is dependent on the adoption of DNSSEC which itself is controversial and has been very slow to this point.
2. A different proposal, SMTP MTA Strict Transport Security (SMTP MTA-STS) would use regular DNS and a secure web service to specify and require email server encryption, but is still currently in draft status and if/when it is published will still take time for significant adoption.

In conclusion, while >80% encryption of email transport is a great start there are still gaping holes in the picture that should prevent anyone today from calling email transport secure. A persistent and sophisticated enough attacker still has plenty of opportunities to break into your email as it’s being transported, even without hacking into your account specifically.

This was an interesting refresher for me, having looked into email security in the distant past⁴ but not having read much about the recent progress made. I’ll have to remember to check back in on it later, maybe we’ll be closer in 2018! Fingers crossed.