Security is one of our core priority, with privacy. We work hard to provide our users the most secure and private experience when using Mailfence. Many users, such as journalists or dissidents use our service for sensitive communications. They are often targeted by advanced persistent threats. Over the past years, we released several new features to improve the security of all Mailfence users.
From DANE to MTA-STS, WKD and VKS, let’s focus on our security improvements to keep your data safe.
DANE and MTA-STS
Why you want it
DNS-based Authentication of Named Entities (DANE) and Mail Transport Agent Strict Transport Security (MTA-STS) are two separate protocols that primarily address the same issue, commonly known as downgrade attack. Simply put, an attacker can remove the encryption layer during transport of emails. It is therefore important to have a mechanism that ensures that transport encryption remains intact when emails go from one to another account.
In the early days of the Internet, email servers would send and receive emails in plain-text—without transport-layer encryption. This meant that anyone monitoring the network could read or modify the message. After TLS arrival, the email standard was adapted to include transport encryption if both sending and receiving servers support it. However, an attacker can still trick sending server to pass email in plain-text by wrongly announcing that receiving server does not support transport-layer encryption.
How it works
MTA-STS is a protocol that ensures email delivery using Transport encryption (not to confuse with end-to-end encryption) if receiving server supports it. The sending mail server looks up and caches the MTA-STS policy of the receiving mail server. Depending on the receiving server MTA-STS policy, it will then refuse any attempt to remove the transport encryption layer. The sending server relies on a long cache time to prevent transient attacks. The downside, however, is that each mail server must maintain its own cache. Further, a domain owner can set but not enforce an MTA-STS policy.
DANE uses DNS records to inform other mail servers about TLS encryption support. Further, it tells the receiving server to expect a certain certificate when connecting to the sending server—defending against attackers in possession of an otherwise valid TLS certificate of the sending server. However, it relies on the security of the DNS system, which means it requires DNS Security Extensions (DNSSEC)—resulting in limited adoption (this is now changing).
Supporting DNSSEC (as a prerequisite to support DANE) also brings additional security advantages. Some examples include protection against DNS cache poisoning attack and to custom domains that use Mailfence’s MX records—especially if the custom domain implements DNSSEC.
Both MTA-STS and DANE have their pros and cons. Each of them can protect against mail delivery encryption downgrade attacks. So we have implemented both of them for mailfence.com.
OpenPGP key discovery & exchange (WKD & VKS)
Mailfence offers OpenPGP encryption and signature for emails. We have been interoperable with other OpenPGP compliant services since the beginning and provide our users full control over OpenPGP keys. However, key discovery and exchange 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 key server.
Web Key Directory (WKD)
Mailfence now supports a new approach, called Web Key Directory (WKD), which uses the web to allow a domain to serve its own keys via HTTPS. This means, when you generate an OpenPGP key pair or import it into your Mailfence account key store, the respective public key (including e-mail address and name) will be publicly available on our Web Key Directory server if:
- Associated email address is based on mailfence.com domain name.
- An association of user email address is made with the key User ID. A key icon next to From address in Message composer represents it.
- The key is associated with Mailfence account’s primary or alias address.
Public key is only served for, and with, queried User ID packet to not expose other associated User ID packets (for privacy and anti-spam reasons). We do not support Web Key Service (WKS) protocol.
Users can also download OpenPGP public keys from external domains (or services) that supports WKD into their Mailfence account key store. Custom domain owner will have to set it up for owned domain or can use WKD as a service.
Validating Key Server (VKS)
In the past, we used Synchronizing Key Server (SKS) pool. Following GDPR enforcement in 2018, we were looking for alternatives due to known data privacy concerns with SKS pool (which eventually closed down in 21-06-2021). We considered a number of public key servers, and finally settled with keys.openpgp.org. You can read more about them here.
They allow identity information (User ID: Display name and email address) to be distributed only with consent and also allow its removal. Check their privacy policy for more details.
You can find public keys using email address. Please note that keys with no User ID (display name and/or email address) are presently not processable on our side. We plan to address this in future.
Key lookup order
Our goal was to use a key discovery mechanism that provides:
- Positive confirmation of key ownership / Vandalism resistance
- Censorship resistance
- Decentralization
We did not find a medium that supports all three of the points above, so we decided to support multiple mechanisms. When a user looks for a public key, the Mailfence platform uses following key lookup order:
- Web Key Directory (WKD): Domain owner acts as a trust anchor for positive confirmation of key ownership (via TOFU model). If a public key is found, the key lookup process stops.
- Validating Key Server (VKS): Email address ownership is performed via double opt-in validation. Not being controlled/managed by a public key domain owner offers a level of censorship resistance.
Signature validation and public key status update is always done using VKS (no lookup order is involved).
We did not find a suitable mechanism yet that offers desired level of decentralization (one of the founding values of OpenPGP) and continue to keep an eye on ongoing efforts in this regard.
Others
- We started enforcing DMARC policy of senders. You can read more here.
- We started using DNS CAA record. This helps prevent certificate authorities from issuing an illegitimate Mailfence certificate.
- To keep an eye on TLS connectivity issues during email delivery, we keep an eye on reports submitted via TLSRPT standard.
- To protect our users from identity impersonation attacks, and our service from abuse, we have decided to forbid deletion of Mailfence domain name based alias addresses. This change will apply on 01-Jan-2022. Read more here.
Just as we always have, we will keep on improving our security to provide the best experience for our users. We will never stop to work on making Mailfence more private and secure. You can help us by contributing to our efforts. Learn more about Mailfence on our press page.
Follow us on twitter/reddit and keep yourself posted at all times.
