Follow

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 What's your threat? Protecting the users from the sysadmins? Protecting users from flaws in the mail system?
Generally speaking, encryption is only as good as the key management, and getting users to be responsible for key management is often too difficult for a general population.

@jerry tutanota, not sure about the server though

@JustReading this is exactly what I’m looking for, but with something I can run myself.

@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.

@algernon @jerry and very specifically, even if I were enticed but the (small) benefit it provides, I would not use it without 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.

@algernon @jerry sure, but gain-root-exploits are a-plenty, I do not really consider this a very strong security boundary.

If one is worried enough about security to encrypt mail files, one perhaps would consider keeping them on a separate dedicated machine (or VM), where nobody else has user accounts, and no other services are running.

And in such a case the attacker would have to exploit the OS or the mailserver to get in. If they are able to do that, they are probably able to gain root to.

@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 That assumes that the encryption keys are held in memory long enough, and the attacker knows where to extract them from.

Those are already considerably harder to do than just reading files from a mounted volume.

@rysiek @jerry To highlight another advantage of using encryption on top of FDE, consider this: separate file & mail server. If attacker gains access to the file server, with FDE alone, they can read all mail. With the mail_crypt plugin, they don't, and as dovecot is running on a different server, they'd have to gain root there too.

Even if they were on the same server, mail_crypt on top requires the attacker to put considerably more effort in. Just FDE alone is kinda weak.

@rysiek @jerry Mind you, FDE is awesome, and it's very useful to help protect against different kind of attacks. Eg, unauthorized offline access, or against attacks against the backups / snapshots / whatever.

It's just that when a volume is already mounted, FDE does nothing. That's where additional schemes come into play.

@algernon @jerry as I said, it only makes sense to me in conjunction with disk encryption, and even then I feel it offers very little actual benefit.

@rysiek @jerry Yes, definitely in conjunction with disk encryption. I prefer encryption on top, because I can keep storage & mail servers separate, so if someone gains access to my storage server, they still can't read my mail.

If someone gains access to my mail server, they can only read mail they can obtain the key for. For example, they'll never read my archived mail, because I never directly log into the archive accounts.

Those extra protections I find very beneficial on top of FDE.

@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.

@algernon @rysiek @jerry As I use the global key setup, once a user logs in vial imap, dovecot decrypts on the fly before sending traffic to the client. As I only allow imaps, transport is TLS encrypted.

@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 @algernon @jerry First of all - per user keying is still considered not ready for production use. You can read more about the inner workings at doc.dovecot.org/configuration_

@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.

@rysiek @jwildeboer @jerry This has the added benefit that if the attacker manages to dump an unencrypted symmetric key from memory, the mail they will be able to read are limited.

If they manage to obtain the private key, they will still be limited to reading that particular user's mail, rather than all of them.

If they manage to obtain all private keys, only then can they read all mail. That involves many ifs, and much additional effort over simply gaining root.

@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 ;)

@rysiek @jerry Do note that unencrypted keys only appear to be used by per-folder encryption, which is considered an experimental feature. Global (as in, not per-folder) encryption will use RSA/EC keys, and does not support unencrypted ones.

@jerry There's a postfix extension being worked on that encrypts incoming mail with users public key. Not sure if this is what you're looking for, but if it is, see https://lacre.io for more info.

I'm involved, so feel free to ask about it. Just please note I'm on vacation. :awesome:

@jerry you do realize that the "S" in SMTP, stands for "Simple" not, "Secure", yes?

By default, all SMTP traffic is plaintext in transit, let alone worrying about it at rest.
SMTPS (Simple Mail Transfer Protocol Secure) at least addresses the in transit part, with TLS, which has multiple commercial MITM attacks, as a given.

Robert Morris (formerly of Bell Labs and the NSA) advised against ever trusting email for anything secure. He was smart, heed his warning, please.

@jerry

If you want a protocol which treats server operators as a threat, SILC (Secure Internet Live Chat) is an outlier insomuch as it does encrypt messages from server operators, by design.

It is possible, to encrypt messages even more than what SILC provides, if perhaps you don't trust SILC, despite its robust design.

For example, I released a proof of concept demonstration running OTR on top of SILC in 2014.

It's probably possible to recreate that work, or something like it today.

@byterhymer thanks for the response. My question wasn’t about smtp - I’m quite familiar with it and the security implications.
My question is with regard to protecting a trove of e-mail once it’s landed on a server to minimize the impact of, say, a ransomware attack that steals a copy of the mail files.

This is for a system I administer for family and friends. I want to limit my and others’ ability to get to the data that is stored on it. I am aware that, as the admin, there’s always going to be a way for me to find a way, but I’d like to minimize it. Was thinking of a system where the something like when the smtp server hands of local mail to procmail for delivery, it would encrypt email for an account with the account’s private key, and a utility like dovecot could session decrypt the private key to decrypt and deliver the previously encrypted mail.

@jerry yeah, I grokked that & you had plenty of other replies.

Precisely *none* of them inspired confidence.

But then, I've worked with people who were more than well versed in ripping SSH passphrases out of memory on Linux boxes using tools such as strace.

I haven't known such individuals to perform similar attacks against SILC, which is why I mentioned it. SILC was designed with that threat model in mind.

SMTP, was not.

Despite lots of glue & duct tape, I still would trust Robert Morris.

Sign in to participate in the conversation
Infosec Exchange

A Mastodon instance for info/cyber security-minded people.