Mailfence “End-to-End Encryption”
Mailfence is a well-known email service provider to the privacy-conscious. “Secure and Private” is its tagline. They tell users that “encryption happens in the browser” and “it is impossible for anyone (including us) to read your email along the line”. They offer password protected encrypted email, along with the more standard OpenPGP pubic key encryption. About OpenPGP they say “With end-to-end encryption, data is encrypted on the sender’s system and only the intended recipient can decrypt it. Nobody in between can read or tamper with it.”
When pressed further, Mailfence stated via email that “The symmetric encrypted (password protected) emails are zero knowledge and stored encrypted… This is the most secured mode.” Asymmetric encryption (OpenPGP), they say, is not zero knowledge. When challenged as to why they advertise end-to-end encryption with no warning that their Open PGP offering is less secure than their password protected option, they state, “Mailfence does offer an E2EE (end-to-end encrypted) email service. Our E2EE service is not yet zero knowledge for asymmetrically encrypted emails”.
For those of us who use “zero knowledge” and “end-to-end encrypted” almost interchangeably, this might be a good reminder to read the fine print. Unfortunately in the case of Mailfence, there is no fine print that would warn you that this is anything other than a “zero knowledge” email provider.
For those unfamiliar with the term, zero knowledge (when referring to email services), means no one can see the content of the email except the sender and recipient. Not even the email service provider. The magic of cryptography, hides this content from them. “End-to-end encryption” likewise, means that the email is encrypted on the senders device and not decrypted until it arrives at the recipients device.
The first clues that Mailfence is not completely zero knowledge are obvious to the cynical or suspicious user. While some encrypted email services such as Protonmail seemlessly hide the encryption behind a front end that looks very much like any other email service, Mailfence flaunts the encryption. If an email has been sent PGP encrypted to the Mailfence recipient they will see the encrypted content along with the option to decrypt with their passphrase. The list of emails in the inbox, show a lock symbol next to each email that is encrypted. A user can easily tell which emails are encrypted or not encrypted.
So let’s send a PGP encrypted email to another Mailfence user. This requires a user to choose encryption and specify OpenPGP. Once the email is sent, the recipient will find an encrypted email much like the above email in their inbox. But for the sender, they can go to their sent folder and find that same email, with a banner at the top telling them that “This email was sent encrypted”, but the stored copy is not encrypted. Mailfence has a readable copy of this email.
Even if a user drafts an email, it is stored in the draft folder. Just start a new email. Select OpenPGP encryption and begin to draft the email. Open the draft folder to again find a copy of this email that shows no sign of being encrypted.
In fact the moment a user clicks “Reply to” on an email they have decrypted and read, a copy of that email is sent back to the Mailfence servers and placed in the Drafts folder.
Taking a look under the hood, Mailfence’s claim that “encryption happens in the browser” is accurate. Fiddler (web debugging proxy) shows the encrypted message being sent to the server after being created in the browser. But it also shows the plaintext message being sent in the same HTTP POST. This is not surprising given the message is held, unencrypted in the sent folder.
Given that both the encrypted and plain text is being sent to the server, the only identifiable benefit of encrypting on the browser is that it could protect the users passphrase which is used to unlock the private key. Private key is used to sign the email before it is encrypted with the recipients public key. Some might suggest that there is also a marketing benefit of being able to state that “encryption happens in the browser”.
Since encryption happens in the browser, you’d be forgiven for thinking that decryption also happens in the browser. Investigations show that the encrypted message is sent from the browser of the sender to the browser of the recipient. But, when a user clicks “decrypt”, Fiddler shows the encrypted message being sent back to the server and the unencrypted text returned. The decryption happens in the server.
The obvious question at this point — why would the encryption happen in the browser, while decryption happens on the server. In an email Mailfence tell me their reason.
Server is involved only for parsing rich-text content (particularly complex inline and attached data). Text-only messages do not require that, and hence are not exposed to the back-end.
The handling of parsing complex data without penalizing performance, was the prime factor that lead to the involvement of server for decryption process. We use Bouncy Castle library on server side, that also covers other operations e.g., digital signature validation. We do plan to study and find reliable ways of carrying necessary operations to achieve zero-knowledge for our asymmetric message encryption offering. Steps like shifting onto (now mature) OpenPGPjs library for parsing-related and other operations are already underway.
This seems a legitimate reason. They do have complete control of the format of data when sending an email through their browser based app. This would no doubt make it relatively easy to parse. Given that their service receives PGP encrypted emails from any outside the Mailfence network, the format of encrypted data that could be received in the inbox could vary widely. It would be more complex to process as they say. Even emails from within the Mailfence network can originate from other email clients through their POP and IMAP services.
But the key question it seems is what users are expected to understand regarding their service. Their statements about encryption on their front page, along with the details they provide about OpenPGP encryption would certainly leave most users believing that Mailfence has no access to the content of their emails. There is no indication anywhere that their OpenPGP encryption is less secure than their password protected emails. There is no indication that they have access to the content of virtually all OpenPGP encrypted emails.
And they continue with the tenuous claim that the OpenPGP service that they provide is end-to-end encrypted, even if it is not zero knowledge. In email communications, they claim “Mailfence does offer an E2EE (end-to-end encrypted) email service. Our E2EE service is not yet zero knowledge for asymmetrically encrypted emails”. They have also said that they will review their communications and see where clarifications are necessary. And finally, they say that they are working towards a truly zero knowledge service for their OpenPGP encryption in future releases.
There is remaining questions and further research that can be done.
- I have not identified the method by which the passphrase is sent back to the server (or other method) to facilitate the decryption of email messages on the server.
- I have not looked at the claims that the password protected emails are secure and zero knowledge.
- I have done no study on the encryption itself, including the key creation and email encryption / decryption.
