Dovecot mail-crypt webmail can't read encrypted messages

[Serveria Support]

Yes, I agree, but why make bad guy's life easier? I mean you can do many 
things including renting a GPU cluster and bruteforcing the passwords 
but it takes time to do it and also expertise. Right now, all they need 
to do is make a few clicks and enable auth logging. Why don't just 
eliminate this extra attack vector?

On 2022-10-09 14:41, Aki Tuomi wrote:
> To add few more comments...
> 
> You speak about privacy that either you have it or not.
> 
> If you are not your own admin, the administrator will always be able
> to access your mails, there are only very limited ways for you to make
> it hard enough. With mail crypt, everything and all boils down to key
> management, which is more hard than you can imagine.
> 
> The decryption key must be somehow recoverable, otherwise the user
> cannot read their mail. So either it needs to be derived, or retrieved
> from somewhere. And at some point, it has to be in readable format.
> The only safe way to deal with decryption is to do it in a hardware
> device, and even this has problems.
> 
> To find out user's password you can turn on pre-login rawlogs, rawlogs
> in general, beef up logging, add various configurations that will
> assist in this. You can setup mitm attack with haproxy + dovecot to
> record all encrypted traffic in plaintext.
> 
> If you want your privacy, your best best is to be your own admin.
> Otherwise the house always win.
> 
> Aki
> 
>> On 09/10/2022 14:02 EEST Aki Tuomi <aki.tuomi at open-xchange.com> wrote:
>> 
>> 
>> > On 09/10/2022 12:53 EEST Serveria Support <support at serveria.com> wrote:
>> >
>> >
>> > Sometimes not. If the data stored in mail accounts is more valuable than
>> > the server and control over it.
>> >
>> > So this means passwords cannot be masked/hidden in the logs?
>> 
>> Passwords are hidden in logs, mostly. Debug logging unfortunately can 
>> leak some password information.
>> 
>> > You realize
>> > that it actually defeats the whole idea of encrypted storage? It's
>> > useless.
>> 
>> Dovecot mail crypt plugin is primarily intended for securing storage, 
>> especially one that is remote, like NFS or object storage. It is not 
>> intended for securing your server against malicious admins.
>> 
>> In production use, customers usually use a site-wide global keypair to 
>> encrypt the information stored in non-local storage.
>> 
>> > I can think of lots of scenarios: malicious system
>> > administrator reading users mails and blackmailing them or selling their
>> > business secrets to competitors, corrupt law enforcement in some
>> > countries getting rid of political or business opponents by disclosing
>> > the contents of their mails and I can go on and on and on...
>> 
> 
> 
> 
>> Yes, and mail crypt plugin is not intended for protecting these cases.
>> 
>> > There is no
>> > such thing as semi-privacy. Privacy is either there or it's not.
>> >
>> > What exactly Dovecot does to hide passwords in logs?
>> >
>> 
>> Turn on auth_debug=yes and see, you'll see passwords being masked.
>> 
>> > I've studied mail-crypt plugin's docs and it's written there:
>> >
>> > Also, it might be visible in debug logging. Suggested approaches are
>> > base64 encoding, hex encoding or hashing the password. With hashing, you
>> > get the extra benefit that password won’t be directly visible in logs.
>> >
>> > So how can I make passwords to be not directly visible in logs?
>> >
>> 
>> Aki
>> 
>> Use hex encoding, base64 encoding or hashing the password, as it says. 
>> E.g. %{sha256,salt=%{user}:password}. Directly using user's password 
>> for mail crypt keys is unsafe anyways, due to % being an expansion 
>> character.
>> 
>> > On 2022-10-09 11:39, Aki Tuomi wrote:
>> > > If you have intruder that is able to enable logs for your server, then
>> > > you have bigger issues than someone enabling logs to see passwords.
>> > >
>> > > Dovecot does it's best to hide passwords in logs, but unfortuntely
>> > > this isn't perfect.
>> > >
>> > > Aki
>> > >
>> > >> On 08/10/2022 23:49 EEST Serveria Support <support at serveria.com>
>> > >> wrote:
>> > >>
>> > >>
>> > >> Hi,
>> > >>
>> > >> I'm here with a follow-up. I have managed to fix this issue!
>> > >>
>> > >> I have rebuilt the entire project from scratch, using vanilla versions
>> > >> of Dovecot, Postfix, SOGO webmail etc and everything works as
>> > >> expected:
>> > >> emails are getting encrypted, I'm able to send, receive and read
>> > >> emails
>> > >> in webmail. I suspect the root of the issue was that I was using
>> > >> software package called iredmail. My guess is that all the master
>> > >> admin
>> > >> drama was caused by iredmail. Big thanks to you guys for the hints and
>> > >> ideas which eventually helped me troubleshoot this issue! I appreciate
>> > >> your assistance.
>> > >>
>> > >> P.S. Btw, is there any way to hide plain text passwords from Dovecot
>> > >> log
>> > >> files? Disabling auth debugging won't help as the system may get
>> > >> compromised and the intruder can re-enable logs and grab the passwords
>> > >> from the logs. The only person who should know/see the password in
>> > >> clear
>> > >> text should be the respective mail user. Is there any way to achieve
>> > >> this?
>> > >>
>> > >> On 2022-09-15 08:16, Aki Tuomi wrote:
>> > >> >> On 14/09/2022 19:34 EEST Serveria Support <support at serveria.com>
>> > >> >> wrote:
>> > >> >>
>> > >> >>
>> > >> >> Thanks for your help. Do you know in which folder the keys are stored?
>> > >> >> I'd like to check the permissions...
>> > >> >>
>> > >> >
>> > >> >
>> > >> > Some notes here, after reading this thread again:
>> > >> >
>> > >> > - Keys are stored in mail_attributes file, which depends on your
>> > >> > config, but usually is %h/dovecot-attributes, which means it'll be in
>> > >> > user's home directory.
>> > >> >
>> > >> > - The key format is Dovecot Dcrypt Key, you can use `doveadm mailbox
>> > >> > cryptokey export` to export them in PEM format. Only **global keys**
>> > >> > expect PEM formatted keys, which you are not using.
>> > >> >
>> > >> > - If you are using mail_crypt_private_password to encrypt the user
>> > >> > key, you will need to provide this every time you want to access the
>> > >> > user's emails, including using doveadm. Dovecot does not know what
>> > >> > password you are using.
>> > >> >
>> > >> > - Your logs indicate that you are, still, using master userdb. This
>> > >> > will not work. You cannot use master users with per-user encryption
>> > >> > passwords in the way you do. If you want to use master users / master
>> > >> > password, you must not encrypt the user key.
>> > >> >
>> > >> > - You should really focus on reading your logs, because they really do
>> > >> > indicate that the userdb_mail_crypt_private_password is not exprted in
>> > >> > anywhere, so clearly and obviously you are not able to access the
>> > >> > mails.
>> > >> >
>> > >> > Maybe consider removing the master user authentication completely?
>> > >> >
>> > >> > Aki