[Date Prev][Date Next]
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.