Today we’re announcing the launch of STARTTLS Everywhere, EFF’s initiative to improve the security of the email ecosystem.
Thanks to previous EFF efforts like Let's Encrypt, and Certbot, as well as help from the major web browsers, we've seen significant wins in encrypting the web. Now we want to do for email what we’ve done for web browsing: make it simple and easy for everyone to help ensure their communications aren’t vulnerable to mass surveillance.
Note that this is a technical deep dive into EFF’s new STARTTLS Everywhere project, which assumes familiarity with SMTP and STARTTLS. If you’re not familiar with those terms, you should first read our post intended for a general audience, available here.
The State of Email Security
There are two primary security models for email transmission: end-to-end, and hop-to-hop. Solutions like PGP and S/MIME were developed as end-to-end solutions for encrypted email, which ensure that only the intended recipient can decrypt and read a particular message.
Unlike PGP and S/MIME, STARTTLS provides hop-to-hop encryption (TLS for email), not end-to-end. Without requiring configuration on the end-user's part, a mailserver with STARTTLS support can protect email from passive network eavesdroppers. For instance, network observers gobbling up worldwide information from Internet backbone access points (like the NSA or other governments) won't be able to see the contents of messages, and will need more targeted, low-volume methods. In addition, if you are using PGP or S/MIME to encrypt your emails, STARTTLS prevents metadata leakage (like the "Subject" line, which is often not encrypted by either standard) and can negotiate forward secrecy for your emails.
Thanks to multiple efforts over the years, effective STARTTLS encryption is as high as 89% according to Google's Email Transparency Report—a big improvement from 39% just five years ago.
However, as we explain in our general STARTTLS Everywhere announcement, STARTTLS has some problems.
Nobody Validates Certificates, and It’s Hard to Blame Them
Although many mailservers enable STARTTLS, most still do not validate certificates. Without certificate validation, an active attacker on the network can read and even modify emails sent through your supposedly “secure” connection. Since it’s not common practice to validate certificates, there’s often little incentive to present valid certificates in the first place. A brief experiment on Censys shows that about half of the mailservers that support STARTTLS use self-signed certificates.
On the web, when browsers encounter certificate errors, these errors are communicated to the end user, who can then decide whether to continue to the insecure site. With email, this is not an option, since an email user's client, like Thunderbird or the Gmail app on a user’s phone, runs separately from the machine responsible for actually sending the mail. Since breakage means the email simply won’t send, the email ecosystem is naturally more risk-averse than the browser ecosystem when it comes to breakages.
As a result, the ecosystem is stuck in a sort of chicken-and-egg problem: no one validates certificates because the other party often doesn’t have a valid one, and the long tail of mailservers continue to use invalid certificates because no one is validating them anyway.
Even If You’re Doing It Right, It Could Still Go Wrong
But let’s say you have STARTTLS enabled with a valid certificate, and so does the other party. You both validate certificates. What could go wrong?
When two mailservers support STARTTLS, their insecure connection is opportunistically upgraded to a secure one. In order to make that upgrade, the two mailservers ask each other if they support STARTTLS. Since this initial negotiation is unencrypted, network attackers can alter these messages to make it seem like neither server supports STARTTLS, causing any emails to be sent unencrypted. ISPs in the U.S. and abroad have been caught doing exactly this, and in 2014, several researchers found that encryption on outbound email from several countries were being regularly stripped.
Can DANE Fix These Problems?
Absolutely! If you are deep into the email world, you may have heard of DANE. DANE relies on DNSSEC, a protocol for publishing and validating signed DNS entries. Consistent and full DANE deployment presents a scalable solution for mailservers to clarify certificate validation rules and prevent downgrade attacks.
However, DANE is dependent on deployment and validation of DNSSEC, the latter of which has remained stagnant (at around 10-15% worldwide) for the past five years. STARTTLS Everywhere’s aim is to decouple secure email from DNSSEC adoption with a stop-gap, intermediate solution.
What About MTA-STS?
MTA-STS is a proposed standard that will allow mailservers to announce the security policies of their mailservers. In MTA-STS, a mailserver administrator creates a TXT record in their domain’s DNS entries, which indicates that the domain supports MTA-STS. They then post their security policy (whether to require STARTTLS or continue sending email on failure, which MX hosts to use, and how long the policy is valid) at a well-known HTTPS URL on their domain, so that senders can retrieve it and adhere to the policy.
The problem with MTA-STS is that since most DNS requests are still unauthenticated (see the section on DANE above), an active attacker can still MitM the initial DNS request and convince the sender that the recipient doesn’t support MTA-STS, and then later MitM the STARTTLS messages, so the sender will never know the recipient supports STARTTLS.
Wow, Everything’s So Messed Up. How Is STARTTLS Everywhere Going to Help?
We have three primary goals for STARTTLS Everywhere:
Improve STARTTLS adoption.
We want to make it easy to deploy STARTTLS with valid certificates on mailservers. We’re developing Certbot plugins for popular MTA software, starting with Postfix, to make this a reality.
If you run a mailserver and use Postfix, help test out our Certbot plugin. Please note that the plugin is still very much beta—if you have problems with it, you can report an issue.
Not using Postfix? We’re also working on Certbot plugins for Dovecot and Sendmail, so stay tuned. We also welcome contributions of installer plugins for other MTAs!
Prevent STARTTLS downgrade attacks.
In order to detect downgrade attacks, we’re hosting a policy list of mailservers that we know support STARTTLS. This list acts essentially as a preload list of MTA-STS security policies. We’ve already preloaded a select number of big-player email domains, like Gmail, Yahoo, and Outlook.
If you’d like to add your email domain to the list, try out our website; otherwise, you can also email starttls-policy@eff.org with validation details or submit a pull request yourself to the code repository where we host the list.
If you’d like to use the list, check out our guidelines for how to do so.
Lower the barriers to entry for running a secure mailserver.
Email was designed as a federated and decentralized communication protocol. Since then, the ecosystem has centralized dramatically, and it has become exponentially more difficult to run your own mailserver. The complexity of running an email service is compounded by the anti-spam arms race that small mail operators are thrust into. At the very least, we’d like to lower the barriers to entry for running a functional, secure mailserver.
Beyond developing and testing Certbot plugins for popular MTAs, we’re still brainstorming ideas to decentralize the email ecosystem. If you work on easy-to-deploy MTA software, let’s get in touch.
You can help, too!
All of our software packages are currently in a developer beta state, and our team is stretched thin working on all of these projects. You can help make the email ecosystem more secure by:
- Preloading your email domain on our policy list
- Contributing to or reporting feature requests to STARTTLS Everywhere
- Helping implement and promote security features, like MTA-STS or DANE validation, in MTA software
- Contributing certificate installer plugins for MTAs to Certbot
Of course, if you appreciate the work we’ve done on STARTTLS Everywhere, you can also donate to EFF! Your contribution will help further development of projects like STARTTLS Everywhere that help raise everyone’s level of security.
With all that we have accomplished together to improve the state of encrypted communications on the Internet, it’s about time we focus on upgrading email, the backbone of communication for a large part of the world. STARTTLS Everywhere is a natural step in that direction, but there’s still plenty of work to do, so let’s get hopping on hop-to-hop encryption!
