changed notes
Full_Name: Emile LeBlanc Version: openldap-clients-2.3.43-12.el5_5.3.i386 OS: Red Hat Enterprise Linux 5.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.100.68.202) I am running the latest version of ldapsearch (that comes with Red Hat Enterprise Linux 5.6) on my machine. If I run: ldapsearch -Z -W -LLL -D "uid=guest,ou=Unit,dc=math,dc=toronto,dc=edu" -H ldap://test.math.toronto.edu -x -b "dc=math,dc=toronto,dc=edu" "(uid=guest)" then the result is as I expect (after I type the passwd to the "Enter LDAP Password:" prompt). However if I remove the "-Z" flag and run: ldapsearch -W -LLL -D "uid=guest,ou=Unit,dc=math,dc=toronto,dc=edu" -H ldap://test.math.toronto.edu -x -b "dc=math,dc=toronto,dc=edu" "(uid=guest)" then, after typing the password I see: ldap_bind: Confidentiality required (13) additional info: confidentiality required This result was also expected since the ldap server has: security ssf=256 in the slapd.conf file. What was unexpected was that the password was sent in cleartext in the second "ldapsearch" command (I verified this with "wireshark", a network packet analyzer). It is true that I should use the "-Z" flag if I want encryption but I think that a simple error on the client end should not expose a password when the initial connection to a secured server could have been tried without transmitting the password to see if additional security was needed. Perhaps there is some good reason for the current behavior, but I wanted to make sure that people realized what was happening. Perhaps the performance hit my suggestion would entail is not worth it for other users. Thank you.
I'd note that sending cleartext credentials is just wrong regardless of the ssf the server requires. OpenLDAP's ldapsearch assumes users know what they are doing. Actually, this client is mainly intended as a tool that allows to perform operations with as many parameter combinations as needed to test the functionalities of slapd. What you recommend would probably be appropriate for a "real life" client implementation. Moreover, the only way to test whether the security factor requested by the server is in place would require the client to attempt a simple bind with intentionally invalid credentials; considering slapd's possibility to configure security per-database, one would need to either use the "right" DN (thus exposing it), or a fake DN that for sure is within the same naming context, and incorrect credentials. I believe this amount of wisdom is beyond any "real life" client implementation. Of course I would not object to any patch for ldapsearch (actually, for all clients) that solves this problem in a general manner without requiring any user intervention. p.
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 choices. 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
Kurt@OpenLDAP.org wrote: > 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. While this is true in general there still could be a benefit from disallowing connections without StartTLS at the server-side: Normally in a serious deployment there are integration tests done with client applications for which no real passwords are used. Disallowing non-protected connections would reveal misconfiguration immediately and the application can then be modified to do the right thing. Ciao, Michael.
On Jan 27, 2011, at 2:30 AM, Michael Ströder wrote: > Kurt@OpenLDAP.org wrote: >> 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. > > While this is true in general there still could be a benefit from disallowing > connections without StartTLS at the server-side: Yes, and slapd(8) has long supported such a configuration and, in fact, the OP had such a configuration. > Normally in a serious deployment there are integration tests done with client > applications for which no real passwords are used. Disallowing non-protected > connections would reveal misconfiguration immediately and the application can > then be modified to do the right thing. > > Ciao, Michael.
moved from Incoming to Software Enhancements
patch welcome
Fixing this literally requires changing the LDAP protocol. I.e., this would require LDAPv4. Closing.