Encryption of stored emails
imc67 last edited by girish
As we know Dovecot it storing all emails of all users in plain text and so they are all readable by the person(s) who have access to the server.
I was wondering if it’s feasible to encrypt this for better privacy and security and found this: https://workaround.org/ispmail/buster/optional-server-based-mailbox-encryption/
Is this something to add to Cloudron, maybe as an option for those who don’t want it?
@imc67 Honestly, the level of extra security given by this is quite low : someone who has full access to the server will always be able to change the code running on it in order to get the decrypted stuff. However, if it's not too complicated to implement, why not
imc67 last edited by
@mehdi the only downside of this solution is that it’s based on password only. If you’ve lost it you can’t access your encrypted mail but don’t know how that is with changing passwords? May there is a solution that the correct combination in the end of password and username can match to a key.
@imc67 I think password changes would require the user to always type in their old password. The password-derived key could be used to encrypt a second, randomly generated key that is the actual key for encrypting emails, that way a password change would only require re-encrypting the random key, not the whole mailbox. Password resets by admin would be impossible unless you did something like encrypt the old key with a key derived from the admin's password too.
What about this: self-host your email storage & webmail, but have a cloudron running on a $5 vps that acts purely as a personal SMTP relay with pinned IP. Emails are never stored on disk, so at most a spying host can only see new correspondence as it flows. (Not perfect, but it's an improvement on just giving up.) Can cloudron be configured as an email relay for another cloudron? It would be nice if you could do that with the free version.
@infogulch yes, I've done it.
You add the domain.
You set up email for the domain.
You create a user & get credentials.
Then add user/credentials to other cloudron email setup to use this relay.
subven last edited by
With SSH and root access, you can take action against security measures such as encryption at any time.
The best change in my opinion was that normal administrators (non superadmins) of Cloudron do not have access to the backup configuration. Otherwise every admin would have been able to access the data (including email) via the backup regardless of backup encryption.
For me as a server admin it still doesn't feel great that sensitive email data is unencrypted on an (external) server. In this case, encryption is just an additional layer, but it helps a bit. Feels like not encrypting your Windows laptop just because you don't trust Microsoft and Bitlocker....
A few notes would be that I agree that this is likely not a huge priority insofar as protecting the on-disk data, but it would be a nice add. That said, to the point about using passwords as keys, that's a hard no - aside from the password-changing problems, it's recognized as a Bad Idea by the security community:
Verify that the architecture treats client-side secrets--such as symmetric keys, passwords, or API tokens--as insecure and never uses them to protect or access sensitive data.
A friend of mine created this very cool thing called PROTECT: https://github.com/jasonkresch/protect
Perhaps just simple full-disc encryption for your servers and access management would cover all this in the most battle-hardened, cpu-efficient and simple way?
subven last edited by
@marcusquinn FDE does not protect your data during runtime so this does nothing. You also have to somehow enter the encryption passphrase after reboots...not practical at all.
@subven All agreed - next-best alternative to nothing though.
I protect my emails by making sure that I have nothing valuable to say
@mehdi That is true in the case of a malicious admin. But it also places the benevolent admin in the position where they have the unencrypted data in their possession (or if full disk encryption is used, they have the keys).
However for some admins, mailbox encryption could also have benefits in cases where third parties attempt to gain access to data through legal disclosure orders.
As a journalist, I would like to be able to offer email accounts on my Cloudron to my peers. However, I would be uncomfortable being in a position where I might one day have to make a call on the validity of a disclosure order (and/or fight it in court on my users' behalf if I thought it was wrong). For me it would be much better if this responsibility rested with the users themselves.
In short, encryption of stored emails would be an extremely interesting feature for me.
@tomw Encrypting emails is literally my job ^^ What I'm saying is that this method of encryption would not offer what you are describing : a legal order could force you to implement a way to intercept the incoming emails before they are encrypted. It could even force you to intercept the password used to decrypt the email and decrypt them.
What you are talking about is proper end-2-end encryption, and it's quite hard to do it right
@mehdi And protecting source material is literally my job
I said mailbox encryption could be helpful against disclosure orders - not that it provides protection in all cases.
This is a fast-moving issue and the situation will be different in different jurisdictions and under different threat models.
But here's one data point to illustrate what I'm saying: in Germany, the email provider Tutanota was ordered to intercept future incoming and outgoing emails for a user account. But the previously received and encrypted emails were unaffected:
The Tutanota spokeswoman said the monitoring function will only apply to future emails this account receives — it will not affect emails previously received.
It won't always be like this in every situation. But just as there will be times when legal orders force admins to intercept encryption passwords, there will also be times when courts do not go that far and the encryption remains effective.
In my scenario, the owner of the mailbox would not be anonymous. The purpose of the encryption, for me, would be much more about shifting the burden of responding to a legal request onto the user, rather than attempting to provide a bulletproof technical solution.
@tomw There's a huge difference, it's that in Tutanota's case, the emails are decrypted client-side. In this proposed process, the emails are decrypted server-side. So basically, you would still be subject to legal orders.
Sounds like these journalists shouldn't be using email.
Could shift the burden onto them by advising them to use email with the assumption it is public data and to move any conversations that need to be kept private to specialists in this area like Signal.
Noting that NO encryption is complete when there are two parties as you cannot always guarantee the security of the receiver.
Then you think, well you could have voice calls over E2E encryption - but the receiver could record calls without knowing.
The ONLY secure communications is face-to-face without any electronics devices. Then, you still have the location data of the users before and after that could cross-reference their meeting to talk offline.
Basically, there is no privacy from a determined spy, which move the best protection to being the legal system, and therefore good access logs and protected multi-location backups beyond reach that could at least be used to hold any information demanders to the highest possible level of standards for their lawfulness in these extraordinary data access endeavours.
robi last edited by robi
I've used a non-email based "email" called Confidant Mail which is very good at the journalist type workflow and it supports unlimited file size transfers, E2E.
@robi Interesting. Would that be an app dedicated to that sort of thing? Perhaps there's others?
@marcusquinn It's a more general tool as an attempt to fix and replace the issues with Email in general. It does that well.
It just needs adoption.
https://privacytools.io has other options too