Re: [Dovecot] Detail improvement: %c variable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 24 Feb 2014, Andreas Schulze wrote: Hadmut Danisch: I did not say that I did not trust 127.0.0.1. I said that I do not trust the Web-IMAP-Gateway (such as squirrelmail) if the client uses an untrusted computer. the question to me is: why could Hadmut Danisch not configure dovecot use an non default trust state for localhost for whatever reasons? because this setting is hardcoded but should be configurable for him. Probably if one goes to implement such option, it would be also a good thing to let this be configurable using "local" blocks. I mean, in order to enable/disable the implicit trust per IP address. That way one could point one service, such as the web frontend, on an IP adsress, that defaults to "not secured", but have others that default to "secured". - -- Steffen Kaiser -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQEVAwUBUwxN+XD1/YhP6VMHAQL7XQgA0mEj0UShy+yUdlLVXNCeH/fD9Qy8ZPAB bkyIsUeWc5lDGwrj5Dgz6c06cLo5YHh67hNzmINiYoY5FwAu2iDuwC7ASq1U2n+3 ZPy/eo4+p3SA9vRVIWOv4PK9Sy7zpm0kypkmCzzrUKXt7WdE275P+dGyF5dvwKjS dGJGhcfWG920YJ4/BbnjyonE3SbduCSylvmu/3e4B6KNkRHAsOLClcVI+Xrcb3CU Q5pdnjZWJ0FIKPIu2D4GvbD0Bsyml/JnYEeZfHdZ88rItNWOCpDuO3KmkjBvaCMx MdXLRjxP/EnhkzRikHUC9uHUlhjsk9mLQLJm8/a+PFprFZ4cIv3e6Q== =c9Qh -END PGP SIGNATURE-
Re: [Dovecot] Detail improvement: %c variable
Hadmut Danisch: I did not say that I did not trust 127.0.0.1. I said that I do not trust the Web-IMAP-Gateway (such as squirrelmail) if the client uses an untrusted computer. the question to me is: why could Hadmut Danisch not configure dovecot use an non default trust state for localhost for whatever reasons? because this setting is hardcoded but should be configurable for him. Andeas
Re: [Dovecot] Detail improvement: %c variable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 24 Feb 2014, Giles Coochey wrote: You could choose not to use localhost IP, but bind to the actual local IP of the host, even though it is on the local machine? Is it only attaching to the 127.0.0.1 because you're binding to it by hostname as opposed to IP? Won't work, I tried it with v2.2.10. Any connection to a local IP from a local IP seems to be "secured". Maybe with a virtual one. - -- Steffen Kaiser -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQEVAwUBUwttZHD1/YhP6VMHAQKe5wgA5q16t412w/HOD01U84fEmyRnu8yZlOti 1GrRPudqtwFRTpwP2zgKFpZsZCcrbGOfHQyIkQEUahnFg1MFNsO0OQovP+480E0B t++NhGdZhIbK2p0b1VSyx0OyexBZrKR96qylgAgEgP3K/HtevzduqFXrETr0kGZF Ri7YUPDKurtvTHN+q91krFY/7aGaF8XWsM0M/SY/+ZKKOMAdNBgm8Pyv5d1iS4Xv kjetCfb4fH05e8yeFlaSM83Qrg+YryTH5gbOPschj3rIae9VU7UOZFMThWDBM54F VGvfLLGsTxAqWOsqAqjFDFe3xagqrFy68xpO5ijjaP0vHQYUNgSz6Q== =QBAY -END PGP SIGNATURE-
Re: [Dovecot] Detail improvement: %c variable
On 24/02/2014 15:19, Hadmut Danisch wrote: As far as I can see dovecot does not consider 127.0.0.1 as "secured" for any good reason, just to make debugging in plaintext easier. This is a severe security gap. Hadmut You could choose not to use localhost IP, but bind to the actual local IP of the host, even though it is on the local machine? Is it only attaching to the 127.0.0.1 because you're binding to it by hostname as opposed to IP? Just a thought... -- Regards, Giles Coochey, CCNP, CCNA, CCNAS NetSecSpec Ltd +44 (0) 8444 780677 +44 (0) 7983 877438 http://www.coochey.net http://www.netsecspec.co.uk gi...@coochey.net smime.p7s Description: S/MIME Cryptographic Signature
Re: [Dovecot] Detail improvement: %c variable
Am 24.02.2014 16:19, schrieb Hadmut Danisch: > On Mon, Feb 24, 2014 at 12:54:51AM +0100, Reindl Harald wrote: >> >> you described nothing relevant > > You're quite ignorant and obviously don't understand the background. no >> you only talk why 127.0.0.1 is treated as "secured" >> well because it is by definition, if you don't trust >> 127.0.0.1 you have lost the game at all > > > Which is wrong. > > I did not say that I did not trust 127.0.0.1. I said that I do not > trust the Web-IMAP-Gateway (such as squirrelmail) if the client uses > an untrusted computer. which should not run on the mailserver at all if we talk about security > Unfortunately, this works only, if the web interface and the IMAP server > are located on different (virtual) machines that is how it should be > But if the web gateway and dovecot are on the /same/ machine, > this does not work anymore that is how it should *not* be http://www.avolio.com/columns/e-mailServerSecurity.html > Again, your statements are technically wrong and you obviously do not > understand the security implications. i understand them well, that's why the case having a service you do not trust on the same machine is questionable to say it nice > As I said before, the Webserver protects the Web access with a > one-time-password. So an IMAP password caught at a computer using the > Web interface is useless for an attacker, since the attacker could not > login again with caught passwords. > > But the attacker could use the password fetched by a keylogger to > directly access the IMAPS port (without the web and thus without the need > to use a one-time-password) if the web interface (going over > 127.0.0.1) and IMAPS share the same password - what they do due to bad > design of dovecot. no, they do due bad design of your network as you statet above by "web gateway and dovecot are on the /same/ machine" > May I kindly ask you to stop giving negativ or even harsh and > offensive replies as long as you do not understand the security > implications and the web technology? there was nothing harsh or offensive > Your statements about man-in-the-middle and trusting 127.0.0.1 are so > technically wrong, that I do not see a point in this conversation. the reason why dovecot treats localhost as "secured" is because it is typically secured as long you don't mix trusted and untrusted software on the sam emachone > As far as I can see dovecot does not consider 127.0.0.1 as "secured" > for any good reason, just to make debugging in plaintext easier. This > is a severe security gap see above don't run trusted and untrusted services on the same machine signature.asc Description: OpenPGP digital signature
Re: [Dovecot] Detail improvement: %c variable
On Mon, Feb 24, 2014 at 12:54:51AM +0100, Reindl Harald wrote: > > you described nothing relevant You're quite ignorant and obviously don't understand the background. > you only talk why 127.0.0.1 is treated as "secured" > well because it is by definition, if you don't trust > 127.0.0.1 you have lost the game at all Which is wrong. I did not say that I did not trust 127.0.0.1. I said that I do not trust the Web-IMAP-Gateway (such as squirrelmail) if the client uses an untrusted computer. > > >> how do you imagine a man-in-the-middle-attack on 127.0.0.1 > > > > You're confusing the different attacks. This has nothing to do with a > > man-in-the-middle. This is against a passive eavesdropper, > > e.g. someone watching people entering the password at a web interface, > > or a keylogger on an unreliable computer > > RTFM - these is *logging* and there it does not make a difference > in case of security if it was a encrypted connection or one > from LOCALHOST where there is no wire at all between client and > server Again, your statements are technically wrong and you obviously do not understand the security implications. As I said before, the Webserver protects the Web access with a one-time-password. So an IMAP password caught at a computer using the Web interface is useless for an attacker, since the attacker could not login again with caught passwords. But the attacker could use the password fetched by a keylogger to directly access the IMAPS port (without the web and thus without the need to use a one-time-password) if the web interface (going over 127.0.0.1) and IMAPS share the same password - what they do due to bad design of dovecot. May I kindly ask you to stop giving negativ or even harsh and offensive replies as long as you do not understand the security implications and the web technology? Your statements about man-in-the-middle and trusting 127.0.0.1 are so technically wrong, that I do not see a point in this conversation. As far as I can see dovecot does not consider 127.0.0.1 as "secured" for any good reason, just to make debugging in plaintext easier. This is a severe security gap. Hadmut
Re: [Dovecot] Detail improvement: %c variable
Am 24.02.2014 00:23, schrieb Hadmut Danisch: > On Sun, Feb 23, 2014 at 11:37:55PM +0100, Reindl Harald wrote: >> what headache? > The one I've described. you described nothing relevant you only talk why 127.0.0.1 is treated as "secured" well because it is by definition, if you don't trust 127.0.0.1 you have lost the game at all >> how do you imagine a man-in-the-middle-attack on 127.0.0.1 > > You're confusing the different attacks. This has nothing to do with a > man-in-the-middle. This is against a passive eavesdropper, > e.g. someone watching people entering the password at a web interface, > or a keylogger on an unreliable computer RTFM - these is *logging* and there it does not make a difference in case of security if it was a encrypted connection or one from LOCALHOST where there is no wire at all between client and server These variables work only in Dovecot-auth and *login_log_format_elements* setting %c secured "secured" string with SSL, TLS and localhost connections. Otherwise empty. signature.asc Description: OpenPGP digital signature
Re: [Dovecot] Detail improvement: %c variable
On Sun, Feb 23, 2014 at 11:37:55PM +0100, Reindl Harald wrote: > > what headache? The one I've described. > > how do you imagine a man-in-the-middle-attack on 127.0.0.1 You're confusing the different attacks. This has nothing to do with a man-in-the-middle. This is against a passive eavesdropper, e.g. someone watching people entering the password at a web interface, or a keylogger on an unreliable computer. > > Please add a configuration variable to configure, whether %c > > should become "secured" for unencrypted traffic on the loopback > > device (localhost) > > to gain exactly what? to gain different LDAP filter strings for IMAP requests coming from outside encrypted with SSL/TLS and unencrypted IMAP requests on localhost. > frankly for practical usage epect debugging even a fallback to > no encryption at all on loopback would be sane and for the > sake of reduce useless overhead fine It is never a good idea to lower security in favor of easy debugging. That's why I propose a switch to turn this behaviour on and off. Hadmut
Re: [Dovecot] Detail improvement: %c variable
Am 23.02.2014 23:27, schrieb Hadmut Danisch: > But if the web gateway and dovecot are no the /same/ machine, this does > not work anymore, since %c becomes "secured" on localhost, even if > unencrypted. It causes a lot of trouble and headache what headache? how do you imagine a man-in-the-middle-attack on 127.0.0.1 > Please add a configuration variable to configure, whether %c > should become "secured" for unencrypted traffic on the loopback > device (localhost) to gain exactly what? frankly for practical usage epect debugging even a fallback to no encryption at all on loopback would be sane and for the sake of reduce useless overhead fine signature.asc Description: OpenPGP digital signature
