Re: Dovecot mail-crypt webmail can't read encrypted messages
I wonder if I can just copy the compiled binaries over to the working server? Or should I build a new server from scratch and compile Dovecot again? If it's possible to copy over, which files will be required? Just 'dovecot'? Also, in my testing environment I used a Dovecot apt package for Debian. Is it compatible with the vanilla Dovecot built from source? Thanks in advance. On 2022-10-12 21:44, spi wrote: Am 12.10.22 um 15:21 schrieb Stuart Henderson: On 2022-10-11, Bernardo Reino wrote: Please please stop top-posting. Makes a mess of everything! I think everything that can be said in this thread, already has been said... But not by everybody... -- Cheers spi
Re: Dovecot mail-crypt webmail can't read encrypted messages
Thanks, worked like a charm! I wonder if I can just copy the compiled binaries over to the working server? Or should I build a new server from scratch and compile Dovecot again? If it's possible to copy over, which files will be required? Just 'dovecot'? Also, in my testing environment I used a Dovecot apt package for Debian. Is it compatible with the vanilla Dovecot built from source? Thanks in advance. On 2022-10-13 17:55, Odhiambo Washington wrote: On Thu, Oct 13, 2022 at 5:40 PM Serveria Support wrote: Hi, Unfortunately, after running autogen.sh and ./configure the file is still not there. I understand that this is not a Dovecot issue, but perhaps someone can help me with this? 1. mkdir ~reinob/Sources 2. cd ~reinob/Sources 3. wget https://dovecot.org/releases/2.3/dovecot-2.3.19.1.tar.gz 4. tar -xzvf dovecot-2.3.19.1.tar.gz 5. cd dovecot-2.3.19.1 # make the changes to the file you want to patch 6. ./configure --help # select your options 7. ./configure --opt1 --opt2 --opt3, etc 8. make install -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-)
Re: Dovecot mail-crypt webmail can't read encrypted messages
On Thu, Oct 13, 2022 at 5:40 PM Serveria Support wrote: > Hi, > > Unfortunately, after running autogen.sh and ./configure the file is > still not there. I understand that this is not a Dovecot issue, but > perhaps someone can help me with this? 1. mkdir ~reinob/Sources 2. cd ~reinob/Sources 3. wget https://dovecot.org/releases/2.3/dovecot-2.3.19.1.tar.gz 4. tar -xzvf dovecot-2.3.19.1.tar.gz 5. cd dovecot-2.3.19.1 # make the changes to the file you want to patch 6. ./configure --help # select your options 7. ./configure --opt1 --opt2 --opt3, etc 8. make install -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-)
Re: Dovecot mail-crypt webmail can't read encrypted messages
Hi, Unfortunately, after running autogen.sh and ./configure the file is still not there. I understand that this is not a Dovecot issue, but perhaps someone can help me with this? On 2022-10-12 08:54, Bernardo Reino wrote: On Tue, 11 Oct 2022, Serveria Support wrote: I'm sorry but I wasn't able to find src/config/all-settings.c file. all-settings.h is there but all-settings.c is missing. I checked on Github (thought maybe some files failed to extract) and it's missing there too. When building from git, you need to run ./autogen.sh first. ^^ This is from the instructions in git (INSTALL.md). This generates, among others, the file I mentioned. On 2022-10-11 22:15, Bernardo Reino wrote: Please please stop top-posting. Makes a mess of everything! On Tue, 11 Oct 2022, Serveria Support wrote: Ok, this is something... let me check... If you're you referring to these pieces of code: [...] I'm not a programmer, let alone a C guru, but these extracts look like password failure logging. Are you sure they are recording successful authentications for the logs? OK. I thought the code would be the same. I *do* log failed passwords, so I sort of thought only about that string ("given password: "). I enabled debug passwords on my server, to test, so I could see how it looks like in the log. The "keyword" in the code seems to be "hide_pass", so if you search for that in the code, you find a few instances where passwords are (selectively) removed/replaced in a given line of text. But at this point I think the easiest in this absurd (IMHO) quest of yours is to patch src/config/all-settings.c, and, around line 4141: static bool login_settings_check(void *_set, pool_t pool, const char **error_r ATTR_UNUSED) { struct login_settings *set = _set; set->log_format_elements_split = p_strsplit(pool, set->login_log_format_elements, " "); /* >>> INSERT HERE */ set->auth_debug_passwords = FALSE; /* */ if (set->auth_debug_passwords) set->auth_debug = TRUE; if (set->auth_debug) set->auth_verbose = TRUE; return TRUE; } If I'm right, this will just turn off the flag whenever dovecot checks the settings, i.e. regardless of what's in the actual dovecot.conf, so it should do the trick. But at this point this feels like a useless homework assignment, so I think I'll stop (I used to be good with C, now I'm read/only, and my time is very limited). (I do make a mental note of having a statically linked dovecot binary with forced password debugging. You never know when/where you might need it ;-) Cheers and good luck, Bernardo On 2022-10-11 17:07, Bernardo Reino wrote: On Mon, 10 Oct 2022, Serveria Support wrote: I checked the source code on Github and discussed this with a C developer. There seem to be too many files... perhaps somebody can guide me where should I look? Aki? You should search for "given password" in the source. Hint: src/auth/passdb-pam.c, around lines 175-178. src/auth/auth-request.c, around lines 2311-2312. This is with the latest source (2.3.19.1). Cheers. PS: But as I noted, nothing prevents $HACKER from bringing their own dovecot (BYOD :) with all debugging options enabled, etc. As others have noted, if the intruder owns your server, you have lost. Period.
Re: Dovecot mail-crypt webmail can't read encrypted messages
Am 12.10.22 um 15:21 schrieb Stuart Henderson: On 2022-10-11, Bernardo Reino wrote: Please please stop top-posting. Makes a mess of everything! I think everything that can be said in this thread, already has been said... But not by everybody... -- Cheers spi
Re: Dovecot mail-crypt webmail can't read encrypted messages
On 2022-10-11, Bernardo Reino wrote: > Please please stop top-posting. Makes a mess of everything! I think everything that can be said in this thread, already has been said...
Re: Dovecot mail-crypt webmail can't read encrypted messages
On Tue, 11 Oct 2022, Serveria Support wrote: I'm sorry but I wasn't able to find src/config/all-settings.c file. all-settings.h is there but all-settings.c is missing. I checked on Github (thought maybe some files failed to extract) and it's missing there too. When building from git, you need to run ./autogen.sh first. ^^ This is from the instructions in git (INSTALL.md). This generates, among others, the file I mentioned. On 2022-10-11 22:15, Bernardo Reino wrote: Please please stop top-posting. Makes a mess of everything! On Tue, 11 Oct 2022, Serveria Support wrote: Ok, this is something... let me check... If you're you referring to these pieces of code: [...] I'm not a programmer, let alone a C guru, but these extracts look like password failure logging. Are you sure they are recording successful authentications for the logs? OK. I thought the code would be the same. I *do* log failed passwords, so I sort of thought only about that string ("given password: "). I enabled debug passwords on my server, to test, so I could see how it looks like in the log. The "keyword" in the code seems to be "hide_pass", so if you search for that in the code, you find a few instances where passwords are (selectively) removed/replaced in a given line of text. But at this point I think the easiest in this absurd (IMHO) quest of yours is to patch src/config/all-settings.c, and, around line 4141: static bool login_settings_check(void *_set, pool_t pool, const char **error_r ATTR_UNUSED) { struct login_settings *set = _set; set->log_format_elements_split = p_strsplit(pool, set->login_log_format_elements, " "); /* >>> INSERT HERE */ set->auth_debug_passwords = FALSE; /* */ if (set->auth_debug_passwords) set->auth_debug = TRUE; if (set->auth_debug) set->auth_verbose = TRUE; return TRUE; } If I'm right, this will just turn off the flag whenever dovecot checks the settings, i.e. regardless of what's in the actual dovecot.conf, so it should do the trick. But at this point this feels like a useless homework assignment, so I think I'll stop (I used to be good with C, now I'm read/only, and my time is very limited). (I do make a mental note of having a statically linked dovecot binary with forced password debugging. You never know when/where you might need it ;-) Cheers and good luck, Bernardo On 2022-10-11 17:07, Bernardo Reino wrote: On Mon, 10 Oct 2022, Serveria Support wrote: I checked the source code on Github and discussed this with a C developer. There seem to be too many files... perhaps somebody can guide me where should I look? Aki? You should search for "given password" in the source. Hint: src/auth/passdb-pam.c, around lines 175-178. src/auth/auth-request.c, around lines 2311-2312. This is with the latest source (2.3.19.1). Cheers. PS: But as I noted, nothing prevents $HACKER from bringing their own dovecot (BYOD :) with all debugging options enabled, etc. As others have noted, if the intruder owns your server, you have lost. Period.
Re: Dovecot mail-crypt webmail can't read encrypted messages
> "Serveria" == Serveria Support writes: > Yes, there is a tiny problem letting the attacker change this value back > to yes and instantly get access to users' passwords in plain text. Apart > from that - no problems at all. :) Honestly, if the attacker has penetrated you to such an extent, then you're toast anyway, because they can just attach to the dovecot process with 'gdb' and dump the data directly as well. Encryption is not a magic solution here, and there's no real way to secure the system so well that once an attacker can modify files and restart processes they are blocked. Because they honestly looks like an Admin doing work on the system. > On 2022-10-11 12:15, Benny Pedersen wrote: >> Serveria Support skrev den 2022-10-11 10:37: >>> Thanks, but I suspect you've missed a part of this discussion >> >> if you set all to no, is there any problem to solve ? >> >> i am only human, not perfect >> >>> >>> On 2022-10-11 01:25, Benny Pedersen wrote: Serveria Support skrev den 2022-10-10 23:18: > Hi Benny, > > Sorry I must have missed your email. Here's the output of doveconf > -P > | grep auth: > > doveconf: Warning: NOTE: You can get a new clean config file with: > doveconf -Pn > dovecot-new.conf > doveconf: Warning: Obsolete setting in /etc/dovecot/dovecot.conf:25: > 'imaps' protocol is no longer necessary, remove it remove imaps in protocol as it says > auth_debug = yes > auth_debug_passwords = yes > auth_verbose = yes > auth_verbose_passwords = yes change yes to no problem solved imho :)
Re: Dovecot mail-crypt webmail can't read encrypted messages
I'm sorry but I wasn't able to find src/config/all-settings.c file. all-settings.h is there but all-settings.c is missing. I checked on Github (thought maybe some files failed to extract) and it's missing there too. On 2022-10-11 22:15, Bernardo Reino wrote: Please please stop top-posting. Makes a mess of everything! On Tue, 11 Oct 2022, Serveria Support wrote: Ok, this is something... let me check... If you're you referring to these pieces of code: [...] I'm not a programmer, let alone a C guru, but these extracts look like password failure logging. Are you sure they are recording successful authentications for the logs? OK. I thought the code would be the same. I *do* log failed passwords, so I sort of thought only about that string ("given password: "). I enabled debug passwords on my server, to test, so I could see how it looks like in the log. The "keyword" in the code seems to be "hide_pass", so if you search for that in the code, you find a few instances where passwords are (selectively) removed/replaced in a given line of text. But at this point I think the easiest in this absurd (IMHO) quest of yours is to patch src/config/all-settings.c, and, around line 4141: static bool login_settings_check(void *_set, pool_t pool, const char **error_r ATTR_UNUSED) { struct login_settings *set = _set; set->log_format_elements_split = p_strsplit(pool, set->login_log_format_elements, " "); /* >>> INSERT HERE */ set->auth_debug_passwords = FALSE; /* */ if (set->auth_debug_passwords) set->auth_debug = TRUE; if (set->auth_debug) set->auth_verbose = TRUE; return TRUE; } If I'm right, this will just turn off the flag whenever dovecot checks the settings, i.e. regardless of what's in the actual dovecot.conf, so it should do the trick. But at this point this feels like a useless homework assignment, so I think I'll stop (I used to be good with C, now I'm read/only, and my time is very limited). (I do make a mental note of having a statically linked dovecot binary with forced password debugging. You never know when/where you might need it ;-) Cheers and good luck, Bernardo On 2022-10-11 17:07, Bernardo Reino wrote: On Mon, 10 Oct 2022, Serveria Support wrote: I checked the source code on Github and discussed this with a C developer. There seem to be too many files... perhaps somebody can guide me where should I look? Aki? You should search for "given password" in the source. Hint: src/auth/passdb-pam.c, around lines 175-178. src/auth/auth-request.c, around lines 2311-2312. This is with the latest source (2.3.19.1). Cheers. PS: But as I noted, nothing prevents $HACKER from bringing their own dovecot (BYOD :) with all debugging options enabled, etc. As others have noted, if the intruder owns your server, you have lost. Period.
Re: Dovecot mail-crypt webmail can't read encrypted messages
Please please stop top-posting. Makes a mess of everything! On Tue, 11 Oct 2022, Serveria Support wrote: Ok, this is something... let me check... If you're you referring to these pieces of code: [...] I'm not a programmer, let alone a C guru, but these extracts look like password failure logging. Are you sure they are recording successful authentications for the logs? OK. I thought the code would be the same. I *do* log failed passwords, so I sort of thought only about that string ("given password: "). I enabled debug passwords on my server, to test, so I could see how it looks like in the log. The "keyword" in the code seems to be "hide_pass", so if you search for that in the code, you find a few instances where passwords are (selectively) removed/replaced in a given line of text. But at this point I think the easiest in this absurd (IMHO) quest of yours is to patch src/config/all-settings.c, and, around line 4141: static bool login_settings_check(void *_set, pool_t pool, const char **error_r ATTR_UNUSED) { struct login_settings *set = _set; set->log_format_elements_split = p_strsplit(pool, set->login_log_format_elements, " "); /* >>> INSERT HERE */ set->auth_debug_passwords = FALSE; /* */ if (set->auth_debug_passwords) set->auth_debug = TRUE; if (set->auth_debug) set->auth_verbose = TRUE; return TRUE; } If I'm right, this will just turn off the flag whenever dovecot checks the settings, i.e. regardless of what's in the actual dovecot.conf, so it should do the trick. But at this point this feels like a useless homework assignment, so I think I'll stop (I used to be good with C, now I'm read/only, and my time is very limited). (I do make a mental note of having a statically linked dovecot binary with forced password debugging. You never know when/where you might need it ;-) Cheers and good luck, Bernardo On 2022-10-11 17:07, Bernardo Reino wrote: On Mon, 10 Oct 2022, Serveria Support wrote: I checked the source code on Github and discussed this with a C developer. There seem to be too many files... perhaps somebody can guide me where should I look? Aki? You should search for "given password" in the source. Hint: src/auth/passdb-pam.c, around lines 175-178. src/auth/auth-request.c, around lines 2311-2312. This is with the latest source (2.3.19.1). Cheers. PS: But as I noted, nothing prevents $HACKER from bringing their own dovecot (BYOD :) with all debugging options enabled, etc. As others have noted, if the intruder owns your server, you have lost. Period.
Re: Dovecot mail-crypt webmail can't read encrypted messages
Ok, this is something... let me check... If you're you referring to these pieces of code: if (path != NULL) { /* log this as error, since it probably is */ str = t_strdup_printf("%s (%s missing?)", str, path); e_error(authdb_event(request), "%s", str); } else if (status == PAM_AUTH_ERR) { str = t_strconcat(str, " ("AUTH_LOG_MSG_PASSWORD_MISMATCH"?)", NULL); if (request->set->debug_passwords) { str = t_strconcat(str, " (given password: ", request->mech_password, ")", NULL); } and: void auth_request_log_login_failure(struct auth_request *request, const char *subsystem, const char *message) I'm not a programmer, let alone a C guru, but these extracts look like password failure logging. Are you sure they are recording successful authentications for the logs? On 2022-10-11 17:07, Bernardo Reino wrote: On Mon, 10 Oct 2022, Serveria Support wrote: I checked the source code on Github and discussed this with a C developer. There seem to be too many files... perhaps somebody can guide me where should I look? Aki? You should search for "given password" in the source. Hint: src/auth/passdb-pam.c, around lines 175-178. src/auth/auth-request.c, around lines 2311-2312. This is with the latest source (2.3.19.1). Cheers. PS: But as I noted, nothing prevents $HACKER from bringing their own dovecot (BYOD :) with all debugging options enabled, etc. As others have noted, if the intruder owns your server, you have lost. Period.
Re: Dovecot mail-crypt webmail can't read encrypted messages
On 11.10.22 18:04, John Tulp wrote: in mitigating such risk, why not go for the "low hanging fruit" by simply not storing passwords on disk in clear text ? unless there is some reason why clear text passwords actually have to be written to disk. Authentication schemes like CRAM-MD5 require the server to have the plaintext password *available* for / prior to the authentication (it is therefor usually called a "shared secret" instead). Before you ask, one benefit from using such schemes is that the password does not have to go through the wire, not even inside encryption (that a MitM may or may not be able to crack), so it's not a clear all-out FAIL to use those. Whether the password is still in cleartext *when written to / read from disk* is another question, but that would be a negligible defense against someone who rooted your server. Kind regards, -- Jochen Bern Systemingenieur Binect GmbH
Re: Dovecot mail-crypt webmail can't read encrypted messages
If someone has root they can just read the email storage files, no password needed. We are discussing Dovecot with encrypted mail storage here. If someone has root, and dovecot has no code showing passwords in logs, the attacker can build THEIR OWN version of dovecot that "key-logs" all passwords to a remote server WITHOUT displaying passwords in the logs. Please compare the time needed to: get in, enable debug logging, read the log file with: get in, enable debug logging, realize it's not working (some will stop here), consider your options, build THEIR OWN version of dovecot that "key-logs" all passwords to a remote server WITHOUT displaying passwords in the logs? This is what people mean when they say if someone has root you have bigger problems then dovecot logging. I generally agree but only if the mail storage is unencrypted. With encrypted storage I can think of many scenarios: corrupt law enforcement, malicious freelance admin, social engineering tricks etc etc etc when attackers will have not enough time/expertise to grab your passwords. On 2022-10-11 18:16, dove...@ptld.com wrote: Yeah, it's such an obvious vulnerability, I'm kinda surprised most people here don't see an issue with that. What people are trying to explain is the scenario you describe requires an attacker to have root privileges on the target server. If someone has root access to a server then your fears are moot and the suggestion to remove code logging passwords offers zero protection. If someone has root they can just read the email storage files, no password needed. If someone has root, and dovecot has no code showing passwords in logs, the attacker can build THEIR OWN version of dovecot that "key-logs" all passwords to a remote server WITHOUT displaying passwords in the logs. This is what people mean when they say if someone has root you have bigger problems then dovecot logging.
Re: Dovecot mail-crypt webmail can't read encrypted messages
What i'm saying is... if the attackers goal is only to get passwords, you will not be dealing with a bigger problem. In that hypothetical there would not be a bigger problem or any other problem. the only problem is passwords leaking in that case. The attacker goes out of their way to not cause any other problems on the server. they do this to avoid getting noticed by admins. as long as admin does not know there is malware on their server, the malware could run for years harvesting passwords. That would be the hypothetical attackers only goal on that server - not to bother anything, just to harvest user email passwords. and the admin will not be dealing with a "bigger problem", because the admin will not know they've been hacked, because hacker does not cause any problems on the server. admin will think everything is fine on their server. there could be email servers right now that are compromised and yielding passwords in this way, and if dovecot suddenly started writing those passwords the logs in some scrambled way - the malware would suddenly stop being able to harvest clear text passwords. hacker then could either quietly go away, or start doing something else on the machine, which the admins may or may not become aware of. might get a big surprise that they've been hacked. This type of "quiet" malware of course definitely exists in the real world, for example, on phones. Many people's phones have been hacked and they are unaware of it, and they continue using the phone for years without realizing it's been hacked. Sometimes attackers mess up the devices they hack, sometimes they don't, they just quietly use the hacked device for their own purposes (which of course are the hacks to really worry about). whenever there are big announcements of hacks to major organizations, the story always unfolds that the hackers had access for quite a while before admins became aware. this is the timeframe that really puts one's "security efforts" to the test - after machine is compromised, but before admins are aware. it makes no sense to make things easy for hackers during this time when they are operating in the target machines/network and the admins are not yet aware that devices have been compromised. in mitigating such risk, why not go for the "low hanging fruit" by simply not storing passwords on disk in clear text ? unless there is some reason why clear text passwords actually have to be written to disk. -- John Tulp tulpex On Tue, 2022-10-11 at 17:58 +0300, Odhiambo Washington wrote: > @Tulp - the attacker has to 0wn your server first. In which case they > will have found a password to SSH in - regardless of dovecot being > there or not. > > You will be dealing with a bigger problem than dovecot. > > > > On Tue, Oct 11, 2022 at 5:39 PM John Tulp > wrote: > > I find this conversation "interesting". > > Serveria, i think some can't see the attack scenario where the > attacker's goal is simply to get email passwords, and nothing > else. it > would make sense for their strategy to do nothing else "bad" > on the > server to attract attention to their intrusion. In that case, > all they > would do is send back the treasure trove of passwords to their > home > server(s), and sit there, remaining possibly for years, > hiding, > exploiting the fact that dovecot, with no code modification, > will allow > them to grab email passwords. If a dovecot server has > thousands of > email accounts, that represents thousands of other devices > they could > target, which is worth much more to the attacker than a single > dovecot > server. > > Oh well, food for thought. > > > On Tue, 2022-10-11 at 15:11 +0300, Serveria Support wrote: > > Yes, I realize that. But I can't think of a reason this > password is > > necessary in the logs. It's kind of a backdoor and has to be > removed > > from code. Why make intruder's life easier? > > > > On 2022-10-11 13:39, Arjen de Korte wrote: > > > Citeren Serveria Support : > > > > > >> Yes, there is a tiny problem letting the attacker change > this value > > >> back to yes and instantly get access to users' passwords > in plain > > >> text. Apart from that - no problems at all. :) > > > > > > If an attacker is able to modify your Dovecot > configuration, you have > > > bigger problems than leaking your users' password. Much > bigger... > > > > > -- > Best regards, > Odhiambo WASHINGTON, > Nairobi,KE > +254 7 3200 0004/+254 7 2274 3223 > "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-)
Re: Dovecot mail-crypt webmail can't read encrypted messages
Yeah, it's such an obvious vulnerability, I'm kinda surprised most people here don't see an issue with that. What people are trying to explain is the scenario you describe requires an attacker to have root privileges on the target server. If someone has root access to a server then your fears are moot and the suggestion to remove code logging passwords offers zero protection. If someone has root they can just read the email storage files, no password needed. If someone has root, and dovecot has no code showing passwords in logs, the attacker can build THEIR OWN version of dovecot that "key-logs" all passwords to a remote server WITHOUT displaying passwords in the logs. This is what people mean when they say if someone has root you have bigger problems then dovecot logging.
Re: Dovecot mail-crypt webmail can't read encrypted messages
@Tulp - the attacker has to 0wn your server first. In which case they will have found a password to SSH in - regardless of dovecot being there or not. You will be dealing with a bigger problem than dovecot. On Tue, Oct 11, 2022 at 5:39 PM John Tulp wrote: > I find this conversation "interesting". > > Serveria, i think some can't see the attack scenario where the > attacker's goal is simply to get email passwords, and nothing else. it > would make sense for their strategy to do nothing else "bad" on the > server to attract attention to their intrusion. In that case, all they > would do is send back the treasure trove of passwords to their home > server(s), and sit there, remaining possibly for years, hiding, > exploiting the fact that dovecot, with no code modification, will allow > them to grab email passwords. If a dovecot server has thousands of > email accounts, that represents thousands of other devices they could > target, which is worth much more to the attacker than a single dovecot > server. > > Oh well, food for thought. > > > On Tue, 2022-10-11 at 15:11 +0300, Serveria Support wrote: > > Yes, I realize that. But I can't think of a reason this password is > > necessary in the logs. It's kind of a backdoor and has to be removed > > from code. Why make intruder's life easier? > > > > On 2022-10-11 13:39, Arjen de Korte wrote: > > > Citeren Serveria Support : > > > > > >> Yes, there is a tiny problem letting the attacker change this value > > >> back to yes and instantly get access to users' passwords in plain > > >> text. Apart from that - no problems at all. :) > > > > > > If an attacker is able to modify your Dovecot configuration, you have > > > bigger problems than leaking your users' password. Much bigger... > > -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-)
Re: Dovecot mail-crypt webmail can't read encrypted messages
Bingo! Great to see some like-minded person here John! Yeah, it's such an obvious vulnerability, I'm kinda surprised most people here don't see an issue with that. If I were a Dovecot Pro OX customer, I'd be very concerned with this "feature". Imagine hacking Protonmail's server, getting root access and seeing customers' password there in clear text? ))) On 2022-10-11 17:38, John Tulp wrote: I find this conversation "interesting". Serveria, i think some can't see the attack scenario where the attacker's goal is simply to get email passwords, and nothing else. it would make sense for their strategy to do nothing else "bad" on the server to attract attention to their intrusion. In that case, all they would do is send back the treasure trove of passwords to their home server(s), and sit there, remaining possibly for years, hiding, exploiting the fact that dovecot, with no code modification, will allow them to grab email passwords. If a dovecot server has thousands of email accounts, that represents thousands of other devices they could target, which is worth much more to the attacker than a single dovecot server. Oh well, food for thought. On Tue, 2022-10-11 at 15:11 +0300, Serveria Support wrote: Yes, I realize that. But I can't think of a reason this password is necessary in the logs. It's kind of a backdoor and has to be removed from code. Why make intruder's life easier? On 2022-10-11 13:39, Arjen de Korte wrote: > Citeren Serveria Support : > >> Yes, there is a tiny problem letting the attacker change this value >> back to yes and instantly get access to users' passwords in plain >> text. Apart from that - no problems at all. :) > > If an attacker is able to modify your Dovecot configuration, you have > bigger problems than leaking your users' password. Much bigger...
Re: Dovecot mail-crypt webmail can't read encrypted messages
I find this conversation "interesting". Serveria, i think some can't see the attack scenario where the attacker's goal is simply to get email passwords, and nothing else. it would make sense for their strategy to do nothing else "bad" on the server to attract attention to their intrusion. In that case, all they would do is send back the treasure trove of passwords to their home server(s), and sit there, remaining possibly for years, hiding, exploiting the fact that dovecot, with no code modification, will allow them to grab email passwords. If a dovecot server has thousands of email accounts, that represents thousands of other devices they could target, which is worth much more to the attacker than a single dovecot server. Oh well, food for thought. On Tue, 2022-10-11 at 15:11 +0300, Serveria Support wrote: > Yes, I realize that. But I can't think of a reason this password is > necessary in the logs. It's kind of a backdoor and has to be removed > from code. Why make intruder's life easier? > > On 2022-10-11 13:39, Arjen de Korte wrote: > > Citeren Serveria Support : > > > >> Yes, there is a tiny problem letting the attacker change this value > >> back to yes and instantly get access to users' passwords in plain > >> text. Apart from that - no problems at all. :) > > > > If an attacker is able to modify your Dovecot configuration, you have > > bigger problems than leaking your users' password. Much bigger...
Re: Dovecot mail-crypt webmail can't read encrypted messages
Odhiambo Washington skrev den 2022-10-11 15:49: If you don't store cleartext passwords in your backend, how will an intruder get them?? auth_debug = yes auth_debug_passwords = yes auth_verbose = yes auth_verbose_passwords = yes then read log files if thats with world access all the above should be no first step to secure it next step is to secure syslogs
Re: Dovecot mail-crypt webmail can't read encrypted messages
On Mon, 10 Oct 2022, Serveria Support wrote: I checked the source code on Github and discussed this with a C developer. There seem to be too many files... perhaps somebody can guide me where should I look? Aki? You should search for "given password" in the source. Hint: src/auth/passdb-pam.c, around lines 175-178. src/auth/auth-request.c, around lines 2311-2312. This is with the latest source (2.3.19.1). Cheers. PS: But as I noted, nothing prevents $HACKER from bringing their own dovecot (BYOD :) with all debugging options enabled, etc. As others have noted, if the intruder owns your server, you have lost. Period.
Re: Dovecot mail-crypt webmail can't read encrypted messages
If you don't store cleartext passwords in your backend, how will an intruder get them?? On Tue, Oct 11, 2022 at 3:45 PM Serveria Support wrote: > Yes, I realize that. But I can't think of a reason this password is > necessary in the logs. It's kind of a backdoor and has to be removed > from code. Why make intruder's life easier? > > On 2022-10-11 13:39, Arjen de Korte wrote: > > Citeren Serveria Support : > > > >> Yes, there is a tiny problem letting the attacker change this value > >> back to yes and instantly get access to users' passwords in plain > >> text. Apart from that - no problems at all. :) > > > > If an attacker is able to modify your Dovecot configuration, you have > > bigger problems than leaking your users' password. Much bigger... > -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-)
Re: Dovecot mail-crypt webmail can't read encrypted messages
Yes, I realize that. But I can't think of a reason this password is necessary in the logs. It's kind of a backdoor and has to be removed from code. Why make intruder's life easier? On 2022-10-11 13:39, Arjen de Korte wrote: Citeren Serveria Support : Yes, there is a tiny problem letting the attacker change this value back to yes and instantly get access to users' passwords in plain text. Apart from that - no problems at all. :) If an attacker is able to modify your Dovecot configuration, you have bigger problems than leaking your users' password. Much bigger...
Re: Dovecot mail-crypt webmail can't read encrypted messages
Citeren Serveria Support : Yes, there is a tiny problem letting the attacker change this value back to yes and instantly get access to users' passwords in plain text. Apart from that - no problems at all. :) If an attacker is able to modify your Dovecot configuration, you have bigger problems than leaking your users' password. Much bigger...
Re: Dovecot mail-crypt webmail can't read encrypted messages
Serveria Support skrev den 2022-10-11 10:44: Yes, there is a tiny problem letting the attacker change this value back to yes and instantly get access to users' passwords in plain text. Apart from that - no problems at all. :) where is this problem ?, are the attacher one with full root access or not ? if thats the case i will just suggest make your own problem
Re: Dovecot mail-crypt webmail can't read encrypted messages
Yes, there is a tiny problem letting the attacker change this value back to yes and instantly get access to users' passwords in plain text. Apart from that - no problems at all. :) On 2022-10-11 12:15, Benny Pedersen wrote: Serveria Support skrev den 2022-10-11 10:37: Thanks, but I suspect you've missed a part of this discussion if you set all to no, is there any problem to solve ? i am only human, not perfect On 2022-10-11 01:25, Benny Pedersen wrote: Serveria Support skrev den 2022-10-10 23:18: Hi Benny, Sorry I must have missed your email. Here's the output of doveconf -P | grep auth: doveconf: Warning: NOTE: You can get a new clean config file with: doveconf -Pn > dovecot-new.conf doveconf: Warning: Obsolete setting in /etc/dovecot/dovecot.conf:25: 'imaps' protocol is no longer necessary, remove it remove imaps in protocol as it says auth_debug = yes auth_debug_passwords = yes auth_verbose = yes auth_verbose_passwords = yes change yes to no problem solved imho :)
Re: Dovecot mail-crypt webmail can't read encrypted messages
Serveria Support skrev den 2022-10-11 10:37: Thanks, but I suspect you've missed a part of this discussion if you set all to no, is there any problem to solve ? i am only human, not perfect On 2022-10-11 01:25, Benny Pedersen wrote: Serveria Support skrev den 2022-10-10 23:18: Hi Benny, Sorry I must have missed your email. Here's the output of doveconf -P | grep auth: doveconf: Warning: NOTE: You can get a new clean config file with: doveconf -Pn > dovecot-new.conf doveconf: Warning: Obsolete setting in /etc/dovecot/dovecot.conf:25: 'imaps' protocol is no longer necessary, remove it remove imaps in protocol as it says auth_debug = yes auth_debug_passwords = yes auth_verbose = yes auth_verbose_passwords = yes change yes to no problem solved imho :)
Re: Dovecot mail-crypt webmail can't read encrypted messages
Thanks, but I suspect you've missed a part of this discussion On 2022-10-11 01:25, Benny Pedersen wrote: Serveria Support skrev den 2022-10-10 23:18: Hi Benny, Sorry I must have missed your email. Here's the output of doveconf -P | grep auth: doveconf: Warning: NOTE: You can get a new clean config file with: doveconf -Pn > dovecot-new.conf doveconf: Warning: Obsolete setting in /etc/dovecot/dovecot.conf:25: 'imaps' protocol is no longer necessary, remove it remove imaps in protocol as it says auth_debug = yes auth_debug_passwords = yes auth_verbose = yes auth_verbose_passwords = yes change yes to no problem solved imho :)
Re: Dovecot mail-crypt webmail can't read encrypted messages
Serveria Support skrev den 2022-10-10 23:18: Hi Benny, Sorry I must have missed your email. Here's the output of doveconf -P | grep auth: doveconf: Warning: NOTE: You can get a new clean config file with: doveconf -Pn > dovecot-new.conf doveconf: Warning: Obsolete setting in /etc/dovecot/dovecot.conf:25: 'imaps' protocol is no longer necessary, remove it remove imaps in protocol as it says auth_debug = yes auth_debug_passwords = yes auth_verbose = yes auth_verbose_passwords = yes change yes to no problem solved imho :)
Re: Dovecot mail-crypt webmail can't read encrypted messages
Hi Benny, Sorry I must have missed your email. Here's the output of doveconf -P | grep auth: doveconf: Warning: NOTE: You can get a new clean config file with: doveconf -Pn > dovecot-new.conf doveconf: Warning: Obsolete setting in /etc/dovecot/dovecot.conf:25: 'imaps' protocol is no longer necessary, remove it auth_anonymous_username = anonymous auth_cache_negative_ttl = 1 hours auth_cache_size = 0 auth_cache_ttl = 1 hours auth_cache_verify_password_with_worker = no auth_debug = yes auth_debug_passwords = yes auth_default_realm = auth_failure_delay = 2 secs auth_gssapi_hostname = auth_krb5_keytab = auth_master_user_separator = auth_mechanisms = plain login auth_policy_check_after_auth = yes auth_policy_check_before_auth = yes auth_policy_hash_mech = sha256 auth_policy_hash_nonce = auth_policy_hash_truncate = 12 auth_policy_log_only = no auth_policy_reject_on_fail = no auth_policy_report_after_auth = yes auth_policy_request_attributes = login=%{requested_username} pwhash=%{hashed_password} remote=%{rip} device_id=%{client_id} protocol=%s session_id=%{session} auth_policy_server_api_header = auth_policy_server_timeout_msecs = 2000 auth_policy_server_url = auth_proxy_self = auth_realms = auth_socket_path = auth-userdb auth_ssl_require_client_cert = no auth_ssl_username_from_cert = no auth_stats = no auth_use_winbind = no auth_username_chars = abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ01234567890.-_@ auth_username_format = %Lu auth_username_translation = auth_verbose = yes auth_verbose_passwords = yes auth_winbind_helper_path = /usr/bin/ntlm_auth auth_worker_max_count = 30 disable_plaintext_auth = yes imap_urlauth_host = imap_urlauth_logout_format = in=%i out=%o imap_urlauth_port = 143 auth_verbose = default auth_verbose = default unix_listener anvil-auth-penalty { service auth-worker { executable = auth -w unix_listener auth-worker { service auth { executable = auth unix_listener /var/spool/postfix/private/auth { unix_listener auth-client { unix_listener auth-login { unix_listener auth-master { unix_listener auth-userdb { service imap-urlauth-login { executable = imap-urlauth-login unix_listener imap-urlauth { service imap-urlauth-worker { executable = imap-urlauth-worker unix_listener imap-urlauth-worker { service imap-urlauth { executable = imap-urlauth unix_listener token-login/imap-urlauth { auth_verbose = default auth_verbose = default I'm not sure how it will help me edit source files though... On 2022-10-10 22:33, Benny Pedersen wrote: Serveria Support skrev den 2022-10-10 20:05: I checked the source code on Github and discussed this with a C developer. There seem to be too many files... perhaps somebody can guide me where should I look? Aki? you ask for help ?, and i have sayed "doveconf -P | grep auth" how can i help more when you are not provide it ?, sorry then
Re: Dovecot mail-crypt webmail can't read encrypted messages
Serveria Support skrev den 2022-10-10 20:05: I checked the source code on Github and discussed this with a C developer. There seem to be too many files... perhaps somebody can guide me where should I look? Aki? you ask for help ?, and i have sayed "doveconf -P | grep auth" how can i help more when you are not provide it ?, sorry then
Re: Dovecot mail-crypt webmail can't read encrypted messages
I checked the source code on Github and discussed this with a C developer. There seem to be too many files... perhaps somebody can guide me where should I look? Aki? On 2022-10-10 11:03, Serveria Support wrote: Hi, thanks, this sounds like a great idea! Will try this and let you guys know... On 2022-10-10 10:52, George Asenov wrote: Dovecot is opensource so you can download source edit the log format removing the passwords and compile it. On 09-Oct-22 8:47 PM, Serveria Support wrote: 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
On 2022-10-10 08:03, Serveria Support wrote: Hi, thanks, this sounds like a great idea! Will try this and let you guys know... On 2022-10-10 10:52, George Asenov wrote: Dovecot is opensource so you can download source edit the log format removing the passwords and compile it. On 09-Oct-22 8:47 PM, Serveria Support wrote: 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 Hey, I thought to recommend encrypting log file by your own. Create service with executing bash script every second perhaps using while loop to encrypt dovecot logs file, add separater at end of log, so in following encryption cycles you can know whats being inserted new and needs encryption by decrypting the old and encrypting the decrypted old and new together. Also, make sure to perform encryption in separate copy of logs temp file so to allow dovecot to pipe out logs without messing up the order of lines, and lastly, you probably want to disallow administrator account from accessing dovecot conf file perhaps by changing its permission and ownership, so they cant change logging path. There you go, passwords are encrypted in log file and no one can read. Zakaria.
Re: Dovecot mail-crypt webmail can't read encrypted messages
Hi, thanks, this sounds like a great idea! Will try this and let you guys know... On 2022-10-10 10:52, George Asenov wrote: Dovecot is opensource so you can download source edit the log format removing the passwords and compile it. On 09-Oct-22 8:47 PM, Serveria Support wrote: 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
Dovecot is opensource so you can download source edit the log format removing the passwords and compile it. On 09-Oct-22 8:47 PM, Serveria Support wrote: 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 -- Warm regards George A. WPXHosting
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 n
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, a
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 maste
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: 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...
Re: Dovecot mail-crypt webmail can't read encrypted messages
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
Ok, big progress here! Specifying user password explicitly did the trick! The command that works is this: doveadm -o plugin/mail_crypt_private_password=xx -Dv fetch -u u...@mydomain.xyz text 1 Now I have to adjust/write a query which does the same in order to read/decrypt emails via webmail. I'm going to investigate the master user issue you mentioned. 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
> 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
Thanks for your help. Do you know in which folder the keys are stored? I'd like to check the permissions... On 2022-09-14 18:56, hi@zakaria.website wrote: On 2022-09-14 16:04, Serveria Support wrote: Oh, I thought that section is for the global keys. I'm trying to use per-user/per-folder keys. I used this command: doveadm -o plugin/mail_crypt_private_password=xx mailbox cryptokey generate -u u...@mydomain.xyz -URf On 2022-09-14 17:47, hi@zakaria.website wrote: On 2022-09-14 15:11, Serveria Support wrote: How can I set the global private key in conf? I was following the official mail-crypt tutorial. This is what I have in dovecot.conf mail-crypt section: mail_crypt_curve = secp521r1 mail_crypt_save_version = 2 mail_crypt_require_encrypted_user_key = yes On 2022-09-14 17:23, hi@zakaria.website wrote: On 2022-09-14 14:41, Serveria Support wrote: Hi, This log shows no errors. Running doveadm fetch command gives me this: doveadm(u...@mydomain.xyz): Error: fetch(text) failed for box=INBOX uid=15: read() failed: read(/var/vmail/vmail1/mydomain.xyz/a/b/d/-2022.09.09.05.52.29//Maildir/cur/1663034263.M491074P1457418.mx,S=2217,W=2266:2,S) failed: Private key not available: Cannot decrypt key fd98762c573b8c54805884838695bd5b7eaeb9e0b0d326434c2f63a95a905a89: Cannot decrypt key 10fed5d3e938ce19a20046b84f29e50a271f6404f0760037996b4cf2d1ecfeb7: Password not available On 2022-09-13 14:43, hi@zakaria.website wrote: On 2022-09-02 20:40, Serveria Support wrote: I tried it but it doesn't seem to make any difference at all. Can someone please assist me with reading logs? Does this log below mean Dovecot is trying to use master_user again or simply reading master_user password file? Sep 2 15:35:33 mx dovecot: auth: Debug: Read auth token secret from /run/dovecot/auth-token-secret.dat Sep 2 15:35:33 mx dovecot: auth: Debug: passwd-file /etc/dovecot/dovecot-master-users: Read 1 users in 0 secs Sep 2 15:35:33 mx dovecot: auth: Debug: auth client connected (pid=900284) Sep 2 15:35:33 mx dovecot: auth: Debug: client in: AUTH#0111#011PLAIN#011service=imap#011secured=tls#011session=Vfxm1bbnRo9/AAAB#011lip=127.0.0.1#011rip=127.0.0.1#011lport=143#011rport=36678#011local_name=127.0.0.1#011resp=AHRlc3RvQG1haWxjaXRhZGVsLnh5egA0SFBYMWt0OSE= (previous base64 data may contain sensitive data) Everything ok here? Sep 2 15:25:34 mx dovecot: auth: Debug: auth client connected (pid=899859) Sep 2 15:25:34 mx dovecot: auth: Debug: client in: AUTH#0111#011PLAIN#011service=imap#011secured=tls#011session=97OusbbnXI1/AAAB#011lip=127.0.0.1#011rip=127.0.0.1#011lport=143#011rport=36188#011local_name=127.0.0.1#011resp=AHRlc3RvQG1haWxjaXRhZGVsLnh5egA0SFBYMWt0OSE= (previous base64 data may contain sensitive data) Sep 2 15:25:34 mx dovecot: auth: Debug: sql(us...@mydomain.xyz,127.0.0.1,<97OusbbnXI1/AAAB>): Performing passdb lookup Sep 2 15:25:34 mx dovecot: auth-worker(899854): Debug: conn unix:auth-worker (pid=899853,uid=110): auth-worker<3>: Handling PASSV request Sep 2 15:25:34 mx dovecot: auth-worker(899854): Debug: conn unix:auth-worker (pid=899853,uid=110): auth-worker<3>: sql(us...@mydomain.xyz,127.0.0.1,<97OusbbnXI1/AAAB>): Performing passdb lookup Sep 2 15:25:34 mx dovecot: auth-worker(899854): Debug: conn unix:auth-worker (pid=899853,uid=110): auth-worker<3>: sql(us...@mydomain.xyz,127.0.0.1,<97OusbbnXI1/AAAB>): query: SELECT mailbox.password, mailbox.allow_nets FROM mailbox,domain WHERE mailbox.username='us...@mydomain.xyz' AND mailbox.`enableimaptls`=1 AND mailbox.active=1 AND mailbox.domain=domain.domain AND domain.backupmx=0 AND domain.active=1 Sep 2 15:25:34 mx dovecot: auth-worker(899854): Debug: conn unix:auth-worker (pid=899853,uid=110): auth-worker<3>: sql(us...@mydomain.xyz,127.0.0.1,<97OusbbnXI1/AAAB>): Finished passdb lookup Sep 2 15:25:34 mx dovecot: auth-worker(899854): Debug: conn unix:auth-worker (pid=899853,uid=110): auth-worker<3>: Finished Sep 2 15:25:34 mx dovecot: auth: Debug: sql(us...@mydomain.xyz,127.0.0.1,<97OusbbnXI1/AAAB>): Finished passdb lookup Sep 2 15:25:34 mx dovecot: auth: Debug: auth(us...@mydomain.xyz,127.0.0.1,<97OusbbnXI1/AAAB>): Auth request finished Sep 2 15:25:34 mx dovecot: auth: Debug: client passdb out: OK#0111#011user=us...@mydomain.xyz Sep 2 15:25:34 mx dovecot: auth: Debug: master in: REQUEST#0111998585857#011899859#0111#01131314e9e09e38b194a05b78bfe279780#011session_pid=899860#011request_auth_token Sep 2 15:25:34 mx dovecot: auth: Debug: sql(us...@mydomain.xyz,127.0.0.1,<97OusbbnXI1/AAAB>): Performing userdb lookup Sep 2 15:25:34 mx dovecot: auth-worker(899854): Debug: conn unix:auth-worker (pid=899853,uid=110): auth-worker<4>: Handling USER request Sep 2 15:25:34 mx dovecot: auth-worker(899854): Debug: conn unix:auth-worker (pid=899853,uid=110): auth-worker<4>: sql(us...@mydomain.xyz,127.0.0.1,<97OusbbnXI1/AAAB>): Performing userdb lookup Sep 2 15:25:34 mx dovecot: auth-worker(8
Re: Dovecot mail-crypt webmail can't read encrypted messages
Oh, I thought that section is for the global keys. I'm trying to use per-user/per-folder keys. I used this command: doveadm -o plugin/mail_crypt_private_password=xx mailbox cryptokey generate -u u...@mydomain.xyz -URf On 2022-09-14 17:47, hi@zakaria.website wrote: On 2022-09-14 15:11, Serveria Support wrote: How can I set the global private key in conf? I was following the official mail-crypt tutorial. This is what I have in dovecot.conf mail-crypt section: mail_crypt_curve = secp521r1 mail_crypt_save_version = 2 mail_crypt_require_encrypted_user_key = yes On 2022-09-14 17:23, hi@zakaria.website wrote: On 2022-09-14 14:41, Serveria Support wrote: Hi, This log shows no errors. Running doveadm fetch command gives me this: doveadm(u...@mydomain.xyz): Error: fetch(text) failed for box=INBOX uid=15: read() failed: read(/var/vmail/vmail1/mydomain.xyz/a/b/d/-2022.09.09.05.52.29//Maildir/cur/1663034263.M491074P1457418.mx,S=2217,W=2266:2,S) failed: Private key not available: Cannot decrypt key fd98762c573b8c54805884838695bd5b7eaeb9e0b0d326434c2f63a95a905a89: Cannot decrypt key 10fed5d3e938ce19a20046b84f29e50a271f6404f0760037996b4cf2d1ecfeb7: Password not available On 2022-09-13 14:43, hi@zakaria.website wrote: On 2022-09-02 20:40, Serveria Support wrote: I tried it but it doesn't seem to make any difference at all. Can someone please assist me with reading logs? Does this log below mean Dovecot is trying to use master_user again or simply reading master_user password file? Sep 2 15:35:33 mx dovecot: auth: Debug: Read auth token secret from /run/dovecot/auth-token-secret.dat Sep 2 15:35:33 mx dovecot: auth: Debug: passwd-file /etc/dovecot/dovecot-master-users: Read 1 users in 0 secs Sep 2 15:35:33 mx dovecot: auth: Debug: auth client connected (pid=900284) Sep 2 15:35:33 mx dovecot: auth: Debug: client in: AUTH#0111#011PLAIN#011service=imap#011secured=tls#011session=Vfxm1bbnRo9/AAAB#011lip=127.0.0.1#011rip=127.0.0.1#011lport=143#011rport=36678#011local_name=127.0.0.1#011resp=AHRlc3RvQG1haWxjaXRhZGVsLnh5egA0SFBYMWt0OSE= (previous base64 data may contain sensitive data) Everything ok here? Sep 2 15:25:34 mx dovecot: auth: Debug: auth client connected (pid=899859) Sep 2 15:25:34 mx dovecot: auth: Debug: client in: AUTH#0111#011PLAIN#011service=imap#011secured=tls#011session=97OusbbnXI1/AAAB#011lip=127.0.0.1#011rip=127.0.0.1#011lport=143#011rport=36188#011local_name=127.0.0.1#011resp=AHRlc3RvQG1haWxjaXRhZGVsLnh5egA0SFBYMWt0OSE= (previous base64 data may contain sensitive data) Sep 2 15:25:34 mx dovecot: auth: Debug: sql(us...@mydomain.xyz,127.0.0.1,<97OusbbnXI1/AAAB>): Performing passdb lookup Sep 2 15:25:34 mx dovecot: auth-worker(899854): Debug: conn unix:auth-worker (pid=899853,uid=110): auth-worker<3>: Handling PASSV request Sep 2 15:25:34 mx dovecot: auth-worker(899854): Debug: conn unix:auth-worker (pid=899853,uid=110): auth-worker<3>: sql(us...@mydomain.xyz,127.0.0.1,<97OusbbnXI1/AAAB>): Performing passdb lookup Sep 2 15:25:34 mx dovecot: auth-worker(899854): Debug: conn unix:auth-worker (pid=899853,uid=110): auth-worker<3>: sql(us...@mydomain.xyz,127.0.0.1,<97OusbbnXI1/AAAB>): query: SELECT mailbox.password, mailbox.allow_nets FROM mailbox,domain WHERE mailbox.username='us...@mydomain.xyz' AND mailbox.`enableimaptls`=1 AND mailbox.active=1 AND mailbox.domain=domain.domain AND domain.backupmx=0 AND domain.active=1 Sep 2 15:25:34 mx dovecot: auth-worker(899854): Debug: conn unix:auth-worker (pid=899853,uid=110): auth-worker<3>: sql(us...@mydomain.xyz,127.0.0.1,<97OusbbnXI1/AAAB>): Finished passdb lookup Sep 2 15:25:34 mx dovecot: auth-worker(899854): Debug: conn unix:auth-worker (pid=899853,uid=110): auth-worker<3>: Finished Sep 2 15:25:34 mx dovecot: auth: Debug: sql(us...@mydomain.xyz,127.0.0.1,<97OusbbnXI1/AAAB>): Finished passdb lookup Sep 2 15:25:34 mx dovecot: auth: Debug: auth(us...@mydomain.xyz,127.0.0.1,<97OusbbnXI1/AAAB>): Auth request finished Sep 2 15:25:34 mx dovecot: auth: Debug: client passdb out: OK#0111#011user=us...@mydomain.xyz Sep 2 15:25:34 mx dovecot: auth: Debug: master in: REQUEST#0111998585857#011899859#0111#01131314e9e09e38b194a05b78bfe279780#011session_pid=899860#011request_auth_token Sep 2 15:25:34 mx dovecot: auth: Debug: sql(us...@mydomain.xyz,127.0.0.1,<97OusbbnXI1/AAAB>): Performing userdb lookup Sep 2 15:25:34 mx dovecot: auth-worker(899854): Debug: conn unix:auth-worker (pid=899853,uid=110): auth-worker<4>: Handling USER request Sep 2 15:25:34 mx dovecot: auth-worker(899854): Debug: conn unix:auth-worker (pid=899853,uid=110): auth-worker<4>: sql(us...@mydomain.xyz,127.0.0.1,<97OusbbnXI1/AAAB>): Performing userdb lookup Sep 2 15:25:34 mx dovecot: auth-worker(899854): Debug: conn unix:auth-worker (pid=899853,uid=110): auth-worker<4>: sql(us...@mydomain.xyz,127.0.0.1,<97OusbbnXI1/AAAB>): SELECT LOWER(CONCAT(mailbox.storagebasedirectory, '/', mailbox.storagen
Re: Dovecot mail-crypt webmail can't read encrypted messages
How can I set the global private key in conf? I was following the official mail-crypt tutorial. This is what I have in dovecot.conf mail-crypt section: mail_crypt_curve = secp521r1 mail_crypt_save_version = 2 mail_crypt_require_encrypted_user_key = yes On 2022-09-14 17:23, hi@zakaria.website wrote: On 2022-09-14 14:41, Serveria Support wrote: Hi, This log shows no errors. Running doveadm fetch command gives me this: doveadm(u...@mydomain.xyz): Error: fetch(text) failed for box=INBOX uid=15: read() failed: read(/var/vmail/vmail1/mydomain.xyz/a/b/d/-2022.09.09.05.52.29//Maildir/cur/1663034263.M491074P1457418.mx,S=2217,W=2266:2,S) failed: Private key not available: Cannot decrypt key fd98762c573b8c54805884838695bd5b7eaeb9e0b0d326434c2f63a95a905a89: Cannot decrypt key 10fed5d3e938ce19a20046b84f29e50a271f6404f0760037996b4cf2d1ecfeb7: Password not available On 2022-09-13 14:43, hi@zakaria.website wrote: On 2022-09-02 20:40, Serveria Support wrote: I tried it but it doesn't seem to make any difference at all. Can someone please assist me with reading logs? Does this log below mean Dovecot is trying to use master_user again or simply reading master_user password file? Sep 2 15:35:33 mx dovecot: auth: Debug: Read auth token secret from /run/dovecot/auth-token-secret.dat Sep 2 15:35:33 mx dovecot: auth: Debug: passwd-file /etc/dovecot/dovecot-master-users: Read 1 users in 0 secs Sep 2 15:35:33 mx dovecot: auth: Debug: auth client connected (pid=900284) Sep 2 15:35:33 mx dovecot: auth: Debug: client in: AUTH#0111#011PLAIN#011service=imap#011secured=tls#011session=Vfxm1bbnRo9/AAAB#011lip=127.0.0.1#011rip=127.0.0.1#011lport=143#011rport=36678#011local_name=127.0.0.1#011resp=AHRlc3RvQG1haWxjaXRhZGVsLnh5egA0SFBYMWt0OSE= (previous base64 data may contain sensitive data) Everything ok here? Sep 2 15:25:34 mx dovecot: auth: Debug: auth client connected (pid=899859) Sep 2 15:25:34 mx dovecot: auth: Debug: client in: AUTH#0111#011PLAIN#011service=imap#011secured=tls#011session=97OusbbnXI1/AAAB#011lip=127.0.0.1#011rip=127.0.0.1#011lport=143#011rport=36188#011local_name=127.0.0.1#011resp=AHRlc3RvQG1haWxjaXRhZGVsLnh5egA0SFBYMWt0OSE= (previous base64 data may contain sensitive data) Sep 2 15:25:34 mx dovecot: auth: Debug: sql(us...@mydomain.xyz,127.0.0.1,<97OusbbnXI1/AAAB>): Performing passdb lookup Sep 2 15:25:34 mx dovecot: auth-worker(899854): Debug: conn unix:auth-worker (pid=899853,uid=110): auth-worker<3>: Handling PASSV request Sep 2 15:25:34 mx dovecot: auth-worker(899854): Debug: conn unix:auth-worker (pid=899853,uid=110): auth-worker<3>: sql(us...@mydomain.xyz,127.0.0.1,<97OusbbnXI1/AAAB>): Performing passdb lookup Sep 2 15:25:34 mx dovecot: auth-worker(899854): Debug: conn unix:auth-worker (pid=899853,uid=110): auth-worker<3>: sql(us...@mydomain.xyz,127.0.0.1,<97OusbbnXI1/AAAB>): query: SELECT mailbox.password, mailbox.allow_nets FROM mailbox,domain WHERE mailbox.username='us...@mydomain.xyz' AND mailbox.`enableimaptls`=1 AND mailbox.active=1 AND mailbox.domain=domain.domain AND domain.backupmx=0 AND domain.active=1 Sep 2 15:25:34 mx dovecot: auth-worker(899854): Debug: conn unix:auth-worker (pid=899853,uid=110): auth-worker<3>: sql(us...@mydomain.xyz,127.0.0.1,<97OusbbnXI1/AAAB>): Finished passdb lookup Sep 2 15:25:34 mx dovecot: auth-worker(899854): Debug: conn unix:auth-worker (pid=899853,uid=110): auth-worker<3>: Finished Sep 2 15:25:34 mx dovecot: auth: Debug: sql(us...@mydomain.xyz,127.0.0.1,<97OusbbnXI1/AAAB>): Finished passdb lookup Sep 2 15:25:34 mx dovecot: auth: Debug: auth(us...@mydomain.xyz,127.0.0.1,<97OusbbnXI1/AAAB>): Auth request finished Sep 2 15:25:34 mx dovecot: auth: Debug: client passdb out: OK#0111#011user=us...@mydomain.xyz Sep 2 15:25:34 mx dovecot: auth: Debug: master in: REQUEST#0111998585857#011899859#0111#01131314e9e09e38b194a05b78bfe279780#011session_pid=899860#011request_auth_token Sep 2 15:25:34 mx dovecot: auth: Debug: sql(us...@mydomain.xyz,127.0.0.1,<97OusbbnXI1/AAAB>): Performing userdb lookup Sep 2 15:25:34 mx dovecot: auth-worker(899854): Debug: conn unix:auth-worker (pid=899853,uid=110): auth-worker<4>: Handling USER request Sep 2 15:25:34 mx dovecot: auth-worker(899854): Debug: conn unix:auth-worker (pid=899853,uid=110): auth-worker<4>: sql(us...@mydomain.xyz,127.0.0.1,<97OusbbnXI1/AAAB>): Performing userdb lookup Sep 2 15:25:34 mx dovecot: auth-worker(899854): Debug: conn unix:auth-worker (pid=899853,uid=110): auth-worker<4>: sql(us...@mydomain.xyz,127.0.0.1,<97OusbbnXI1/AAAB>): SELECT LOWER(CONCAT(mailbox.storagebasedirectory, '/', mailbox.storagenode, '/', mailbox.maildir)) AS home, CONCAT(mailbox.mailboxformat, ':~/', mailbox.mailboxfolder) AS mail, CONCAT('*:bytes=', mailbox.quota*1048576) AS quota_rule FROM mailbox,domain WHERE mailbox.username='us...@mydomain.xyz' AND mailbox.`enableimaptls`=1 AND mailbox.active=1 AND mailbox.domain=domain.domain AND domain.back
Re: Dovecot mail-crypt webmail can't read encrypted messages
Hi, This log shows no errors. Running doveadm fetch command gives me this: doveadm(u...@mydomain.xyz): Error: fetch(text) failed for box=INBOX uid=15: read() failed: read(/var/vmail/vmail1/mydomain.xyz/a/b/d/-2022.09.09.05.52.29//Maildir/cur/1663034263.M491074P1457418.mx,S=2217,W=2266:2,S) failed: Private key not available: Cannot decrypt key fd98762c573b8c54805884838695bd5b7eaeb9e0b0d326434c2f63a95a905a89: Cannot decrypt key 10fed5d3e938ce19a20046b84f29e50a271f6404f0760037996b4cf2d1ecfeb7: Password not available On 2022-09-13 14:43, hi@zakaria.website wrote: On 2022-09-02 20:40, Serveria Support wrote: I tried it but it doesn't seem to make any difference at all. Can someone please assist me with reading logs? Does this log below mean Dovecot is trying to use master_user again or simply reading master_user password file? Sep 2 15:35:33 mx dovecot: auth: Debug: Read auth token secret from /run/dovecot/auth-token-secret.dat Sep 2 15:35:33 mx dovecot: auth: Debug: passwd-file /etc/dovecot/dovecot-master-users: Read 1 users in 0 secs Sep 2 15:35:33 mx dovecot: auth: Debug: auth client connected (pid=900284) Sep 2 15:35:33 mx dovecot: auth: Debug: client in: AUTH#0111#011PLAIN#011service=imap#011secured=tls#011session=Vfxm1bbnRo9/AAAB#011lip=127.0.0.1#011rip=127.0.0.1#011lport=143#011rport=36678#011local_name=127.0.0.1#011resp=AHRlc3RvQG1haWxjaXRhZGVsLnh5egA0SFBYMWt0OSE= (previous base64 data may contain sensitive data) Everything ok here? Sep 2 15:25:34 mx dovecot: auth: Debug: auth client connected (pid=899859) Sep 2 15:25:34 mx dovecot: auth: Debug: client in: AUTH#0111#011PLAIN#011service=imap#011secured=tls#011session=97OusbbnXI1/AAAB#011lip=127.0.0.1#011rip=127.0.0.1#011lport=143#011rport=36188#011local_name=127.0.0.1#011resp=AHRlc3RvQG1haWxjaXRhZGVsLnh5egA0SFBYMWt0OSE= (previous base64 data may contain sensitive data) Sep 2 15:25:34 mx dovecot: auth: Debug: sql(us...@mydomain.xyz,127.0.0.1,<97OusbbnXI1/AAAB>): Performing passdb lookup Sep 2 15:25:34 mx dovecot: auth-worker(899854): Debug: conn unix:auth-worker (pid=899853,uid=110): auth-worker<3>: Handling PASSV request Sep 2 15:25:34 mx dovecot: auth-worker(899854): Debug: conn unix:auth-worker (pid=899853,uid=110): auth-worker<3>: sql(us...@mydomain.xyz,127.0.0.1,<97OusbbnXI1/AAAB>): Performing passdb lookup Sep 2 15:25:34 mx dovecot: auth-worker(899854): Debug: conn unix:auth-worker (pid=899853,uid=110): auth-worker<3>: sql(us...@mydomain.xyz,127.0.0.1,<97OusbbnXI1/AAAB>): query: SELECT mailbox.password, mailbox.allow_nets FROM mailbox,domain WHERE mailbox.username='us...@mydomain.xyz' AND mailbox.`enableimaptls`=1 AND mailbox.active=1 AND mailbox.domain=domain.domain AND domain.backupmx=0 AND domain.active=1 Sep 2 15:25:34 mx dovecot: auth-worker(899854): Debug: conn unix:auth-worker (pid=899853,uid=110): auth-worker<3>: sql(us...@mydomain.xyz,127.0.0.1,<97OusbbnXI1/AAAB>): Finished passdb lookup Sep 2 15:25:34 mx dovecot: auth-worker(899854): Debug: conn unix:auth-worker (pid=899853,uid=110): auth-worker<3>: Finished Sep 2 15:25:34 mx dovecot: auth: Debug: sql(us...@mydomain.xyz,127.0.0.1,<97OusbbnXI1/AAAB>): Finished passdb lookup Sep 2 15:25:34 mx dovecot: auth: Debug: auth(us...@mydomain.xyz,127.0.0.1,<97OusbbnXI1/AAAB>): Auth request finished Sep 2 15:25:34 mx dovecot: auth: Debug: client passdb out: OK#0111#011user=us...@mydomain.xyz Sep 2 15:25:34 mx dovecot: auth: Debug: master in: REQUEST#0111998585857#011899859#0111#01131314e9e09e38b194a05b78bfe279780#011session_pid=899860#011request_auth_token Sep 2 15:25:34 mx dovecot: auth: Debug: sql(us...@mydomain.xyz,127.0.0.1,<97OusbbnXI1/AAAB>): Performing userdb lookup Sep 2 15:25:34 mx dovecot: auth-worker(899854): Debug: conn unix:auth-worker (pid=899853,uid=110): auth-worker<4>: Handling USER request Sep 2 15:25:34 mx dovecot: auth-worker(899854): Debug: conn unix:auth-worker (pid=899853,uid=110): auth-worker<4>: sql(us...@mydomain.xyz,127.0.0.1,<97OusbbnXI1/AAAB>): Performing userdb lookup Sep 2 15:25:34 mx dovecot: auth-worker(899854): Debug: conn unix:auth-worker (pid=899853,uid=110): auth-worker<4>: sql(us...@mydomain.xyz,127.0.0.1,<97OusbbnXI1/AAAB>): SELECT LOWER(CONCAT(mailbox.storagebasedirectory, '/', mailbox.storagenode, '/', mailbox.maildir)) AS home, CONCAT(mailbox.mailboxformat, ':~/', mailbox.mailboxfolder) AS mail, CONCAT('*:bytes=', mailbox.quota*1048576) AS quota_rule FROM mailbox,domain WHERE mailbox.username='us...@mydomain.xyz' AND mailbox.`enableimaptls`=1 AND mailbox.active=1 AND mailbox.domain=domain.domain AND domain.backupmx=0 AND domain.active=1 Sep 2 15:25:34 mx dovecot: auth-worker(899854): Debug: conn unix:auth-worker (pid=899853,uid=110): auth-worker<4>: sql(us...@mydomain.xyz,127.0.0.1,<97OusbbnXI1/AAAB>): Finished userdb lookup Sep 2 15:25:34 mx dovecot: auth-worker(899854): Debug: conn unix:auth-worker (pid=899853,uid=110): auth-worker<4>: Finished Sep 2 15:25
Re: Dovecot mail-crypt webmail can't read encrypted messages
I tried it but it doesn't seem to make any difference at all. Can someone please assist me with reading logs? Does this log below mean Dovecot is trying to use master_user again or simply reading master_user password file? Sep 2 15:35:33 mx dovecot: auth: Debug: Read auth token secret from /run/dovecot/auth-token-secret.dat Sep 2 15:35:33 mx dovecot: auth: Debug: passwd-file /etc/dovecot/dovecot-master-users: Read 1 users in 0 secs Sep 2 15:35:33 mx dovecot: auth: Debug: auth client connected (pid=900284) Sep 2 15:35:33 mx dovecot: auth: Debug: client in: AUTH#0111#011PLAIN#011service=imap#011secured=tls#011session=Vfxm1bbnRo9/AAAB#011lip=127.0.0.1#011rip=127.0.0.1#011lport=143#011rport=36678#011local_name=127.0.0.1#011resp=AHRlc3RvQG1haWxjaXRhZGVsLnh5egA0SFBYMWt0OSE= (previous base64 data may contain sensitive data) Everything ok here? Sep 2 15:25:34 mx dovecot: auth: Debug: auth client connected (pid=899859) Sep 2 15:25:34 mx dovecot: auth: Debug: client in: AUTH#0111#011PLAIN#011service=imap#011secured=tls#011session=97OusbbnXI1/AAAB#011lip=127.0.0.1#011rip=127.0.0.1#011lport=143#011rport=36188#011local_name=127.0.0.1#011resp=AHRlc3RvQG1haWxjaXRhZGVsLnh5egA0SFBYMWt0OSE= (previous base64 data may contain sensitive data) Sep 2 15:25:34 mx dovecot: auth: Debug: sql(us...@mydomain.xyz,127.0.0.1,<97OusbbnXI1/AAAB>): Performing passdb lookup Sep 2 15:25:34 mx dovecot: auth-worker(899854): Debug: conn unix:auth-worker (pid=899853,uid=110): auth-worker<3>: Handling PASSV request Sep 2 15:25:34 mx dovecot: auth-worker(899854): Debug: conn unix:auth-worker (pid=899853,uid=110): auth-worker<3>: sql(us...@mydomain.xyz,127.0.0.1,<97OusbbnXI1/AAAB>): Performing passdb lookup Sep 2 15:25:34 mx dovecot: auth-worker(899854): Debug: conn unix:auth-worker (pid=899853,uid=110): auth-worker<3>: sql(us...@mydomain.xyz,127.0.0.1,<97OusbbnXI1/AAAB>): query: SELECT mailbox.password, mailbox.allow_nets FROM mailbox,domain WHERE mailbox.username='us...@mydomain.xyz' AND mailbox.`enableimaptls`=1 AND mailbox.active=1 AND mailbox.domain=domain.domain AND domain.backupmx=0 AND domain.active=1 Sep 2 15:25:34 mx dovecot: auth-worker(899854): Debug: conn unix:auth-worker (pid=899853,uid=110): auth-worker<3>: sql(us...@mydomain.xyz,127.0.0.1,<97OusbbnXI1/AAAB>): Finished passdb lookup Sep 2 15:25:34 mx dovecot: auth-worker(899854): Debug: conn unix:auth-worker (pid=899853,uid=110): auth-worker<3>: Finished Sep 2 15:25:34 mx dovecot: auth: Debug: sql(us...@mydomain.xyz,127.0.0.1,<97OusbbnXI1/AAAB>): Finished passdb lookup Sep 2 15:25:34 mx dovecot: auth: Debug: auth(us...@mydomain.xyz,127.0.0.1,<97OusbbnXI1/AAAB>): Auth request finished Sep 2 15:25:34 mx dovecot: auth: Debug: client passdb out: OK#0111#011user=us...@mydomain.xyz Sep 2 15:25:34 mx dovecot: auth: Debug: master in: REQUEST#0111998585857#011899859#0111#01131314e9e09e38b194a05b78bfe279780#011session_pid=899860#011request_auth_token Sep 2 15:25:34 mx dovecot: auth: Debug: sql(us...@mydomain.xyz,127.0.0.1,<97OusbbnXI1/AAAB>): Performing userdb lookup Sep 2 15:25:34 mx dovecot: auth-worker(899854): Debug: conn unix:auth-worker (pid=899853,uid=110): auth-worker<4>: Handling USER request Sep 2 15:25:34 mx dovecot: auth-worker(899854): Debug: conn unix:auth-worker (pid=899853,uid=110): auth-worker<4>: sql(us...@mydomain.xyz,127.0.0.1,<97OusbbnXI1/AAAB>): Performing userdb lookup Sep 2 15:25:34 mx dovecot: auth-worker(899854): Debug: conn unix:auth-worker (pid=899853,uid=110): auth-worker<4>: sql(us...@mydomain.xyz,127.0.0.1,<97OusbbnXI1/AAAB>): SELECT LOWER(CONCAT(mailbox.storagebasedirectory, '/', mailbox.storagenode, '/', mailbox.maildir)) AS home, CONCAT(mailbox.mailboxformat, ':~/', mailbox.mailboxfolder) AS mail, CONCAT('*:bytes=', mailbox.quota*1048576) AS quota_rule FROM mailbox,domain WHERE mailbox.username='us...@mydomain.xyz' AND mailbox.`enableimaptls`=1 AND mailbox.active=1 AND mailbox.domain=domain.domain AND domain.backupmx=0 AND domain.active=1 Sep 2 15:25:34 mx dovecot: auth-worker(899854): Debug: conn unix:auth-worker (pid=899853,uid=110): auth-worker<4>: sql(us...@mydomain.xyz,127.0.0.1,<97OusbbnXI1/AAAB>): Finished userdb lookup Sep 2 15:25:34 mx dovecot: auth-worker(899854): Debug: conn unix:auth-worker (pid=899853,uid=110): auth-worker<4>: Finished Sep 2 15:25:34 mx dovecot: auth: Debug: sql(us...@mydomain.xyz,127.0.0.1,<97OusbbnXI1/AAAB>): Finished userdb lookup Sep 2 15:25:34 mx dovecot: auth: Debug: master userdb out: USER#0111998585857#011us...@mydomain.xyz#011home=/var/vmail/vmail1/mydomain.xyz/t/e/s/x-2022.08.30.06.07.08/#011mail=maildir:~/Maildir#011quota_rule=*:bytes=1073741824#011auth_mech=PLAIN#011auth_token=fac9c351492fd6073176272c79ff65b1b3e87f37 Sep 2 15:25:34 mx dovecot: imap(us...@mydomain.xyz)<899860><97OusbbnXI1/AAAB>: Debug: Added userdb setting: mail=maildir:~/Maildir Sep 2 15:25:34 mx dovecot: imap(us...@mydomain.xyz)<899860><97OusbbnXI1/AAAB>:
Re: Dovecot mail-crypt webmail can't read encrypted messages
password_query = SELECT \ username as user, password, \ '%w' AS userdb_mail_crypt_private_password \ FROM mailbox WHERE username="%u"; Try if using ' instead of " makes a difference. FROM mailbox WHERE username='%u';
Re: Dovecot mail-crypt webmail can't read encrypted messages
Still banging my head against the wall... Upon running this query: SELECT username as user, password, '%w' AS userdb_mail_crypt_private_password FROM mailbox; I'm getting the following output: ++---++ | user | password | userdb_mail_crypt_private_password | ++---++ | us...@mydomain.xyz | {SSHA512}1Z3spq1ySn4dmF2vgv5DRNW5KedMJH/Yspi+33PUTGe/9T6k8Uad62pAnKMUXOhGJliXSkPK24dHWs7UfHtMJFUpJdOX8kV9 | %w | | us...@mydomain.xyz | {SSHA512}xE+M7bD8nlbdfJl314iYmLgDjG0sud3oakQuxSYkcJYrLSoqgv9W7MD4ghtflZ32VgV6mnhcYIJrRK77tVCoDOG1dkA= | %w | | us...@mydomain.xyz | {SSHA512}LgmL2XS1b+cb/g/SVjWaic8fMn4h8pwud1Ark7rkpfcSOuIcib4eeKVO2yKW3BivulHuj3DA7s5591VLYiURek6SCJhKiqHo | %w | | us...@mydomain.xyz| {SSHA512}2e/VxDvjHbJZmBUMKYNlFM6Of7nbc5bDtm14Nz1IiFXQuq0VMgwOPCA8p9RTMav+KLX/tlCbKfkcbYzaNI/dHF2Nhiinyvnv | %w | | us...@mydomain.xyz | {SSHA512}/WDzitklDJ6yZH1eeRHljQvN1/MEB+bdXftSx7Sw2VBSyH21WlxjRx5dp3fiibhTNrHeIL5qWiADaBifJyfmKhn0Zi0TSwvp | %w | ++---++ 5 rows in set (0.000 sec) As soon as I'm adding WHERE username='%u'; at the end, query returns 0 rows. This is the exact contents of my file: password_query = SELECT \ username as user, password, \ '%w' AS userdb_mail_crypt_private_password \ FROM mailbox WHERE username="%u"; Is it ok to run it like this? Or should I construct a separate query "user_query=" ? It was like this in your tutorial... On 2022-08-30 16:13, Aki Tuomi wrote: You need to return the private password in your passdb query, like SELECT '%w' AS userdb_mail_crypt_private_password ... not in your userdb query, as %w will not be available there. Aki On 30/08/2022 15:33 EEST Serveria Support wrote: Update: I managed to remove the master user query so users are not getting marked as master_user on login. However, that doesn't seem to affect anything. I'm still unable to read encoded emails in webmail. No new errors are showing up in the log. I have even created a brand new user and all new keys via doveadm but still no go. Any suggestions? On 2022-08-29 16:30, Serveria Support wrote: > Upon closer review, it seems you're probably right: both users are in > fact marked master_user. How is that possible? I haven't marked new > user as a master_user. Are users marked master_user by default? What's > even more interesting, /etc/dovecot/dovecot-master-users doesn't > contain this user's data. Is it possible to unset this master_user > flag somehow? I browsed through the db in mySQL but wasn't able to > locate any master_users as well. Sorry for being such a noob... :) > > On 2022-08-29 11:33, Aki Tuomi wrote: >> Hard to say. >> >> If you are logging is master_user, there will be different password >> than normal user. Usually. With your setup, you can only access user's >> mail if you are using the exact same password that the user was using. >> >> Your logs seem to indicate that you are logging as master_user, so you >> are probably unable to access mails. >> >> Aki >> >> >>> On 29/08/2022 10:51 EEST Serveria Support >>> wrote: >>> >>> >>> Emm, sorry for the confusion, there are two users authenticating - >>> master user "postmaster" and the second user called "test". I have >>> just >>> obfuscated users by replacing usernames with myuser. So no, this >>> shouldn't be the issue. >>> >>> Any other suggestions? >>> >>> On 2022-08-29 10:30, Aki Tuomi wrote: >>> >> On 29/08/2022 09:26 EEST Serveria Support >>> >> wrote: >>> >> >>> >> >>> >> It's a testing install my main goal is to make it work. I will play >>> >> around with password encryption before going live. >>> >> >>> >> I have enabled all possible debugging yet I can's see the value you >>> >> mentioned in the log file. Could you please point me? >>> >> >>> >> Aug 29 01:46:30 mx dovecot: auth-worker(648543): Debug: conn >>> >> unix:auth-worker (pid=648542,uid=110): auth-worker<1>: >>> >> sql(myu...@mydomain.xyz,xx.xx.xx.xx,): query: SELECT >>> >> mailbox.password, mailbox.allow_nets FROM mailbox,domain WHERE >>> >> mailbox.username='myu...@mydomain.xyz' AND mailbox.`enableimaptls`=1 >>> >> AND >>> >> mailbox.active=1 AND mailbox.domain=domain.domain AND >>> >> domain.backupmx=0 >>> >> AND domain.active=1 >>> > >>> >
Re: Dovecot mail-crypt webmail can't read encrypted messages
That's exactly what I'm trying to do. Both userdb and passwdb are referring to dovecot-mysql.conf: userdb { args = /etc/dovecot/dovecot-mysql.conf driver = sql } passdb { args = /etc/dovecot/dovecot-mysql.conf driver = sql } dovecot-mysql.conf contains the following query only: password_query = SELECT \ username as "user", password, \ '%w' AS userdb_mail_crypt_private_password \ FROM mailbox WHERE username="%u"; It was taken from you tutorial (I was following this tutorial closely): https://doc.dovecot.org/configuration_manual/mail_crypt_plugin/ So what am I doing wrong? :) On 2022-08-30 16:13, Aki Tuomi wrote: You need to return the private password in your passdb query, like SELECT '%w' AS userdb_mail_crypt_private_password ... not in your userdb query, as %w will not be available there. Aki On 30/08/2022 15:33 EEST Serveria Support wrote: Update: I managed to remove the master user query so users are not getting marked as master_user on login. However, that doesn't seem to affect anything. I'm still unable to read encoded emails in webmail. No new errors are showing up in the log. I have even created a brand new user and all new keys via doveadm but still no go. Any suggestions? On 2022-08-29 16:30, Serveria Support wrote: > Upon closer review, it seems you're probably right: both users are in > fact marked master_user. How is that possible? I haven't marked new > user as a master_user. Are users marked master_user by default? What's > even more interesting, /etc/dovecot/dovecot-master-users doesn't > contain this user's data. Is it possible to unset this master_user > flag somehow? I browsed through the db in mySQL but wasn't able to > locate any master_users as well. Sorry for being such a noob... :) > > On 2022-08-29 11:33, Aki Tuomi wrote: >> Hard to say. >> >> If you are logging is master_user, there will be different password >> than normal user. Usually. With your setup, you can only access user's >> mail if you are using the exact same password that the user was using. >> >> Your logs seem to indicate that you are logging as master_user, so you >> are probably unable to access mails. >> >> Aki >> >> >>> On 29/08/2022 10:51 EEST Serveria Support >>> wrote: >>> >>> >>> Emm, sorry for the confusion, there are two users authenticating - >>> master user "postmaster" and the second user called "test". I have >>> just >>> obfuscated users by replacing usernames with myuser. So no, this >>> shouldn't be the issue. >>> >>> Any other suggestions? >>> >>> On 2022-08-29 10:30, Aki Tuomi wrote: >>> >> On 29/08/2022 09:26 EEST Serveria Support >>> >> wrote: >>> >> >>> >> >>> >> It's a testing install my main goal is to make it work. I will play >>> >> around with password encryption before going live. >>> >> >>> >> I have enabled all possible debugging yet I can's see the value you >>> >> mentioned in the log file. Could you please point me? >>> >> >>> >> Aug 29 01:46:30 mx dovecot: auth-worker(648543): Debug: conn >>> >> unix:auth-worker (pid=648542,uid=110): auth-worker<1>: >>> >> sql(myu...@mydomain.xyz,xx.xx.xx.xx,): query: SELECT >>> >> mailbox.password, mailbox.allow_nets FROM mailbox,domain WHERE >>> >> mailbox.username='myu...@mydomain.xyz' AND mailbox.`enableimaptls`=1 >>> >> AND >>> >> mailbox.active=1 AND mailbox.domain=domain.domain AND >>> >> domain.backupmx=0 >>> >> AND domain.active=1 >>> > >>> > it's not set here. >>> > >>> > >>> >> Aug 29 01:46:30 mx dovecot: auth-worker(648543): Debug: conn >>> >> unix:auth-worker (pid=648542,uid=110): auth-worker<2>: >>> >> sql(myu...@mydomain.xyz,xx.xx.xx.xx,): SELECT >>> >> LOWER('myu...@mydomain.xyz') AS master_user, >>> >> LOWER(CONCAT(mailbox.storagebasedirectory, '/', mailbox.storagenode, >>> >> '/', mailbox.maildir)) AS home, CONCAT(mailbox.mailboxformat, ':~/', >>> >> mailbox.mailboxfolder) AS mail, CONCAT('*:bytes=', >>> >> mailbox.quota*1048576) AS quota_rule FROM mailbox,domain WHERE >>> >> mailbox.username='myu...@mydomain.xyz' AND mailbox.`enableimaptls`=1 >>> >> AND >>> >> mailbox.active=1 AND mailbox.domain=domain.domain AND >>> >> domain.backupmx=0 >>> >> AND domain.active=1 >>> > >>> > it's not set here either. >>> > >>> > So. You are doing master user login, and are wondering why user's >>> > password is not available? >>> > >>> > Master user logins are not really compatible with using user's >>> > password as encryption key. >>> > >>> > Aki >>> > >>> >> >>> >> On 2022-08-29 07:56, Aki Tuomi wrote: >>> >> >> On 28/08/2022 09:20 EEST Serveria Support >>> >> >> wrote: >>> >> >> >>> >> >> >>> >> >> I'm trying to setup Dovecot with mail-crypt plugin with per-user >>> >> >> encryption. >>> >> >> >>> >> >> I have configured mail-crypt plugin as per official guide here: >>> >> >> https://doc.dovecot.org/configuration_manual/mail_crypt_plugin/ >>> >> >> >>> >> >> After that I created a user and an encrypted key by running this >>> >> >> command: doveadm -o \plugin/mail_crypt_private_password=123
Re: Dovecot mail-crypt webmail can't read encrypted messages
You need to return the private password in your passdb query, like SELECT '%w' AS userdb_mail_crypt_private_password ... not in your userdb query, as %w will not be available there. Aki > On 30/08/2022 15:33 EEST Serveria Support wrote: > > > Update: I managed to remove the master user query so users are not > getting marked as master_user on login. However, that doesn't seem to > affect anything. I'm still unable to read encoded emails in webmail. No > new errors are showing up in the log. I have even created a brand new > user and all new keys via doveadm but still no go. Any suggestions? > > On 2022-08-29 16:30, Serveria Support wrote: > > Upon closer review, it seems you're probably right: both users are in > > fact marked master_user. How is that possible? I haven't marked new > > user as a master_user. Are users marked master_user by default? What's > > even more interesting, /etc/dovecot/dovecot-master-users doesn't > > contain this user's data. Is it possible to unset this master_user > > flag somehow? I browsed through the db in mySQL but wasn't able to > > locate any master_users as well. Sorry for being such a noob... :) > > > > On 2022-08-29 11:33, Aki Tuomi wrote: > >> Hard to say. > >> > >> If you are logging is master_user, there will be different password > >> than normal user. Usually. With your setup, you can only access user's > >> mail if you are using the exact same password that the user was using. > >> > >> Your logs seem to indicate that you are logging as master_user, so you > >> are probably unable to access mails. > >> > >> Aki > >> > >> > >>> On 29/08/2022 10:51 EEST Serveria Support > >>> wrote: > >>> > >>> > >>> Emm, sorry for the confusion, there are two users authenticating - > >>> master user "postmaster" and the second user called "test". I have > >>> just > >>> obfuscated users by replacing usernames with myuser. So no, this > >>> shouldn't be the issue. > >>> > >>> Any other suggestions? > >>> > >>> On 2022-08-29 10:30, Aki Tuomi wrote: > >>> >> On 29/08/2022 09:26 EEST Serveria Support > >>> >> wrote: > >>> >> > >>> >> > >>> >> It's a testing install my main goal is to make it work. I will play > >>> >> around with password encryption before going live. > >>> >> > >>> >> I have enabled all possible debugging yet I can's see the value you > >>> >> mentioned in the log file. Could you please point me? > >>> >> > >>> >> Aug 29 01:46:30 mx dovecot: auth-worker(648543): Debug: conn > >>> >> unix:auth-worker (pid=648542,uid=110): auth-worker<1>: > >>> >> sql(myu...@mydomain.xyz,xx.xx.xx.xx,): query: SELECT > >>> >> mailbox.password, mailbox.allow_nets FROM mailbox,domain WHERE > >>> >> mailbox.username='myu...@mydomain.xyz' AND mailbox.`enableimaptls`=1 > >>> >> AND > >>> >> mailbox.active=1 AND mailbox.domain=domain.domain AND > >>> >> domain.backupmx=0 > >>> >> AND domain.active=1 > >>> > > >>> > it's not set here. > >>> > > >>> > > >>> >> Aug 29 01:46:30 mx dovecot: auth-worker(648543): Debug: conn > >>> >> unix:auth-worker (pid=648542,uid=110): auth-worker<2>: > >>> >> sql(myu...@mydomain.xyz,xx.xx.xx.xx,): SELECT > >>> >> LOWER('myu...@mydomain.xyz') AS master_user, > >>> >> LOWER(CONCAT(mailbox.storagebasedirectory, '/', mailbox.storagenode, > >>> >> '/', mailbox.maildir)) AS home, CONCAT(mailbox.mailboxformat, ':~/', > >>> >> mailbox.mailboxfolder) AS mail, CONCAT('*:bytes=', > >>> >> mailbox.quota*1048576) AS quota_rule FROM mailbox,domain WHERE > >>> >> mailbox.username='myu...@mydomain.xyz' AND mailbox.`enableimaptls`=1 > >>> >> AND > >>> >> mailbox.active=1 AND mailbox.domain=domain.domain AND > >>> >> domain.backupmx=0 > >>> >> AND domain.active=1 > >>> > > >>> > it's not set here either. > >>> > > >>> > So. You are doing master user login, and are wondering why user's > >>> > password is not available? > >>> > > >>> > Master user logins are not really compatible with using user's > >>> > password as encryption key. > >>> > > >>> > Aki > >>> > > >>> >> > >>> >> On 2022-08-29 07:56, Aki Tuomi wrote: > >>> >> >> On 28/08/2022 09:20 EEST Serveria Support > >>> >> >> wrote: > >>> >> >> > >>> >> >> > >>> >> >> I'm trying to setup Dovecot with mail-crypt plugin with per-user > >>> >> >> encryption. > >>> >> >> > >>> >> >> I have configured mail-crypt plugin as per official guide here: > >>> >> >> https://doc.dovecot.org/configuration_manual/mail_crypt_plugin/ > >>> >> >> > >>> >> >> After that I created a user and an encrypted key by running this > >>> >> >> command: doveadm -o \plugin/mail_crypt_private_password=12345 > >>> >> >> mailbox > >>> >> >> cryptokey generate -u m...@example.org -URf (replacing dummy data > >>> >> >> ofc) > >>> >> >> > >>> >> >> I can log in to webmail (and Dovecot) just fine, emails are getting > >>> >> >> sent > >>> >> >> and delivered. I have also checked the storage and the messages seem > >>> >> >> to > >>> >> >> be stored encrypted. > >>> >> >> > >>> >> >> However, I can't read the emails in webmail (j
Re: Dovecot mail-crypt webmail can't read encrypted messages
Update: I managed to remove the master user query so users are not getting marked as master_user on login. However, that doesn't seem to affect anything. I'm still unable to read encoded emails in webmail. No new errors are showing up in the log. I have even created a brand new user and all new keys via doveadm but still no go. Any suggestions? On 2022-08-29 16:30, Serveria Support wrote: Upon closer review, it seems you're probably right: both users are in fact marked master_user. How is that possible? I haven't marked new user as a master_user. Are users marked master_user by default? What's even more interesting, /etc/dovecot/dovecot-master-users doesn't contain this user's data. Is it possible to unset this master_user flag somehow? I browsed through the db in mySQL but wasn't able to locate any master_users as well. Sorry for being such a noob... :) On 2022-08-29 11:33, Aki Tuomi wrote: Hard to say. If you are logging is master_user, there will be different password than normal user. Usually. With your setup, you can only access user's mail if you are using the exact same password that the user was using. Your logs seem to indicate that you are logging as master_user, so you are probably unable to access mails. Aki On 29/08/2022 10:51 EEST Serveria Support wrote: Emm, sorry for the confusion, there are two users authenticating - master user "postmaster" and the second user called "test". I have just obfuscated users by replacing usernames with myuser. So no, this shouldn't be the issue. Any other suggestions? On 2022-08-29 10:30, Aki Tuomi wrote: >> On 29/08/2022 09:26 EEST Serveria Support >> wrote: >> >> >> It's a testing install my main goal is to make it work. I will play >> around with password encryption before going live. >> >> I have enabled all possible debugging yet I can's see the value you >> mentioned in the log file. Could you please point me? >> >> Aug 29 01:46:30 mx dovecot: auth-worker(648543): Debug: conn >> unix:auth-worker (pid=648542,uid=110): auth-worker<1>: >> sql(myu...@mydomain.xyz,xx.xx.xx.xx,): query: SELECT >> mailbox.password, mailbox.allow_nets FROM mailbox,domain WHERE >> mailbox.username='myu...@mydomain.xyz' AND mailbox.`enableimaptls`=1 >> AND >> mailbox.active=1 AND mailbox.domain=domain.domain AND >> domain.backupmx=0 >> AND domain.active=1 > > it's not set here. > > >> Aug 29 01:46:30 mx dovecot: auth-worker(648543): Debug: conn >> unix:auth-worker (pid=648542,uid=110): auth-worker<2>: >> sql(myu...@mydomain.xyz,xx.xx.xx.xx,): SELECT >> LOWER('myu...@mydomain.xyz') AS master_user, >> LOWER(CONCAT(mailbox.storagebasedirectory, '/', mailbox.storagenode, >> '/', mailbox.maildir)) AS home, CONCAT(mailbox.mailboxformat, ':~/', >> mailbox.mailboxfolder) AS mail, CONCAT('*:bytes=', >> mailbox.quota*1048576) AS quota_rule FROM mailbox,domain WHERE >> mailbox.username='myu...@mydomain.xyz' AND mailbox.`enableimaptls`=1 >> AND >> mailbox.active=1 AND mailbox.domain=domain.domain AND >> domain.backupmx=0 >> AND domain.active=1 > > it's not set here either. > > So. You are doing master user login, and are wondering why user's > password is not available? > > Master user logins are not really compatible with using user's > password as encryption key. > > Aki > >> >> On 2022-08-29 07:56, Aki Tuomi wrote: >> >> On 28/08/2022 09:20 EEST Serveria Support >> >> wrote: >> >> >> >> >> >> I'm trying to setup Dovecot with mail-crypt plugin with per-user >> >> encryption. >> >> >> >> I have configured mail-crypt plugin as per official guide here: >> >> https://doc.dovecot.org/configuration_manual/mail_crypt_plugin/ >> >> >> >> After that I created a user and an encrypted key by running this >> >> command: doveadm -o \plugin/mail_crypt_private_password=12345 mailbox >> >> cryptokey generate -u m...@example.org -URf (replacing dummy data ofc) >> >> >> >> I can log in to webmail (and Dovecot) just fine, emails are getting >> >> sent >> >> and delivered. I have also checked the storage and the messages seem >> >> to >> >> be stored encrypted. >> >> >> >> However, I can't read the emails in webmail (just headers can be seen) >> >> and in Dovecot logs I can see the following error: >> >> >> >> failed: Private key not available: Cannot decrypt key ### Cannot >> >> decrypt >> >> key ### <8632: Password not available (FETCH RFC822.HEADER) >> >> >> >> There seems to be an issue with mySQL query. The query I'm using >> >> (Select >> >> username as "user", password,"%w" as >> >> userdb_mail_crypt_private_password >> >> from mailbox;) seems to work just fine, when run from mysql prompt it >> >> outputs the usernames and passwords, but the error is still there >> >> (Cannot decrypt key ### Password not available). >> >> >> >> Any ideas? What am I missing >> > >> > Hi! >> > >> > First of all, it's super-unsafe to use user's password like that as >> > private password, at least run it through SHA256. This prevents >> > dovecot from doing expansions on it by accident. >> > >> > S
Re: Dovecot mail-crypt webmail can't read encrypted messages
Upon closer review, it seems you're probably right: both users are in fact marked master_user. How is that possible? I haven't marked new user as a master_user. Are users marked master_user by default? What's even more interesting, /etc/dovecot/dovecot-master-users doesn't contain this user's data. Is it possible to unset this master_user flag somehow? I browsed through the db in mySQL but wasn't able to locate any master_users as well. Sorry for being such a noob... :) On 2022-08-29 11:33, Aki Tuomi wrote: Hard to say. If you are logging is master_user, there will be different password than normal user. Usually. With your setup, you can only access user's mail if you are using the exact same password that the user was using. Your logs seem to indicate that you are logging as master_user, so you are probably unable to access mails. Aki On 29/08/2022 10:51 EEST Serveria Support wrote: Emm, sorry for the confusion, there are two users authenticating - master user "postmaster" and the second user called "test". I have just obfuscated users by replacing usernames with myuser. So no, this shouldn't be the issue. Any other suggestions? On 2022-08-29 10:30, Aki Tuomi wrote: >> On 29/08/2022 09:26 EEST Serveria Support >> wrote: >> >> >> It's a testing install my main goal is to make it work. I will play >> around with password encryption before going live. >> >> I have enabled all possible debugging yet I can's see the value you >> mentioned in the log file. Could you please point me? >> >> Aug 29 01:46:30 mx dovecot: auth-worker(648543): Debug: conn >> unix:auth-worker (pid=648542,uid=110): auth-worker<1>: >> sql(myu...@mydomain.xyz,xx.xx.xx.xx,): query: SELECT >> mailbox.password, mailbox.allow_nets FROM mailbox,domain WHERE >> mailbox.username='myu...@mydomain.xyz' AND mailbox.`enableimaptls`=1 >> AND >> mailbox.active=1 AND mailbox.domain=domain.domain AND >> domain.backupmx=0 >> AND domain.active=1 > > it's not set here. > > >> Aug 29 01:46:30 mx dovecot: auth-worker(648543): Debug: conn >> unix:auth-worker (pid=648542,uid=110): auth-worker<2>: >> sql(myu...@mydomain.xyz,xx.xx.xx.xx,): SELECT >> LOWER('myu...@mydomain.xyz') AS master_user, >> LOWER(CONCAT(mailbox.storagebasedirectory, '/', mailbox.storagenode, >> '/', mailbox.maildir)) AS home, CONCAT(mailbox.mailboxformat, ':~/', >> mailbox.mailboxfolder) AS mail, CONCAT('*:bytes=', >> mailbox.quota*1048576) AS quota_rule FROM mailbox,domain WHERE >> mailbox.username='myu...@mydomain.xyz' AND mailbox.`enableimaptls`=1 >> AND >> mailbox.active=1 AND mailbox.domain=domain.domain AND >> domain.backupmx=0 >> AND domain.active=1 > > it's not set here either. > > So. You are doing master user login, and are wondering why user's > password is not available? > > Master user logins are not really compatible with using user's > password as encryption key. > > Aki > >> >> On 2022-08-29 07:56, Aki Tuomi wrote: >> >> On 28/08/2022 09:20 EEST Serveria Support >> >> wrote: >> >> >> >> >> >> I'm trying to setup Dovecot with mail-crypt plugin with per-user >> >> encryption. >> >> >> >> I have configured mail-crypt plugin as per official guide here: >> >> https://doc.dovecot.org/configuration_manual/mail_crypt_plugin/ >> >> >> >> After that I created a user and an encrypted key by running this >> >> command: doveadm -o \plugin/mail_crypt_private_password=12345 mailbox >> >> cryptokey generate -u m...@example.org -URf (replacing dummy data ofc) >> >> >> >> I can log in to webmail (and Dovecot) just fine, emails are getting >> >> sent >> >> and delivered. I have also checked the storage and the messages seem >> >> to >> >> be stored encrypted. >> >> >> >> However, I can't read the emails in webmail (just headers can be seen) >> >> and in Dovecot logs I can see the following error: >> >> >> >> failed: Private key not available: Cannot decrypt key ### Cannot >> >> decrypt >> >> key ### <8632: Password not available (FETCH RFC822.HEADER) >> >> >> >> There seems to be an issue with mySQL query. The query I'm using >> >> (Select >> >> username as "user", password,"%w" as >> >> userdb_mail_crypt_private_password >> >> from mailbox;) seems to work just fine, when run from mysql prompt it >> >> outputs the usernames and passwords, but the error is still there >> >> (Cannot decrypt key ### Password not available). >> >> >> >> Any ideas? What am I missing >> > >> > Hi! >> > >> > First of all, it's super-unsafe to use user's password like that as >> > private password, at least run it through SHA256. This prevents >> > dovecot from doing expansions on it by accident. >> > >> > Secondly, enable mail_debug=yes and auth_debug=yes, run it again, and >> > make sure the correct value gets added as >> > 'plugin/mail_crypt_private_password' when using with webmail. >> > >> > Aki
Re: Dovecot mail-crypt webmail can't read encrypted messages
Hard to say. If you are logging is master_user, there will be different password than normal user. Usually. With your setup, you can only access user's mail if you are using the exact same password that the user was using. Your logs seem to indicate that you are logging as master_user, so you are probably unable to access mails. Aki > On 29/08/2022 10:51 EEST Serveria Support wrote: > > > Emm, sorry for the confusion, there are two users authenticating - > master user "postmaster" and the second user called "test". I have just > obfuscated users by replacing usernames with myuser. So no, this > shouldn't be the issue. > > Any other suggestions? > > On 2022-08-29 10:30, Aki Tuomi wrote: > >> On 29/08/2022 09:26 EEST Serveria Support > >> wrote: > >> > >> > >> It's a testing install my main goal is to make it work. I will play > >> around with password encryption before going live. > >> > >> I have enabled all possible debugging yet I can's see the value you > >> mentioned in the log file. Could you please point me? > >> > >> Aug 29 01:46:30 mx dovecot: auth-worker(648543): Debug: conn > >> unix:auth-worker (pid=648542,uid=110): auth-worker<1>: > >> sql(myu...@mydomain.xyz,xx.xx.xx.xx,): query: SELECT > >> mailbox.password, mailbox.allow_nets FROM mailbox,domain WHERE > >> mailbox.username='myu...@mydomain.xyz' AND mailbox.`enableimaptls`=1 > >> AND > >> mailbox.active=1 AND mailbox.domain=domain.domain AND > >> domain.backupmx=0 > >> AND domain.active=1 > > > > it's not set here. > > > > > >> Aug 29 01:46:30 mx dovecot: auth-worker(648543): Debug: conn > >> unix:auth-worker (pid=648542,uid=110): auth-worker<2>: > >> sql(myu...@mydomain.xyz,xx.xx.xx.xx,): SELECT > >> LOWER('myu...@mydomain.xyz') AS master_user, > >> LOWER(CONCAT(mailbox.storagebasedirectory, '/', mailbox.storagenode, > >> '/', mailbox.maildir)) AS home, CONCAT(mailbox.mailboxformat, ':~/', > >> mailbox.mailboxfolder) AS mail, CONCAT('*:bytes=', > >> mailbox.quota*1048576) AS quota_rule FROM mailbox,domain WHERE > >> mailbox.username='myu...@mydomain.xyz' AND mailbox.`enableimaptls`=1 > >> AND > >> mailbox.active=1 AND mailbox.domain=domain.domain AND > >> domain.backupmx=0 > >> AND domain.active=1 > > > > it's not set here either. > > > > So. You are doing master user login, and are wondering why user's > > password is not available? > > > > Master user logins are not really compatible with using user's > > password as encryption key. > > > > Aki > > > >> > >> On 2022-08-29 07:56, Aki Tuomi wrote: > >> >> On 28/08/2022 09:20 EEST Serveria Support > >> >> wrote: > >> >> > >> >> > >> >> I'm trying to setup Dovecot with mail-crypt plugin with per-user > >> >> encryption. > >> >> > >> >> I have configured mail-crypt plugin as per official guide here: > >> >> https://doc.dovecot.org/configuration_manual/mail_crypt_plugin/ > >> >> > >> >> After that I created a user and an encrypted key by running this > >> >> command: doveadm -o \plugin/mail_crypt_private_password=12345 mailbox > >> >> cryptokey generate -u m...@example.org -URf (replacing dummy data ofc) > >> >> > >> >> I can log in to webmail (and Dovecot) just fine, emails are getting > >> >> sent > >> >> and delivered. I have also checked the storage and the messages seem > >> >> to > >> >> be stored encrypted. > >> >> > >> >> However, I can't read the emails in webmail (just headers can be seen) > >> >> and in Dovecot logs I can see the following error: > >> >> > >> >> failed: Private key not available: Cannot decrypt key ### Cannot > >> >> decrypt > >> >> key ### <8632: Password not available (FETCH RFC822.HEADER) > >> >> > >> >> There seems to be an issue with mySQL query. The query I'm using > >> >> (Select > >> >> username as "user", password,"%w" as > >> >> userdb_mail_crypt_private_password > >> >> from mailbox;) seems to work just fine, when run from mysql prompt it > >> >> outputs the usernames and passwords, but the error is still there > >> >> (Cannot decrypt key ### Password not available). > >> >> > >> >> Any ideas? What am I missing > >> > > >> > Hi! > >> > > >> > First of all, it's super-unsafe to use user's password like that as > >> > private password, at least run it through SHA256. This prevents > >> > dovecot from doing expansions on it by accident. > >> > > >> > Secondly, enable mail_debug=yes and auth_debug=yes, run it again, and > >> > make sure the correct value gets added as > >> > 'plugin/mail_crypt_private_password' when using with webmail. > >> > > >> > Aki
Re: Dovecot mail-crypt webmail can't read encrypted messages
Emm, sorry for the confusion, there are two users authenticating - master user "postmaster" and the second user called "test". I have just obfuscated users by replacing usernames with myuser. So no, this shouldn't be the issue. Any other suggestions? On 2022-08-29 10:30, Aki Tuomi wrote: On 29/08/2022 09:26 EEST Serveria Support wrote: It's a testing install my main goal is to make it work. I will play around with password encryption before going live. I have enabled all possible debugging yet I can's see the value you mentioned in the log file. Could you please point me? Aug 29 01:46:30 mx dovecot: auth-worker(648543): Debug: conn unix:auth-worker (pid=648542,uid=110): auth-worker<1>: sql(myu...@mydomain.xyz,xx.xx.xx.xx,): query: SELECT mailbox.password, mailbox.allow_nets FROM mailbox,domain WHERE mailbox.username='myu...@mydomain.xyz' AND mailbox.`enableimaptls`=1 AND mailbox.active=1 AND mailbox.domain=domain.domain AND domain.backupmx=0 AND domain.active=1 it's not set here. Aug 29 01:46:30 mx dovecot: auth-worker(648543): Debug: conn unix:auth-worker (pid=648542,uid=110): auth-worker<2>: sql(myu...@mydomain.xyz,xx.xx.xx.xx,): SELECT LOWER('myu...@mydomain.xyz') AS master_user, LOWER(CONCAT(mailbox.storagebasedirectory, '/', mailbox.storagenode, '/', mailbox.maildir)) AS home, CONCAT(mailbox.mailboxformat, ':~/', mailbox.mailboxfolder) AS mail, CONCAT('*:bytes=', mailbox.quota*1048576) AS quota_rule FROM mailbox,domain WHERE mailbox.username='myu...@mydomain.xyz' AND mailbox.`enableimaptls`=1 AND mailbox.active=1 AND mailbox.domain=domain.domain AND domain.backupmx=0 AND domain.active=1 it's not set here either. So. You are doing master user login, and are wondering why user's password is not available? Master user logins are not really compatible with using user's password as encryption key. Aki On 2022-08-29 07:56, Aki Tuomi wrote: >> On 28/08/2022 09:20 EEST Serveria Support >> wrote: >> >> >> I'm trying to setup Dovecot with mail-crypt plugin with per-user >> encryption. >> >> I have configured mail-crypt plugin as per official guide here: >> https://doc.dovecot.org/configuration_manual/mail_crypt_plugin/ >> >> After that I created a user and an encrypted key by running this >> command: doveadm -o \plugin/mail_crypt_private_password=12345 mailbox >> cryptokey generate -u m...@example.org -URf (replacing dummy data ofc) >> >> I can log in to webmail (and Dovecot) just fine, emails are getting >> sent >> and delivered. I have also checked the storage and the messages seem >> to >> be stored encrypted. >> >> However, I can't read the emails in webmail (just headers can be seen) >> and in Dovecot logs I can see the following error: >> >> failed: Private key not available: Cannot decrypt key ### Cannot >> decrypt >> key ### <8632: Password not available (FETCH RFC822.HEADER) >> >> There seems to be an issue with mySQL query. The query I'm using >> (Select >> username as "user", password,"%w" as >> userdb_mail_crypt_private_password >> from mailbox;) seems to work just fine, when run from mysql prompt it >> outputs the usernames and passwords, but the error is still there >> (Cannot decrypt key ### Password not available). >> >> Any ideas? What am I missing > > Hi! > > First of all, it's super-unsafe to use user's password like that as > private password, at least run it through SHA256. This prevents > dovecot from doing expansions on it by accident. > > Secondly, enable mail_debug=yes and auth_debug=yes, run it again, and > make sure the correct value gets added as > 'plugin/mail_crypt_private_password' when using with webmail. > > Aki
Re: Dovecot mail-crypt webmail can't read encrypted messages
> On 29/08/2022 09:26 EEST Serveria Support wrote: > > > It's a testing install my main goal is to make it work. I will play > around with password encryption before going live. > > I have enabled all possible debugging yet I can's see the value you > mentioned in the log file. Could you please point me? > > Aug 29 01:46:30 mx dovecot: auth-worker(648543): Debug: conn > unix:auth-worker (pid=648542,uid=110): auth-worker<1>: > sql(myu...@mydomain.xyz,xx.xx.xx.xx,): query: SELECT > mailbox.password, mailbox.allow_nets FROM mailbox,domain WHERE > mailbox.username='myu...@mydomain.xyz' AND mailbox.`enableimaptls`=1 AND > mailbox.active=1 AND mailbox.domain=domain.domain AND domain.backupmx=0 > AND domain.active=1 it's not set here. > Aug 29 01:46:30 mx dovecot: auth-worker(648543): Debug: conn > unix:auth-worker (pid=648542,uid=110): auth-worker<2>: > sql(myu...@mydomain.xyz,xx.xx.xx.xx,): SELECT > LOWER('myu...@mydomain.xyz') AS master_user, > LOWER(CONCAT(mailbox.storagebasedirectory, '/', mailbox.storagenode, > '/', mailbox.maildir)) AS home, CONCAT(mailbox.mailboxformat, ':~/', > mailbox.mailboxfolder) AS mail, CONCAT('*:bytes=', > mailbox.quota*1048576) AS quota_rule FROM mailbox,domain WHERE > mailbox.username='myu...@mydomain.xyz' AND mailbox.`enableimaptls`=1 AND > mailbox.active=1 AND mailbox.domain=domain.domain AND domain.backupmx=0 > AND domain.active=1 it's not set here either. So. You are doing master user login, and are wondering why user's password is not available? Master user logins are not really compatible with using user's password as encryption key. Aki > > On 2022-08-29 07:56, Aki Tuomi wrote: > >> On 28/08/2022 09:20 EEST Serveria Support > >> wrote: > >> > >> > >> I'm trying to setup Dovecot with mail-crypt plugin with per-user > >> encryption. > >> > >> I have configured mail-crypt plugin as per official guide here: > >> https://doc.dovecot.org/configuration_manual/mail_crypt_plugin/ > >> > >> After that I created a user and an encrypted key by running this > >> command: doveadm -o \plugin/mail_crypt_private_password=12345 mailbox > >> cryptokey generate -u m...@example.org -URf (replacing dummy data ofc) > >> > >> I can log in to webmail (and Dovecot) just fine, emails are getting > >> sent > >> and delivered. I have also checked the storage and the messages seem > >> to > >> be stored encrypted. > >> > >> However, I can't read the emails in webmail (just headers can be seen) > >> and in Dovecot logs I can see the following error: > >> > >> failed: Private key not available: Cannot decrypt key ### Cannot > >> decrypt > >> key ### <8632: Password not available (FETCH RFC822.HEADER) > >> > >> There seems to be an issue with mySQL query. The query I'm using > >> (Select > >> username as "user", password,"%w" as > >> userdb_mail_crypt_private_password > >> from mailbox;) seems to work just fine, when run from mysql prompt it > >> outputs the usernames and passwords, but the error is still there > >> (Cannot decrypt key ### Password not available). > >> > >> Any ideas? What am I missing > > > > Hi! > > > > First of all, it's super-unsafe to use user's password like that as > > private password, at least run it through SHA256. This prevents > > dovecot from doing expansions on it by accident. > > > > Secondly, enable mail_debug=yes and auth_debug=yes, run it again, and > > make sure the correct value gets added as > > 'plugin/mail_crypt_private_password' when using with webmail. > > > > Aki
Re: Dovecot mail-crypt webmail can't read encrypted messages
> On 28/08/2022 09:20 EEST Serveria Support wrote: > > > I'm trying to setup Dovecot with mail-crypt plugin with per-user > encryption. > > I have configured mail-crypt plugin as per official guide here: > https://doc.dovecot.org/configuration_manual/mail_crypt_plugin/ > > After that I created a user and an encrypted key by running this > command: doveadm -o \plugin/mail_crypt_private_password=12345 mailbox > cryptokey generate -u m...@example.org -URf (replacing dummy data ofc) > > I can log in to webmail (and Dovecot) just fine, emails are getting sent > and delivered. I have also checked the storage and the messages seem to > be stored encrypted. > > However, I can't read the emails in webmail (just headers can be seen) > and in Dovecot logs I can see the following error: > > failed: Private key not available: Cannot decrypt key ### Cannot decrypt > key ### <8632: Password not available (FETCH RFC822.HEADER) > > There seems to be an issue with mySQL query. The query I'm using (Select > username as "user", password,"%w" as userdb_mail_crypt_private_password > from mailbox;) seems to work just fine, when run from mysql prompt it > outputs the usernames and passwords, but the error is still there > (Cannot decrypt key ### Password not available). > > Any ideas? What am I missing Hi! First of all, it's super-unsafe to use user's password like that as private password, at least run it through SHA256. This prevents dovecot from doing expansions on it by accident. Secondly, enable mail_debug=yes and auth_debug=yes, run it again, and make sure the correct value gets added as 'plugin/mail_crypt_private_password' when using with webmail. Aki