Re: Static build problems
> On 09/10/2022 21:35 EEST Jacob Welsh wrote: > > > On Sun, 9 Oct 2022, Aki Tuomi wrote: > > >> I noticed commit d21897832a443d139d56b1fb1c86d8f76e5f77f3 from 2009, > >> "Fixed compiling without module support", and clearly it's supposed to > >> work since the #ifdefs are there, but I begin to suspect that nobody's > >> actually tested this branch of the configuration tree recently. > >> > >> Further, looking through the automakefiles I'm not finding how the plugin > >> libraries are supposed to work at all in this case and I begin to fear > >> that they simply... aren't. > > > We don't test all static builds, since we don't use or ship Dovecot in that > > manner. So, it is very likely it will not work. > > Alright, then is there any desire to fix it? > > Jacob If you or someone else in community comes up with a fix we can consider merging it at some point. Aki
Re: Static build problems
On Sun, 9 Oct 2022, Aki Tuomi wrote: I noticed commit d21897832a443d139d56b1fb1c86d8f76e5f77f3 from 2009, "Fixed compiling without module support", and clearly it's supposed to work since the #ifdefs are there, but I begin to suspect that nobody's actually tested this branch of the configuration tree recently. Further, looking through the automakefiles I'm not finding how the plugin libraries are supposed to work at all in this case and I begin to fear that they simply... aren't. We don't test all static builds, since we don't use or ship Dovecot in that manner. So, it is very likely it will not work. Alright, then is there any desire to fix it? Jacob
Re: Dovecot mail-crypt webmail can't read encrypted messages
Like I've already mentioned in my reply to Aki, I generally agree, but many of these methods require much time and expertise some bad guys don't have. You can also bruteforce the passwords but it can take years. With passwords showing in logs all they need to do is make a few clicks and enable auth logging. In most cases the attacker is really short on time and needs to act fast, before he is detected and locked out of the system. On 2022-10-09 19:10, Bernardo Reino wrote: On Sun, 9 Oct 2022, Serveria Support wrote: So this means passwords cannot be masked/hidden in the logs? You realize that it actually defeats the whole idea of encrypted storage? It's useless. 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... There is no such thing as semi-privacy. Privacy is either there or it's not. If your attack scenario includes somebody owning your server, nothing prevents them from compiling/installing a custom version of dovecot (or any other tool you may be using, like PAM, etc.) which dumps the passwords in clear text to a suitable file, pipe, or socket. So good luck with that requirement.. Cheers, Bernardo
Re: Dovecot mail-crypt webmail can't read encrypted messages
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 wrote:
> On 09/10/2022 12:53 EEST Serveria Support 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
> >> 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
> >> >> wrote:
> >> >>
> >> >>
> >> >> Thanks for your help. Do you know in which folder
Re: Dovecot mail-crypt webmail can't read encrypted messages
Serveria Support skrev den 2022-10-09 19:12: Turn on auth_debug=yes and see, you'll see passwords being masked. I have this value set to yes already and the passwords are not being masked. Perhaps you meant auth_debug_passwords = no? both need to be no imho but can be diffrent in diffrent dovecot versions check doveconf -P | grep auth
Re: Dovecot mail-crypt webmail can't read encrypted messages
Passwords are hidden in logs, mostly. Debug logging unfortunately can
leak some password information.
So why not just get rid of this attack vector? Who needs users'
plaintext passwords in debug logs anyway? I can't think of a situation
when this is necessary. But that's just me of course.
Turn on auth_debug=yes and see, you'll see passwords being masked.
I have this value set to yes already and the passwords are not being
masked. Perhaps you meant auth_debug_passwords = no?
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.
Will this work in doveadm commands? Or it has to be done in a PHP script
feeding login data to dovecot (like webmail/frontend)? Will it prevent
passwords from showing in the logs?
On 2022-10-09 14:02, Aki Tuomi wrote:
On 09/10/2022 12:53 EEST Serveria Support
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
>> 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
>> >> 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
rspamd results
Results for file: 2 (0.0633 seconds)
[Metric: default]
Action: add header
Spam: true
Score: 3.99 / 30.00
Symbol: ARC_REJECT (1.00)[signature check failed: fail, {[1] =
sig:dovecot.org:reject}]
Symbol: DKIM_TRACE (0.00)[junc.eu:-]
Symbol: DMARC_POLICY_SOFTFAIL (0.10)[junc.eu : No valid SPF, none]
Symbol: FROM_HAS_DN (0.00)
Symbol: FROM_NEQ_ENVFROM (0.00)[m...@junc.eu, dovecot-boun...@dovecot.org]
Symbol: HAS_LIST_UNSUB (-0.01)
Symbol: HAS_ORG_HEADER (0.00)
Symbol: HFILTER_HOSTNAME_UNKNOWN (2.50)
Symbol: MAILLIST (-0.20)[mailman]
Symbol: MID_RHS_MATCH_FROM (0.00)
Symbol: MIME_GOOD (-0.10)[text/plain]
Symbol: MIME_TRACE (0.00)[0:+]
Symbol: RCPT_COUNT_ONE (0.00)[1]
Symbol: RCVD_COUNT_SEVEN (0.00)[7]
Symbol: RCVD_IN_DNSWL_MED (-0.40)[172.104.150.56:received,
94.237.105.223:received]
Symbol: RCVD_NO_TLS_LAST (0.10)
Symbol: RCVD_VIA_SMTP_AUTH (0.00)
Symbol: R_DKIM_REJECT (1.00)[junc.eu:s=default]
Symbol: TO_DN_NONE (0.00)
Message-ID: 38f38a585892368901bd47944ca61...@junc.eu
just to be sure its not a fail in spamassassin with dkim_invalid
ARC-Authentication-Results: i=1; talvi.dovecot.org;
dkim=pass header.d=junc.eu header.s=default header.b=rodgOLEw;
spf=pass (talvi.dovecot.org: domain of m...@junc.eu designates
172.104.150.56 as
permitted sender) smtp.mailfrom=m...@junc.eu;
dmarc=pass (policy=none) header.from=junc.eu
where is the problem ?
i will report fuglu dkim signing non existing headers in a moment if
that my fault
cc: is non existing here but are still signed, why did ARC verify not
find this problem ?
Re: Dovecot mail-crypt webmail can't read encrypted messages
On Sun, 9 Oct 2022, Serveria Support wrote: So this means passwords cannot be masked/hidden in the logs? You realize that it actually defeats the whole idea of encrypted storage? It's useless. 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... There is no such thing as semi-privacy. Privacy is either there or it's not. If your attack scenario includes somebody owning your server, nothing prevents them from compiling/installing a custom version of dovecot (or any other tool you may be using, like PAM, etc.) which dumps the passwords in clear text to a suitable file, pipe, or socket. So good luck with that requirement.. Cheers, Bernardo
Re: Dovecot mail-crypt webmail can't read encrypted messages
Serveria Support skrev den 2022-10-09 11:53: Dovecot does it's best to hide passwords in logs, but unfortuntely this isn't perfect. doveconf -P | grep auth maybe the issue is decrypt ?
Re: Dovecot mail-crypt webmail can't read encrypted messages
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 wrote:
>
>
> > On 09/10/2022 12:53 EEST Serveria Support 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
> > >> 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
> > >> >> 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,
Re: Dovecot mail-crypt webmail can't read encrypted messages
> On 09/10/2022 12:53 EEST Serveria Support 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
> >> 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
> >> >> 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
Re: Dovecot mail-crypt webmail can't read encrypted messages
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? You realize that it actually defeats the whole idea of encrypted storage? It's useless. 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... 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? 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? 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 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 >> 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
Re: Dovecot mail-crypt webmail can't read encrypted messages
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 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 > >> 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
Re: Static build problems
> On 08/10/2022 01:51 EEST Jacob Welsh wrote: > > > I'm attempting to build the latest Dovecot, version 2.3.19.1, on Gales > Linux, a distribution based on musl libc with all static linking. > > After working around some expected troubles to generate configure, such as > the libtool and iconv.m4 dependencies, the build appeared to complete > successfully. But on closer inspection, the plugins were installed as a > bunch of .a and .la files rather than getting linked into any of the > binaries, as would be necessary to actually use them. > > I determined that the probe for dynamic module support (DOVECOT_MODULES > defined in 'm4/modules.m4') had returned a false positive: in the static > configuration musl includes a stub dlopen() that always returns failure at > runtime, so a compile-and-link-only test is not predictive. Libtool itself > is affected in the same way, but it comes with the --disable-shared option > which usually makes things works fine. > > Short of a proper solution (perhaps removing modules.m4 and going instead > by what libtool already determined, since you've decided to depend on it > anyway), I stubbed out modules.m4 to simply return the correct result for > this platform, thus: > > AC_DEFUN([DOVECOT_MODULES], [ >have_modules=no >AC_SUBST(MODULE_LIBS) >AC_SUBST(DLLIB) > ]) > > Now the build is failing due to the absence of a function that's defined > only when HAVE_MODULES is true: > > libtool: link: gcc -I../../src/lib -I../../src/lib-test > -I../../src/lib-ssl-iostream > -DDCRYPT_MODULE_DIR=\"/gales/pkg/dovecot-0.0-2.3.19.1/lib/dovecot\" > -DDCRYPT_SRC_DIR=\"../../src/lib-dcrypt\" -std=gnu99 -g -O1 -U_FORTIFY_SOURCE > -D_FORTIFY_SOURCE=2 -Wall -W -Wmissing-prototypes -Wmissing-declarations > -Wpointer-arith -Wchar-subscripts -Wformat=2 -Wbad-function-cast > -fno-builtin-strftime -Wstrict-aliasing=2 -Wl,--whole-archive > -Wl,../lib-ssl-iostream/.libs/libssl_iostream.a -Wl,--no-whole-archive -o > test-stream test_stream-dcrypt.o test_stream-istream-decrypt.o > test_stream-ostream-encrypt.o test_stream-test-stream.o > ../lib-ssl-iostream/.libs/libssl_iostream.a ../lib-test/.libs/libtest.a > ../lib/.libs/liblib.a > test_crypto-dcrypt.o: In function `dcrypt_initialize': > /home/user/gales-linux/gports/dovecot/build/dovecot-2.3.19.1/src/lib-dcrypt/dcrypt.c:34: > undefined reference to `module_dir_try_load_missing' > collect2: error: ld returned 1 exit status > make[3]: *** [Makefile:664: test-crypto] Error 1 > > I noticed commit d21897832a443d139d56b1fb1c86d8f76e5f77f3 from 2009, > "Fixed compiling without module support", and clearly it's supposed to > work since the #ifdefs are there, but I begin to suspect that nobody's > actually tested this branch of the configuration tree recently. > > Further, looking through the automakefiles I'm not finding how the plugin > libraries are supposed to work at all in this case and I begin to fear > that they simply... aren't. > > Say it ain't so? > > Jacob We don't test all static builds, since we don't use or ship Dovecot in that manner. So, it is very likely it will not work. Aki
Re: Dovecot mail-crypt webmail can't read encrypted messages
Hi, sorry I meant Sogo Groupware. The one from their website, not the one bundled with iREDMAIL. I'm only using it for webmail, that's why I called it webmail. Sorry for misleading you. On 2022-10-09 10:47, mabi wrote: I have rebuilt the entire project from scratch, using vanilla versions of Dovecot, Postfix, SOGO webmail etc and everything works as expected: Hi, just wondering where do you find the vanilla version of only SOGO webmail? I thought SOGO webmail was distributed as a whole server package...
Re: Dovecot mail-crypt webmail can't read encrypted messages
> I have rebuilt the entire project from scratch, using vanilla versions > of Dovecot, Postfix, SOGO webmail etc and everything works as expected: Hi, just wondering where do you find the vanilla version of only SOGO webmail? I thought SOGO webmail was distributed as a whole server package...
