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