Mailcow-dockerized: Mail Crypt

[ghost]

Hi,

could we think about to optin Mail Crypt?
https://wiki.dovecot.org/Plugins/MailCrypt
Thanks

[andryyy]

I'm working on it.

[ghost]

On a way only user cand acces the mail?
Or does the root still have access to the keys and the mails?

[andryyy]

The keys are encrypted with the users mailbox password.

[ghost]

Nice

[ghost]

Is there maybe a way to create a blog or news page where informations like this will be showing

[andryyy]

https://mailcow.email/

:-D

[ghost]

LOL

[andryyy]

There were a lot of things, that required changes... :-(

We need a SELECT plain_text_password ... in the userdb (or passdb) query to read the plain password and decrypt the encryption key in Dovecot. We now use socket communication with SQL to hide this information from the network.

To set the key password we use dockerapi-mailcow, but we cannot curl our passwords there. So dockerapi-mailcow is now TLS-enabled. Key pairs are created by Python on-the-fly. (We cannot use our mail certificate, because it would break acme-mailcow, which needs dockerapi-mailcow to restart containers.)

But what happens when dockerapi-mailcow runs a command in dovecot-mailcow? It would show the password in the process list. So we now create a socket with the container and pipe or commands to a bash here (I fixed that for the Rspamd UI password, too)...

Aaaand, what happens when an admin changes a users login password? Passwords are out of sync then, mails cannot be decrypted. We need to add a warning for this.

Mail encryption will also be part of ACL and disabled by default.

Oh, the UI will also not work when it cannot find dockerapi-mailcow now. I implemented some checks to verify password changes etc., that heavily rely on correct execution of commands in dovecot-mailcow.

[ghost]

What is ACL?

Edit: Found it.

[Braintelligence]

LOL

Didn't you know that André is the best? ;)

[Braintelligence]

Just to clarify to be 100% sure:

• Are mails lost if >anyone< changes the password, or only if an admin does this? If they're not lost when a user changes the password, are mails re-encrypted then? If so, are they batch decrypted first, then batch encrypted (security implications) or are they decrypted and encrypted in a serial way and how long does this take normally?
• Is mail decryption client-agnostic, so you can use any IMAP client?

EDIT: typo

[andryyy]

I will probably switch to a global key...

The per-user stuff is stupid and of no advantage. It only brings problems with it, like forgotten passwords, password changes, it stores the keys in the mail attribute dict, it can be problematic for ACL (I run into a few bugs), FTS is very buggy with per-user encryption and much more...

And the most important fact is, that you can easily sniff the users password when you have access to the TLS key for IMAP (and other services). There is no additional security. Your administrator can always access your mails, if he really wants to.

I think the global key, stored outside the maildir, is the way to go.

I will stick to the other changes anyway. Like TLS for dockerapi etc.

[Braintelligence]

What would be the implications for wanting to change this global key in a case of security breach and would it be client-agnostic?

Edit: damn autocorrect x(

[andryyy]

You need root access to your mailcow server. As soon as you have root access to your mailcow server, you can do whatever you want, there are hundreds of ways to harm and sniff on users then. But that's applicable to every software. The key is stored in a volume outside the maildir and can only be read by the owner (dovenull, iirc, or dovecot) and root.
But as soon as you are root on your node, you can just use the key for IMAP, HTTPS etc. and sniff passwords. Keys need to be stored somewhere, that's unavoidable.

There will not be a difference in the UI for admins and users. But it is very, very important to backup your mail_crypt key. Without this key, access is lost until we can crack those keys.

[Braintelligence]

I guess Thunderbird/Outlook and other clients will be presented with server-side decrypted mails, then. (Correct me, if I'm wrong.)

What would be a typical case of security breach, where someone would have access to the maildir from outside (or maybe from the inside, because he/she has access to the same host, but not to the Mailcow-instance), but not to the encryption key?

EDIT: Perhaps reading out the underlying HDD? What if the Filesystem is encrypted?

[andryyy]

Yes, nothing changes, it is just that the maildir is encrypted.

Security breach? Hm, any service that runs as user vmail/5000 in Dovecot needs to be exploited. You'd gain access to all mails.

Or... using external/shared storage for vmail-vol-1. That's the biggest security gain we have. Imagine vmail-vol-1 being mounted on AWS, I'd rather not do this unencrypted. Whoever hacks the AWS storage has access to your mails then.

[Braintelligence]

That last part sounds interesting. That would definitely be an interesting use-case, though perhaps pretty cost-intensive/not viable for cold-storage buckets. But very interesting for shared storages on a VM hypervisor/central or self-owned shared storage on another host.

[ntimo]

Hey, I have three questions:

1. Will the existing mail be encrypted too or will only new email be encrypted?
2. How is the key secured? Does the Admin will need to enter a Passphrase to unlock it when restarting mailcow?
3. The docker volume with the mail crypt key will be backedup by the backup script too?

Thank you so much for adding this @andryyy this is one of my most wanted features 😍

[ntimo]

If you want to create a super secure system you probably would need to add a option to upload a pgp public key that is then used to encrypt all incoming mails. This way only a pgp enabled client will be able to decrypt the data with the proper private key.

[andryyy]

What holds me back from sniffing the key when you upload it?

[ntimo]

You could of course sniff the public key but that won't help you since you need to private key to decrypt the data on that would only be stored on the computer of the user. Also changing the key after or during upload with you own would be visible immediately since the user won't be able to decrypt data with his own key. Thats how https://protonmail.com works, and they are the leader in encrypted and secure email services. :)

[andryyy]

Ah, per PGP, yes, that would work. But "no", because that would break so many clients without PGP support.

One could write a web mail client like they probably did, to support this.

Back to mail crypt: using a password for the key is useless. You cannot give mailcow the password on start up, it would need to be permanently stored then. IMAP workers come and go, every worker needs the password. It would be stored in a place you can definitely grab it when you are able to grab the key, too.

PGP encryption is probably a way most of it can be avoided, but a) at heavy costs and b) more important: at some point the mail reaches your mailcow, when I gain access to the IMAP TLS key, I could sniff the traffic, when it comes in and catch the content of your mail unencrypted.

[ntimo]

Indeed that's true. So if I understand you correctly the key that is used to encrypt the vmail dir stored without a password that encrypts the key? Yes indeed if a attacker gains access to the host system there is indeed not much you can do. But using PGP he would not be able to read the stored mails ;). I am looking forward to this mail crypt implementation. Can't wait to start using it.

[andryyy]

It is very useful for when the maildir is stored externally or any Dovecot service with UID 5000 is exploited. When you use PGP, you are probably safe in all cases.

[ghost]

I updated to the latest version.
Where can I see that the encryption is active?

[Braintelligence]

@andryyy You even thought about updating the backup-script. I love you man <3.

[andryyy]

👍

You can just open a newly created file in the maildir and check the header.

[EnriqCG]

This is gold, thanks Andrew.

[ntimo]

Thanks @andryyy for adding this :). Is it possible to also encrypt the old mails that where already stored pre update?

[andryyy]

I just wrote this (and tested, but still, I recommend to change /var/vmail to a test mailbox like /var/vmail/example.org/test first):

Enter dovecot-mailcow by running docker-compose exec dovecot-mailcow /bin/bash.

# Decrypt /var/vmail
for file in $(find /var/vmail/ -type f -regextype egrep -regex '/.*[0-9]{10}.+,.+'); do
if [[ $(head -c7 "$file") == "CRYPTED" ]]; then
doveadm fs get crypt private_key_path=/mail_crypt/ecprivkey.pem:public_key_path=/mail_crypt/ecpubkey.pem:posix:prefix=/ \
  "$file" > "/tmp/$(basename "$file")"
  chmod 600 "/tmp/$(basename "$file")"
  chown 5000:5000 "/tmp/$(basename "$file")"
  mv "/tmp/$(basename "$file")" "$file"
fi
done

# Encrypt /var/vmail
for file in $(find /var/vmail/ -type f -regextype egrep -regex '/.*[0-9]{10}.+,.+'); do
if [[ $(head -c7 "$file") != "CRYPTED" ]]; then
doveadm fs put crypt private_key_path=/mail_crypt/ecprivkey.pem:public_key_path=/mail_crypt/ecpubkey.pem:posix:prefix=/ \
  "$file" "$file"
  chmod 600 "$file"
  chown 5000:5000 "$file"
fi
done

[ntimo]

@andryyy Thanks for the script. Could you add it the the wiki? And what do you think about adding a PGP option so the mails get encrypted with the gpg public key once they are delivered to the server. This would work great with rainloop as a web mailer since it supports openpgp.

[andryyy]

Rainloop will not be default. It does not come with ActiveSync and it is a strange clone of AfterLogics Webmail. I think they even sell Rainloop. See http://forum.afterlogic.com/forum_posts.asp?TID=5973 - I don't support them at all. Everything they fork from Afterlogic works fine, the other code is just a mess. :-/

We already have Zeyple integrated (but without docs, that's up to you guys, if you want to use it). It works great, just needs a docs review (there is an open PR).

Have you tried the code above? Did it work for you?

[ntimo]

I just installed a test VM and tested out the Zeyple stuff, and it works really really great the only problem I ran into is that the python-gpgme package is no longer supported by Ubuntu 18 so the package was replaced by python-gpg which does not work with Zeyple yet. One way would be to install the old package which worked for my testing but that's of course not the best way.

https://github.com/infertux/zeyple/issues/52

I haven't yet tried it manly because I have no mailbox I can safely try it with. But I will find a solution and test it out.

[andryyy]

Thank you very much for testing this!

Let's wait for infertux and see if he has plans to integrate it or a workaround. :-)

[alexanderadam]

Zeyple was recently removed (1, 2)?
Does anyone know why? Is there a replacement?