(ITS#8675) tools continuing after ldap_start_tls_ returns non-LDAP error

[kurt@openldap.org]

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.

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.