At Proton(nieuw venster), your security is always our first priority. That’s why, in recent months, we have added support for MTA-STS, DANE, WKD, DNS CAA, and much more to Proton Mail(nieuw venster) to further enhance your security.
We know that many people, such as journalists, use Proton Mail for sensitive communications and may be targeted by highly sophisticated threat actors. As part of our ongoing security efforts, we have released several new features to improve the security of all Proton Mail users.
This article describes Proton Mail’s new security features and explains how they keep you safe. At the end of the article, we also discuss some of the other upcoming Proton Mail features we have planned for this fall.
Web Key Directory (WKD) – a better way to look up public keys
Quick summary: You’ll be able to send encrypted messages to non-Proton Mail PGP users without having to import their public key. This is another step toward making end-to-end encryption the default for all email communication.
Proton Mail is built on top of the OpenPGP standard(nieuw venster), and interoperability has long been a priority for us. This is why we released full PGP interoperability support(nieuw venster) for all our mail clients in 2018. However, key discovery has long been a challenge in the OpenPGP ecosystem because it’s difficult to know whether to trust the keys you receive from a public keyserver. A new approach, called Web Key Directory (WKD), leverages the web to allow a domain to serve its own keys via HTTPS. Proton Mail has supported an early version of WKD since 2018, but we have recently revamped our implementation to match the latest specifications. This should allow any WKD client to retrieve keys for addresses on our proton.me, proton.me, and proton.me/mail domains automatically, making it easier for Proton Mail to have end-to-end encryption with non-Proton Mail users.
Brand new, however, is Proton Mail support for external key discovery via WKD. Our servers will now use WKD to look for keys on external domains, meaning that anyone can set up their domain or service for full end-to-end interoperability with Proton Mail. In practical terms, this means you may notice the green padlock that indicates your message is encrypted when you send an email to a non-Proton Mail email address, even if you have not uploaded a key for them. Full WKD support will be rolling out across all Proton Mail apps in the following weeks.
DANE and MTA-STS – thwarting active attackers
Quick summary: We implemented two security “rules” for our servers that basically force other servers to always send encrypted data. This means it’s now much harder for hackers to intercept emails between Proton Mail and non-Proton Mail accounts.
DNS-based Authentication of Named Entities (DANE) and Mail Transport Agent Strict Transport Security (MTA-STS) are two separate web standards that do roughly the same thing: protect email transport encryption (SMTP TLS) from attacks that remove this encryption. For emails sent between Proton Mail accounts, this is less of a concern because message contents are always end-to-end encrypted by default. But to protect messages exchanged between Proton Mail and outside email accounts, it’s important to ensure the transport encryption is secure against this kind of attack.
The problem is that in the early days of the Internet, there was no transport-layer encryption for either the web or email. This meant that emails from your email server to your recipient’s email server were sent in plaintext that anyone monitoring the network could read — no privacy at all. When TLS encryption finally arrived, there were thousands of mail servers that did not understand the new encryption standard. To ensure mail delivery, the standard requires that mail be delivered unencrypted if the remote server does not support encryption.
Therefore, TLS encryption is effective against passive attackers who are recording network traffic. The problem is that the discussion between the servers about encryption support is itself unencrypted, and can therefore be modified by an active attacker. The attacker can delete the message from the destination server which says that it supports encryption and force unencrypted mail delivery, which the attacker can then intercept.
The protocol used for web traffic (HTTP) had a similar problem, and it was largely solved via a standard called HTTP Strict Transport Security (HSTS). This standard allows a website to advertise via an HTTP header that it supports encryption (HTTPS). The browser caches this information for a long time, usually several weeks. While HSTS is a trust-on-first-use (TOFU) mechanism, the long lifetime ensures that transient attacks are usually thwarted, and modern browsers typically have a preloaded list of websites that must use HTTPS to address the TOFU loophole as well.
MTA-STS is HSTS for email. The sending mail server looks up and caches an MTA-STS policy, which tells it that the receiving mail server supports encryption. Once it has this information, it knows to refuse any attempts to downgrade its connection with the destination mail server. It relies on a long cache time to prevent transient attacks.
The downside, however, is that each mail server must maintain its own cache. That cache will also only contain policies for servers it has contacted recently. This works well for popular domains such as proton.me. It is not as effective between small domains with low email traffic. The policies for these domains are unlikely to be cached and can, therefore, be blocked by an attacker who can control DNS lookups. Our MTA-STS implementation works with most of the major email service providers.
DANE works via a different mechanism. With DANE, an email provider publishes DNS records which tell other mail servers that it supports TLS encryption. Even better, it tells the receiving server to expect a certain certificate when connecting to the sending server. This can foil attackers in possession of an otherwise valid TLS certificate for the mail server in question. It also works well for smaller email domains with low traffic because it does not rely on caching. However, it does rely on the security of the DNS system, which means it requires DNS Security Extensions (DNSSEC), and it has had limited adoption as a result.
Both MTA-STS and DANE have their pros and cons, and neither is perfect. However, they each can foil mail delivery encryption downgrade attacks under the right circumstances. So we have implemented both of them for proton.me, proton.me, and proton.me/mail. DANE also gives some protection for the thousands of custom domains we host by securing Proton Mail’s MX records, especially if the custom domain implements DNSSEC.
Expect-CT and Public-Key-Pins-Report-Only – an alarm system against eavesdroppers
Quick summary: These two headers make it easier for us to detect fake certificates and prevent man-in-the-middle attacks against our users.
Expect-CT is a new security header which is, at the moment, only supported by Chrome and Opera browsers. It allows a website to instruct the browser to reject any certificate not found in Certificate Transparency, a read-only public log of certificates which can be audited. Because Expect-CT is an HTTP header, it is a trust-on-first-use protocol that relies on long-term caching to ensure security. While Expect-CT does not prevent a compromised Certificate Authority from issuing a fake certificate, it does limit the damage by forcing the addition of the certificate to the log. The domain owner can then report the fake certificate and attempt to get it revoked.
HTTP Public Key Pinning (HPKP) is an older protocol that is being deprecated by most major browsers because it is too dangerous to use in practice. What HPKP did was allow a website to specify which TLS keys a browser should accept for the site, similar to DANE. However, unlike DANE, HPKP is another trust-on-first-use protocol that relies on a long-lived cache for security. This combination made it extremely easy to destroy one’s site either accidentally or on-purpose by publishing a bad header with a long lifetime.
HPKP, however, has a report-only mode, which is not dangerous and is useful in detecting man-in-the-middle (MITM) attacks or misconfigurations. While the report-only mode is likely to be removed eventually in favor of Expect-CT, we will continue to use it to monitor MITM attacks against our users for as long as it remains supported.
DNS CAA – a check on certificate authorities
Quick summary: Certificate authorities are trusted third parties that issue certificates that verify a site’s servers are legitimate. We’re now using a record that helps prevent certificate authorities from issuing a hacker’s certificate.
Nothing can prevent a compromised certificate authority (CA) from issuing a valid certificate that they should not, which is a fundamental problem with the CA system in general. However, the chances of a CA being tricked into issuing a bad certificate can be reduced by adding a Certificate Authority Authorization (CAA) DNS record. These records specify exactly which CAs, if any, are allowed to issue certificates for a given domain or sub-domain, and are checked by most reputable CAs. This will reduce the odds of an illegitimate Proton Mail certificate being improperly issued and used to create a fake Proton Mail site or launch a man-in-the-middle attack.
New reporting mechanisms to ensure delivery
Quick summary: Extra layers of security can complicate email delivery, so we’ve installed monitoring that will keep an eye out for any issues.
Many of the previous protocols, if deployed incorrectly, can cause serious mail delivery or site accessibility issues. Most also have a mechanism to report policy violations, which is vital for detecting configuration issues and attacks. While we have long monitored other mail delivery and security reports, such as DMARC and Content Security Policy (CSP) violations, with this update we are now also monitoring Expect-CT, HPKP, DNS CAA, and SMTP TLS issues (DANE/MTA-STS). SMTP TLS issues are monitored via TLSRPT, a new standard that reports TLS connectivity problems experienced by applications that send email. This additional monitoring will give us a better awareness of both attacks and non-malicious problems experienced by our users.
Further work
We’ve accomplished a lot in the past few months, but much work remains left to do. Both MTA-STS and WKD support for custom domains hosted at Proton Mail would require domain owners to request new TLS certificates and set up a reverse proxy to Proton Mail. This is inconvenient for our users, and we would like to build an automatic way for custom domain owners to integrate MTA-STS and WKD support.
While DANE and MTA-STS work against downgrade attacks, they do nothing in cases where the remote server does not support TLS, or has not configured MTA-STS/DANE and is under attack. We would also like to allow our users to require that their email be sent externally only over TLS, either as a global setting or for specific contacts.
Upcoming releases
In the coming weeks and months, we will continue to roll out several other significant releases. Many users have asked for multi-user support on our mobile apps. We have heard your requests, and we will be releasing this shortly on Android, with iOS to follow. As part of our security initiatives, we are also conducting an independent security audit of all Proton apps. As these audits are completed in the coming months, we will publish the results and open source even more software. We are developing an encrypted search of message content, and we hope to release this on mobile clients before the end of this year. This feature is also coming to the web version of Proton Mail.
Finally, we continue to work on Proton Mail 4.0, which is a completely redesigned version of Proton Mail’s web app that also features Proton Calendar(nieuw venster), a fully encrypted calendar. Because we wanted to get this security release out first, Proton Mail 4.0 is now scheduled for Q4 2019. We will be sharing regular updates on social media, so follow us to get the latest news. We look forward to making Proton Mail not only more secure, but also easier to use!
Best Regards,
The Proton Mail Team
You can get a free secure email account from Proton Mail here(nieuw venster).
We also provide a free VPN service(nieuw venster) to protect your privacy.
Proton Mail and Proton VPN are funded by community contributions. If you would like to support our development efforts, you can upgrade to a paid plan(nieuw venster). Thank you for your support.
