[Dovecot] Detail improvement: %c variable
Hi,
although dovecot is great and almost exactly solving my problems and fitting my requirements, there is an odd detail that causes me problems:
The %c variable. (See http://wiki2.dovecot.org/Variables )
I'm managing an IMAP server for an association, which is connected to an LDAP server. Users can connect in three ways: IMAPS from the internet, IMAP from local acccounts, and IMAP through a Web->IMAP interface, which is protected through additional one-time-passwords.
The web gateway is intended to be used from untrusted computers as well, so the IMAP password entered through the Web site must not be the same as the password used on IMAPS.
I have solved this problem by using %s%c as part of the LDAP user_filter. When people connect over IMAPS, this becomes imapsecured (%s=imap, %c=secured), while an unencrypted connect becomes imap (%s=imap, %c=)
Unfortunately, this works only, if the web interface and the IMAP server are located on different (virtual) machines.
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.
Please add a configuration variable to configure, whether %c should become "secured" for unencrypted traffic on the loopback device (localhost).
regards Hadmut
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
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
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.
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
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
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 giles@coochey.net
-----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-----
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
-----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-----
participants (5)
-
Andreas Schulze
-
Giles Coochey
-
Hadmut Danisch
-
Reindl Harald
-
Steffen Kaiser