STARTTLS Everywhere is a project by EFF to improve the security of the email ecosystem. We want to increase and improve STARTTLS adoption and improve solutions for downgrade attacks on secure email communications.
This tool checks whether your email domain…
- “STARTTLS” is the command an email server sends if it wants to encrypt communications (using Transport Layer Security or “TLS”) with another email server. If your server supports STARTTLS, that means any other server that supports STARTTLS can communicate securely with it.
- Does your email server send the STARTTLS command correctly, and does it accept the STARTTLS command from other servers?
Uses a secure version of TLS?
- TLS has changed many times over the years. Researchers have discovered security flaws in some older versions, named “SSLv2” and “SSLv3”, so technologists across the Internet are working to deprecate SSLv2/3.
- Does your email server disallow establishing a valid TLS connection over SSLv2/3?
Presents a valid certificate?
- Even if you think you’re talking to a service named “eff.org”, it could be an impersonator pretending to be “eff.org”. Checking a mail server’s certificate helps ensure that you really are talking to the actual service.
- In order for your certificate to be valid for your email domain, it should be unexpired, chain to a valid root from Mozilla’s CA certificates list, and one of the names on the certificate should either match the domain (the part of an email address after the @) or the server’s hostname (the name of the server, as indicated by an MX record).
Preloaded on our STARTTLS policy list?
- Even if you pass the above checks, someone sitting between your server and other mailservers can choose to drop “STARTTLS” messages and fool servers into thinking that you do not support TLS.
- To prevent this from happening, if you pass all the previous checks, you can add your domain to our index of high-security email domains so servers have another point of reference to discover that you support STARTTLS encryption.
DANE, or DNS-based Authentication of Named Entities is an Internet standard which could on its own do what MTA-STS + the preload list would cover combined. It’s a downgrade-resistant way for mailservers to discover and publish each other’s TLS information using another technology called DNSSEC. DNSSEC is a protocol for signing and verifying statements by owners of domain names.
DANE has been around for a while– so why doesn’t everyone use it already, and why do we need MTA-STS in the first place? DNSSEC presents some challenges. * If your domain’s TLD doesn’t support DNSSEC, then your mailserver cannot utilize DANE. A large majority of TLDs are DNSSEC-signed, but many country-code TLDs remain unsigned. * DNSSEC can be difficult to deploy correctly, for both signing and validation. For instance, to do validation properly, the mailserver needs a local, trusted DNSSEC-validating resolver; otherwise, your server relies on upstream DNS resolvers for validation. DNSSEC adoption has unfortunately remained stagnant (validation is at around 10-15% worldwide) for the past five years.
We still recommend deploying DANE for email security if you have the resources to maintain DNSSEC signing and validation properly. The Internet Society has a good explanation and list of related resources and Viktor Dukhovni’s slides from ICANN contain lots of DANE deployment best practices.
MTA-STS was designed in the absence of a technology like DNSSEC. It bootstraps trust off the WebPKI Certificate Authority ecosystem (that secures HTTPS), but is not a perfect solution either.
Do you have STARTTLS enabled?
First thing’s first: consult your mailserver’s documentation or contact your hosting provider about how to enable STARTTLS for your mail delivery.
Are your TLS parameters secure?
There’s a tradeoff in the mailserver world you’ll need to make between backwards-compatibility (so you can encrypt with as many mailservers as possible) and requiring strong security. Here are some various things we recommend you do to make your mailserver robust, while still allowing it to encrypt with modern mailservers.
Is your certificate valid?
Standard practice is to obtain a certificate matching the hostname of the mailserver. However, you can also obtain a certificate matching your email domain (the part of the email address after the @) for a stronger security guarantee.
You can obtain a valid certificate automatically and for free from Let’s Encrypt using Certbot! Consult your mailserver documentation or contact your hosting provider for how to install these certificates.
Do you have some sort of downgrade prevention?
Since STARTTLS negotiation is done in the open, the process of upgrading an email connection to TLS is susceptible to tampering. There are a couple of proposed solutions for this, each with varying degrees of effectiveness and ecosystem support.
DANE, or DNS-based Authentication of Named Entities, is an Internet standard designed for mailservers to publish and validate TLS information over DNS. Its security relies on DNSSEC, a protocol for publishing and authenticating signed DNS entries. The What about DANE? FAQ entry has more details.
MTA-STS + Preloading
The STARTTLS Policy List’s aim is to decouple secure email from DNSSEC adoption with a stop-gap, intermediate solution to secure email delivery today rather than later. The list will preload TLS policies for domains that support MTA-STS.
There’s two sides for MTA-STS to work. When an email is sent: * the receiving server must have its MTA-STS policy up, advertising correct TLS information * the sending server must be able to look up and remember the other server’s MTA-STS policy Our checker confirms whether a server has MTA-STS receiving support and offers suggestions if it detects misconfigurations. It’s difficult to check for sending support in an automated way. Of the larger mail providers, Gmail has sending support by default, and domains using Gmail can turn it on.
MTA-STS is not perfect; before server A has discovered server B’s TLS information and vice versa, connections between the two can be downgraded in /faq#insecure. That’s where the STARTTLS policy list comes in, to pre-load the TLS information for various heavy-use mailservers as well as individual opted-in mail providers and servers.
MTA-STS support is on the rise.
The STARTTLS Policy List is a list of email domains who meet a minimum set of security requirements.
By providing a list of email domains that support TLS encryption and present valid certificates, the STARTTLS Policy List gives mailservers another point of reference to discover whether other mailservers support STARTTLS. Then, if a man-in-the-middle prevents a sender from receiving a recipient’s “STARTTLS” message, the sender will know that an attack is occuring if the recipient domain is on the STARTTLS Policy List.