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.
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. > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
it's standard conformance issue.... The spec says that upon StartTLS 'success', both TLS communications is established on the octet following the Start TLS response (and the request)... and that once one starts TLS communications, one can never go back to LDAP without TLS. So if there's a TLS failure (whether as part of TLS nego or later), LDAP communications cannot be continued (without TLS). Only ignoring LDAP errors (rc > 0) ensures that if TLS negotiation fails, we don't attempt to send LDAP operations without TLS. -- Kurt
changed notes
has patch;openldap-scratch IPR ok
https://git.openldap.org/openldap/openldap/-/merge_requests/9
Commits: • 23af2c36 by Kurt Zeilenga at 2020-03-26T18:45:00+00:00 ITS#8675 - Fix tools to not continue on TLS error