[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: ITS#6805

The OP expects somehow for the server to prevent the client from =
exposing information when the server has no control over what the client =
sends.  This simply is not possible and hence should not be expected.

Even if the server were configured only with a ldaps:// listener, =
clients would not be precluded from sending a password to the server in =
the clear.  A client could be told to connect to that listener and send =
a LDAP Simple Bind with password without ever attempting to start TLS.   =
Sure, the server will error, but the password is exposed none the less.

As you indicate, the same issue exist in more robust clients as well.  =
It's quite hard to provide client configurability and prevention from =
misconfiguration which lead to security issues concurrently.  How is the =
client software to know that StartTLS or ldaps:// was wanted with it =
wasn't so configured?  The best a robust client could do here is warn =
the user of security concerns that arise from their configuration =

I would have no objection to adding such robustness to OpenLDAP command =
line tools so long as such warnings were off by default.  Kicking out =
warnings as the default would likely break a lot of scripts which use =
OpenLDAP command line tools.

-- Kurt=