This is an overview of the STARTTLS Everywhere project. If your mailserver is affected by these changes, check out our technical deep-dive to securing your mailserver!

EFF started our STARTTLS Everywhere project in 2014, in a post-Snowden moment when the technology community banded together to push transport encryption as a crucial necessity.

Thanks to the Snowden revelations, we got a glimpse of how aggressive governments can be about intercepting Internet backbone communications. Along with other security technologists, EFF responded by working to encrypt the Internet. We launched several projects, imploring site owners, email providers, and app makers across the world to deploy encryption to their services. We built tooling and infrastructure to make it easier for websites and other services to encrypt, like Let’s Encrypt and Certbot. To complement HTTPS Everywhere, we launched a parallel effort for encrypting emails as they are delivered between email providers: STARTTLS Everywhere.

We’ve made major strides in transport security for email since then, thanks to the cooperation of email providers, protocol authors, and mailserver developers. We’ll slowly be winding down our work on the STARTTLS policy list, though we will continue to advocate for improved transport security in email and everywhere else on the Internet. While support for the project has been encouraging, the data we publish is not widely used by email providers. At the same time, we’ve seen other standards-based approaches mature and become more straightforward to adopt. On April 29th, we will no longer be accepting submissions to our STARTTLS policy list.

Encrypted, but Not Authenticated

According to Google’s transparency report, the percentage of emails encrypted in transit has increased from around 30% in 2013 and 2014 to over 90% today.  Despite these successes, the email ecosystem is far from completely secure against network surveillance and attackers.

Transport encryption is incomplete without authentication. Though it prevents people who are listening in on the network from reading email traffic in transit, intentional attempts to decrypt that traffic can still succeed. That’s because authentication isn’t completely solved in transport security for email yet.

Encryption ensures that your communication is only readable by a particular party. Authentication ensures that this party is the one you intended it to be.

Email is more complicated than the web, and relies more heavily on DNS, an Internet-wide system for storing information about how to reach certain computers. For instance, there are two DNS lookups involved in identifying the server for a particular email domain, whereas web servers often only require a single lookup. DNS is useful, but notoriously insecure—and in practice, this means that when sending email, servers have to somehow make sure both of these two lookups are correct. Otherwise, a major ISP could use this discrepancy to remove encryption from emails, or even pretend to be the receiving mail server, thereby intercepting, delaying, blocking, or rewriting emails.

On the web, TLS certificates provide enough information for your browser to validate the website’s identity. For email, these certificates aren’t enough, since they often only secure one of the two DNS lookups; mailservers need an additional way to securely receive and broadcast TLS and DNS information, which has not traditionally been a part of the Internet email standards.

Authenticating Emails

In short, mailservers need a way to advertise more information about their identity, and they also need a way to fetch that information so they can verify the identities of other mailservers. Currently, there are a couple of leading solutions–there’s DANE, and there’s MTA-STS.

DANE is a way to advertise more TLS information for an email domain over DNS. It relies on DNSSEC, a technology used for securing DNS lookups. Since DNSSEC deployment is top-down (for instance, your domain registrar also has to support it) and is somewhat complex, deployment remains relatively low. However, many combined efforts are increasing its use: many open source mail servers provide DANE support, more DNS providers are making it easier to deploy DNSSEC, and we’ve been improving Certbot to cooperate better with DANE. In the future, we hope to help Certbot work even better with DANE deployments.

MTA-STS is another way to advertise TLS information for a mail server, this time over the web. It was standardized in late 2018, and has since been adopted by a number of larger email service providers—including Gmail and ISPs like Comcast. The one downside to this approach is that when looking up someone’s TLS information using MTA-STS for the first time, it can be blocked by an ISP that wants to deliberately prevent secure email delivery.

We’re hoping more mailservers in the future can adopt these alternatives to authenticating emails.

One of the concerns going forward is how centralized the email ecosystem is. This centralized structure has been beneficial for deploying new security protocols such as MTA-STS—it’s easier to secure large portions of all email by pressuring these large email providers to adopt protocols en masse.

However, it can be difficult for smaller email providers to advertise their TLS information over DNSSEC and DANE due to its complexity, and additionally difficult for them to check TLS information over MTA-STS since very few popular open source mail servers provide this support. Rather than building new sets of solutions to cover various security flaws, mailserver developers should continue to build security into mailservers by default, and lower the barrier to entry for authenticated TLS in email. Projects like Mail in a Box, a “one-click setup” mailserver project, are especially promising.

As we’ve seen with the progress of HTTPS adoption, if we make security effortless, we can make it universal.