1

I'm presently using mailfence.com

They claim all encryption happen in the browser and that they are zero knowledge.

My question is this: Where do they store my key. If my private key is stored on their servers, can't they decrypt all my mails?

Improve this question
  • What's unclear on mailfence.com/c/mailfence/more/crypto.jsp in fact ? (I mean you always have to type your passphrase to open your private key, hence why they can't decrypt your mail) this still mean you trust them to not store the passphrase when you type it. – Tensibai Feb 10 '17 at 16:49
6

I work at Mailfence as an Information security analyst.

Where do they store my key.

When you generate your keypair, we first encrypt it with your passphrase in the browser and then store it on our servers. This way, server never sees the key in plain-text, and a zero-knowledge framework gets established.

If my private key is stored on their servers, can't they decrypt all my mails?

No, we can't. As your private key is encrypted with your passphrase, which only you knows.

The blog-post Mailfence end-to-end encryption and digital signatures will give you more insights in this regard (including the open-source libraries that we use to perform crypto-based operations).

We are always open to external (legitimate) audits, and to further strengthen our transparency - we have also planned to go open-source. It's now only a matter of time and priorities.

Improve this answer
  • 1
    Client side encryption is not to be 100% trusted ... what steps are you taking to verify that eve is not tampering with the encryption.js coming from server side. What steps are you taking to mitigate malware in the browser from modifying the encryption.js. Do you have a browser independent clients side app? – CaffeineAddiction Feb 13 '17 at 14:38
  • @CaffeineAddiction: the js is under https, and malware is not on them, just like a kb wedge isn't put on window's security model... – dandavis Feb 14 '17 at 7:09
  • @CaffeineAddiction SSL/TLS, javascript obfuscation techniques, ... to name a few, against classic MITM based attacks (you can always verify our SSL cert. as well webmail cert., blog cert. ). For MITB, strict, hard-coded SOP policies are in place - but that always drops down to level of safe practices a user follows (as if the device is compromised, no protection will last). Yes, (browser independent) mobile apps are on our current priority list. – M Salman Nadeem Feb 14 '17 at 17:59
  • @MSalmanNadeem do you have a response for my Answer Below? security.stackexchange.com/a/151288/92213 – CaffeineAddiction Feb 14 '17 at 20:03
3

I'm not sure how exactly mailfence works, so the following paragraph is a theory on how it could work: Mailfence seems to work with asymmetric cryptography. So it would't be necessary to enter a password when sending mail. But in order to read encrypted mail adressed to you, you'd need to enter a password that locally decrypts your private key. This may all happen the moment you sign in to the service, e.g. some javascript uses the info you enter to sign in to fetch and decrypt your key, and then authenticates you to the mail service, possibly using the decrypted key to sign a challenge. So yes, its possible to build a zero knowledge mail service.

However:

  1. The browser is a notoriously insecure environment. It isn't possible to secure javascript. So if your browser is hacked by maware/malicious javascript, you lose.

  2. Mailfence could turn evil and send the decrypted private key back to their servers in the background, once it got locally decrypted. Nothing you can do to avoid that.

  3. Its likely that mailfence can read most of your mail, since most of your communication partners probably don't use encryption, so mailfence could read incoming unencrypted mail to you before they encrypted it, or read outgoing mail from you to someone that doesn't use encryption.

Improve this answer
  • "It isn't possible to secure javascript" is a bit misleading; it's no more vulnerable to malware than anything else, and given the attention and ease of user-verification, probably less vulnerable. – dandavis Feb 14 '17 at 7:14
  • nccgroup.trust/us/about-us/newsroom-and-events/blog/2011/august/… – CaffeineAddiction Feb 14 '17 at 8:20
  • @dandavis one big difference is also that the JavaScript code is basically downloaded each time you visit the website. Every one of this downloads is a potential chance for an attacker or evil provider to give you malicious code. It is also much easier to provide malicious code just to you and not all the other people using the service, compared to locally installed programs. – Josef says Reinstate Monica Feb 14 '17 at 9:35
  • use https, a csp, and when possible, the new integrity attribs on script resources to curtail such threats. – dandavis Feb 14 '17 at 18:17
1

The people behind mailfence seem like they are trying, but there are multiple underlying flaws with there design ... many of which they simply cant fix as they are inherent to the underlying architecture that they are using. While there are many problems, the biggest of these is:

They Require you to upload a private key

Ok, so they need to encrypt your content in the client side ... and a reasonable way to do that is with a Private-Key ... the problem is that since this is a web app and you will need the Private-Key on multiple different devices ... they have to send it to the server. This is a problem for many reasons:

  • The private key is passphrase protected ... right? Sure, but who gave you the algorithm to protect that Private-Key? Also, who gave you the algorithm to securely encode your content with the Private-Key? You dont trust mailfence.com with your clear text content ... but you trust them to provide you with the code to protect your content and the key used to protect that content from them? Again, im sure the people at mailfence.com are all decent people ... but if you are going to trust them with the door, the lock, and the key to the lock ... you might as well just trust them with what is on the other side.
  • Even if mailfence.com used a third-party cdn to host the code to create, employ, and protect your private key ... and that third-party was somehow indisputably secure ... the browser still has a malleable runtime. This means that if you loaded super-secure.js from untouchable-cdn.com ... if mailfence.com has a single line of javascript code coming from anywhere else it has the potential of overwriting the functions of the super-secure.js library ... there is no way to prevent this.
  • If you generated your private-key via the commandline with a passphrase and then pasted it into your browser ... you are still storing your private key on there server. This means that in the off chance there was a security breach at mailfence.com ... someone could obtain your passphrase protected private key and start brute force decryption. Granted, this is no more or less secure than google generating and employing an encryption key server side to encrypt all your user content, however, it is very much less secure when compared to having never given them access to your private key in any form.

... There are still further problems some of which can be found here though it was written in 2011 and some of the issues are no-longer true for current browsers.

further issues that could be elaborated on later if I find the time:

  • Javascript based garbage collection ... and lack of a way of forcibly 'deleting' secrets from memory
  • lack of a secure random number generator (not sure if this is still true)
  • A way to generate and store private keys that doesn't depend on an external trust anchor. (partially covered above)
Improve this answer
  • A nitpick to your first point about trust: While I agree with the general sentiment, still, assuming Mailfence is an upstanding company, you're better off with their zero knowledge implementation than without it, because it defends against several attacks which would otherwise succeed (e.g. disgrunted employee who steals a backup with customer data on it, hackers who manage to eavesdrop on all Mailfence data, but not change or inject any, especially not in the js codebase, etc). So its not quite as all-or-nothing as you make it sound. – Out of Band Feb 14 '17 at 11:43
  • See, that's part of the problem ... it doesn't defend against these attacks. In the case of a disgruntled employee ... it would require them to change 1 line of code ... and the whole system is void the next time you log in ... and in terms of eve being able to monitor the connection but not change anything ... that isnt prevented by there "added security" ... its prevented by SSL/TLS. – CaffeineAddiction Feb 14 '17 at 15:17
  • Further, either the company knew about all of the problems I described above and decided to continue anyway ... or ... they didn't know and thus do not understand the basic principles of encryption and security. In either case, these are not people I would trust with any of my information – CaffeineAddiction Feb 14 '17 at 15:20
  • 1
    Well, you're right that if the disgrunted employee is one of the programmers, it's hopeless. If it's someone else, he might not know how to break the system.You also don't know what kind of security protocols they have in place to protect their code (which, of course, is an additional trust problem). As for Eve, if she has access to data at rest, or traffic behind the SSL Terminator, it will make a difference whether there is an additional layer of encryption. Security in depth... but we agree on the fact that this scheme offers much less protection than it seems to suggest to customers. – Out of Band Feb 14 '17 at 17:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.