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.
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.
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.
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.
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.
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 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.
@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.
@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.
@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 https://doc.dovecot.org/configuration_manual/mail_crypt_plugin/
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.
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.
@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.
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.
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.
@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.
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.
A Mastodon instance for info/cyber security-minded people.