“Safer hops for email” – EFF’s plan to cut down on email snooping

You’ve probably heard of Let’s Encrypt, not least because we’ve written about it many times on Naked Security.
Let’s Encrypt is a non-profit project that’s supported and sponsored by a wide range of high-profile internet companies and other non-profits.
The project has a fairly straightforward goal: to help websites make the switch to secure HTTP, better known as HTTPS, the protocol that puts the padlock in your browser.
HTTPS, simply put, is regular HTTP transmitted by means of an underlying network protocol known as Transport Layer Security, commonly known by its abbreviation TLS.

TLS is often still referred to, imprecisely, by its earlier name of SSL, which stood for Secure Sockets Layer. SSL is a backwards-compatible precursor of TLS that is no longer considered secure enough for use. You shouldn’t initiate or accept SSL connections any more – they give a false sense of security to both sender and recipient.
If you run a website that doesn’t ask users to login and doesn’t have any forms on which visitors might fill in personal data, it’s easy to slip into the habit of saying “encryption doesn’t matter.”
The anti-HTTPS excuses typically look like this: I’ve got nothing to hide, the pages I’ve serving up are meant to be public anyway, I never ask for or send out personally identifiable information, and there’s nothing on the site that could be considered incriminating to anyone reading it.

More than confidentiality

But the encryption provided by HTTPS isn’t only about confidentiality – it’s also about integrity and authenticity.
You owe it to your visitors to make them confident that they’re really visiting your site, not an imposter’s clone that’s riddled with scams and bogus content, and that they’re really getting your official files for download, not some modified and malware-tainted alternatives.
Nevertheless, even with the excuses for not using HTTPS swept aside, two primary reasons stood in its way until Let’s Encrypt came along: “going encrypted” took time and it cost money.
You need a TLS security certificate, and a trusted third-party needs to sign it – a process that used to be much more easily said than done.
Let’s Encrypt not only made the process simpler but also waived the fees for issuing signed security certificates, resulting in a huge decrease in the number of holdout websites that refuse to bother with HTTPS at all.
In fact, HTTPS is now prevalent enough that the Chrome browser is about to start shouting at you about any sites that aren’t encrypted, making HTTP into something to avoid altogether.

But what about email?

So much for the web – what about email encryption?
Who’s eavesdropping on your messages?
The good news is that if you use one of the major webmail services, and send email to another major webmail user, your emails are almost certainly cryptographically safe in transit.
The servers of webmail services like Gmail, Outlook.com and Yahoo! all use encryption when talking to each other, as well as when they talk to many other mainstream mail servers out there.
But plenty of non-webmail servers still aren’t bothering with server-to-server mail encryption, or are encrypting in a sub-standard way.
So the Electronic Frontier Foundation (EFF), one of the groups behind the Let’s Encrypt project, has announced a related effort called STARTTLS Everywhere for the world’s email ecosystem.
The word STARTTLS comes from the command used in the SMTP email protocol to switch into encrypted mode, and the STARTTLS Everywhere project aims to get everyone not only to use STARTTLS, but also to use it properly.
EFF identified several problems:

1. No support for STARTTLS at all. It’s easy enough not to bother with email encryption – it saves the hassle of acquiring a security certificate in the first place, and many corporate mail servers will still accept your messages anyway, even if they ask you to STARTTLS but you refuse.
2. Insecure TLS certificates. Some mail server administrators have gone to the trouble of creating security certificates, but not of getting them vouched for by a recognised certificate authority such as Let’s Encrypt. These so-called self-signed certificates are perfectly legal, and super-easy to create, but they have a significant weakness: anyone can create a self-signed certificate in anyone else’s name. So, self-signed certificates miss out on one of the most important benefits of STARTTLS in email, namely verifying that you’re delivering your email to the right server in the first place.
3. No downgrade protection. Unlike HTTPS connections from your browser, which start out using TLS and then talk HTTP over the secure-from-the-outset channel, email connections start out unencrypted and “upgrade” themselves to TLS later on after the STARTTLS command is used. An eavesdropper who can alter the unencrypted part of a mail connection can therefore strip out the STARTTLS commands, sneakily turning a connection that was supposed to be encrypted into one that can be snooped on throughout.

EFF plans to solve problems 1 and 2 by extending the Let’s Encrypt system so that email administrators can quickly and easily add TLS support for free.
So the TL;DR version so far is simple: “STARTTLS Everywhere is just Let’s Encrypt for email sysadmins.”

A trickier problem

But problem 3 above is trickier to solve, at least in the short term.
In theory, if the vast majority of email administrators simply refused to send or to accept unencrypted mail connections at all, then the small minority of crypto-deniers remaining would have no choice but to join the encryption club and start doing things properly.
But there are still sufficiently many non-encrypting email servers out there that we still need to support the old-and-insecure ways for convenience.
In practice, therefore, mail servers will be forced to accept unencrypted connections from time to time.
That means they need a reliable way to differentiate between a server that wanted to use encryption but was tricked by an eavesdropper into not doing so, and a server that didn’t care or couldn’t do encryption.
(It’s no use asking an email server if it wants to do secure encryption unless you already have an encrypted channel to validate the answer.)
One posible solution is a draft internet standard called MTA-STS, jointly proposed by experts from Microsoft, Google, Yahoo! and Comcast.
Simply put, MTA-STS allows a mail server to use an HTTPS connection – because secure HTTP is something we already know how to do well – to declare its preference for using email encryption, and thereby to prevent a downgrade attack.
EFF is also helping out by hosting its own database called the STARTTLS Policy List, hosted on its own secure servers, that keeps track of email systems that meet various minimum standards for SMTP encryption.

What to do?

If you run your own mail server, or outsource your mail server to someone else, please take the time to study the EFF’s STARTTLS Everywhere technical document – it’s called a “deep dive” but it’s nevertheless a fairly short read.
We urge you to start doing server-to-server email encryption if you aren’t already, and we encourage you not to cut corners with self-signed certificates: after all, a job worth doing is worth doing well.
As we like to say: Dance like no one’s watching/Encrypt like everyone is.