Are there any open source mail servers that store email in encrypted form? In a way that would be tough to recover from just access to the mail files?

@jerry Dovecot: doc.dovecot.org/configuration_

Mailcow uses Dovecot under the hood too, as do a lot of similar solutions that package up a whole lot of components required to self-host e-mail.

@algernon @jerry interesting. I am trying to understand how/where encryption keys/passwords are stored.

Seems like per-user encryption keys can be stored unencrypted on the server (which... kind of defeats the purpose), or encrypted with a password from an SQL database (which is perhaps a tiny bit better)?

I think I would prefer to rely on disk encryption (like LUKS) instead. Fewer moving parts and better-understood failure modes and threat model, at least from my perspective.

@rysiek @jerry I would not rely on disk encryption alone. That does exactly nothing when the attacker gains access to the mail files directly. It does not protect at all from the case originally asked: when the attacker has access to the mail files themselves.

Disk encryption + encrypting mail files on top provides more protection.

But yes, it's only as strong as the key management. Even unencrypted keys can provide more protection than just LUKS.

(more in next toot)

@algernon @jerry thing is, if the attacker is "in", all bets are off. If the mailserver is running (and it probably is, since the server is presumably running if the attacker got access to mail files on a system with disk encryption), all the attacker has to do is dump the memory of the mailserver process and extract the encryption keys from there.

Obviously that's one more step, and defense in depth matters, but reading the docs there makes me think it offers very little benefit over FDE.

@rysiek @jerry Yes, if the attacker has root, then all bets are off. But if the attacker does not have root, only enough permissions to access the mail files, then LUKS does nothing, but encrypting the files themselves (with keys unavailable to the user used to read the mail files) does.

@rysiek @jerry Eg, if I have FDE, and mail files owned by mail:mail, if I can get a shell as the mail user, I can read the files, FDE does nothing in this case.

If files are encrypted on top of FDE, I'd have to gain access to the keys, too. If I have a mail shell only, then that's a good few extra steps, especially if the keys are on another server, and need separate authentication to obtain, such as per-user passwords.

@rysiek @jerry Furthermore, with FDE only, if I have access to the mail user, I can read all mail. With per-user encryption on top, I'd need access to the keys too.

Also keep in mind that the keys themselves are encrypted too. So even if you have access to the keys, because you gained root, you still can't decrypt it, unless you figure out the password.

@rysiek @jerry If the key password is derived from the user password, you'd have to wait for the user to log in, dump the right slice of memory at the right time, and you'd still only have access to their mail, not all mail. Catching the short amount of time the password is in memory is tough.

If you don't catch the password, just the decrypted keys, that limits what you can do further, 'cos there are multiple symmetric keys used, and I'd think dovecot only decrypts those that it needs.

@algernon @jerry how is incoming mail handled? Left unencrypted until a relevant user logs in?

@rysiek @jerry Incoming mail is easy, it does not need to be decrypted, thus, it only needs the public key. With the public key, dovecot generates a new symmetric key, with which it encrypts the incoming one. No private key, no password in memory necessary.

Password and private key is only required to read the mail once it is stored, and that can be tied to user login.

@algernon @rysiek @jerry IIRC correctly, once the mail has arrived and dovecot puts it in the users mail folder, it gets encrypted. Depends a bit on how your mailserver is configured. In my case, all local handling is via lmtp, so postfix receives incoming mail, puts it in the queue, hands over to dovecot, who immediately encrypts.

@jwildeboer @algernon @jerry okay, but encrypts with which key?

If using per-user keys, and if keys are derived from user passwords, how does it encrypt incoming mail before the user logs in for the first time since server restart?

Does it do some fancy asymmetric key stuff?

@rysiek @jwildeboer @jerry It's documented on the dovecot plugin docs link I posted initially.

Global per-user keys are asymmetric, and dovecot encrypts mail with symmetric keys which are encrypted by the per-user keys. The symmetric keys are auto-generated.

So once dovecot receives the mail, it generates a symmetric key, encrypts the mail with it, then encrypts the symmetric key with the per-user key using its public part, and stores the encrypted symmetric key + mail in a file.

Follow

@algernon @rysiek @jerry And, again, IIRC, the public and private keys per user (more precise: per folder) are NOT stored at the client side, they all live on the server. So mails can be en/decrypted without the user having logged in.

@jwildeboer @algernon @jerry yeah, but if the mail can be en/decrypted without user having to log in, that also means that an attacker can do that without waiting for user to input their password.

@rysiek @algernon @jerry No. At least for the decrypting part when the user keys are encrypted, arriving email still gets encrypted before being stored, but decryption only works when the correct key has been given to unlock the private key.

@rysiek @algernon @jerry In general I wold say that mail-crypt does a fabulous job to make mail servers more secure but it is definitely not a full end-to-emnd encryption system a la GPG. But that was also never promised. It's task is to make emails at rest more protected. And that it does in a good way.

@rysiek @jwildeboer @jerry Encryption can happen without users having to log in because of asymmetric keys.

Decryption is as strong as your key management. If you store your private keys unencrypted, in a way the attacker can access it, then yes, they can use that to read mail.

You don't have to store the priv key unencrypted however. That will prevent server-side reencryption (no biggie, imo), but will also make it harder for the attacker to decrypt email.

@rysiek @jwildeboer @jerry If the priv key is password protected, then the attacker has to obtain the password too, or dump dovecot's memory at just the right time.

He'll still be limited to reading the email of the user they managed to obtain private keys for, rather than reading all mail.

Obtaining keys for hundreds of users is considerably more difficult than just obtaining root. Assuming the keys aren't left open in the wild.

@algernon @rysiek @jerry And if you prefer to not trust your mail server, you can always switch to good ole pop3 to remove the (encrypted) mails from the server ASAP ;)

Sign in to participate in the conversation
social.wildeboer.net

Mastodon instance for people with Wildeboer as their last name