kurt@openldap.org wrote:

Full_Name: Kurt Zeilenga Version: most every OS: MacOS URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:470:f052:8000:7cca:294:b2d:2652)

The client tools were designed to support optimistic encryption (-Z)... in cases where the server says "yes, let's start TLS...", TLS negotiations must be entered into and, if they fail, no further LDAP traffic should be allowed on the stream. Upon TLS alert, the session should no longer usable. Further attempts to send any PDU should fail.

I guess this was never stated clearly. "-ZZ" meant require TLS, drop the session if TLS fails. "-Z" meant proceed if TLS fails. No one ever specified exactly what types of failures were intended in either situation.

But one could argue that the bug is simply the LDAP application software ignoring the local (non-LDAP) errors coming from ldap_start_tls_s(). In this case, the following trivial patch would address the issue.

diff --git a/clients/tools/common.c b/clients/tools/common.c index 7f758cb..089dd9b 100644 --- a/clients/tools/common.c +++ b/clients/tools/common.c @@ -1367,7 +1367,7 @@ dnssrv_free:; ldap_get_option( ld, LDAP_OPT_DIAGNOSTIC_MESSAGE, (void*)&msg); tool_perror( "ldap_start_tls", rc, NULL, NULL, msg, NULL ); ldap_memfree(msg);

•                       if ( use_tls > 1 ) {
  

•                     if ( use_tls > 1 || rc < 0) {
                                    tool_exit( ld, EXIT_FAILURE );
                            }
                    }
  
  

However, it might be better to do something at a lower level to ensure that all subsequent attempts to send LDAP PDUs over the wire after a TLS Alert fail.

I hereby place the above patch into the public domain.