This is a multi-part message in MIME format. --------------020600000809090503050207 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Riight - I see what you mean now. I mis-read the debugging messages as meaning it had reconnected without TLS. Retesting with a sniffer shows otherwise. So "-Z" works as I had hoped - excellent Thanks! Jason On 19/09/11 15:22, Kurt Zeilenga wrote: > > On Sep 18, 2011, at 5:41 PM, [email protected] wrote: > > > Full_Name: Jason Haar > > Version: 2.4.21 > > OS: Fedora > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (222.154.246.214) > > > > > > As you know, LDAP passwords are sent in cleartext unless TLS or SASL > are used. > > Depending on TLS cipher suites and SASL mechnanism choice, of course. > > And you shouldn't be using a cleartext mechanism unless you've first > authenticated the server. > > > > > However, "ldapsearch -Z" will fall-back onto cleartext if any form > of TLS error > > occurs, even the non-fatal "TLS: hostname does not match CN in peer > certificate" > > error. > > Actually, ldapsearch(1) does not fall back into cleartext in this > case. The OpenLDAP library, and most servers, wisely don't support > stop TLS. > > What ldapsearch(1) does is, if told to check certs (the default) and > they are bad, is to terminate the session and exit. > > > > i.e. TLS is attempted, the hostname doesn't match, so ldapsearch > tries again not > > using TLS! > > No it doesn't. > > > > > This seems wasteful to me. It is still *more secure* to continue the > encrypted > > TLS session than to fallback onto cleartext. > > No, it's not. If you continued to use TLS, there is no server > authentication. Use of cleartext mechanism to an unauthenticated > server is quite insecure. > > Now it might seem that if one said use simple bind w/ password and -Z, > that it would be reasonable to assume the user didn't care about > server authentication (or data integrity/confidential). But -Z is > designed less for use with simple bind w/ password but with SASL > mechanisms. > > Now, if you really want to do that, just tell ldapsearch(1) not to do > cert checks. > > > > Web browsers are a good example of > > this: if you connect to a self-signed https site, you can choose to > continue - > > as untrusted https is still secured against other attackers. > > And some browsers are stupid enough to do basic authentication without > first authenticating the server. > > > > If a user wants to guarantee the trustworthiness of their ldapsearch > session, > > they can use "-ZZ" to achieve that - but I can't see any reason to > stop people > > using "-Z" if they want to? > > Nothing stops those who don't want cert checks from disabling them. > > > (I'm using ldapsearch to dump Active Directory LDAP data via the DNS > round-robin > > entry for the domain name: as such the LDAP host *never* matches the > hostname > > DNS round-robin gives back - and I don't care - I just don't want > the network > > group sniffing my password ;-) > > Then you likely should be doing -ZZ (because you care about > eavesdropping) while disabling the cert checks (because you seem to > not care that you might be sending your password to a man-in-the-middle). > > -- Kurt > -- Cheers Jason Haar Information Security Manager, Trimble Navigation Ltd. Phone: +1 408 481 8171 PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1 --------------020600000809090503050207 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> <font face="Liberation Sans">Riight - I see what you mean now. I mis-read the debugging messages as meaning it had reconnected without TLS. Retesting with a sniffer shows otherwise.<br> <br> So "-Z" works as I had hoped - excellent<br> <br> Thanks!<br> <br> Jason<br> </font><br> On 19/09/11 15:22, Kurt Zeilenga wrote: <blockquote cite="mid:[email protected]" type="cite"> <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> <meta name="Generator" content="MS Exchange Server version 6.5.7654.12"> <title>Re: (ITS#7045) "ldapsearch -Z" should continue using TLS one cert mis-match</title> <!-- Converted from text/plain format --> <br> <p><font size="2">On Sep 18, 2011, at 5:41 PM, <a class="moz-txt-link-abbreviated" href="mailto:[email protected]";>[email protected]</a> wrote:<br> <br> > Full_Name: Jason Haar<br> > Version: 2.4.21<br> > OS: Fedora<br> > URL: <a moz-do-not-send="true" href="ftp://ftp.openldap.org/incoming/";>ftp://ftp.openldap.org/incoming/</a><br> > Submission from: (NULL) (222.154.246.214)<br> ><br> ><br> > As you know, LDAP passwords are sent in cleartext unless TLS or SASL are used.<br> <br> Depending on TLS cipher suites and SASL mechnanism choice, of course.<br> <br> And you shouldn't be using a cleartext mechanism unless you've first authenticated the server.<br> <br> ><br> > However, "ldapsearch -Z" will fall-back onto cleartext if any form of TLS error<br> > occurs, even the non-fatal "TLS: hostname does not match CN in peer certificate"<br> > error.<br> <br> Actually, ldapsearch(1) does not fall back into cleartext in this case. The OpenLDAP library, and most servers, wisely don't support stop TLS.<br> <br> What ldapsearch(1) does is, if told to check certs (the default) and they are bad, is to terminate the session and exit.<br> ><br> > i.e. TLS is attempted, the hostname doesn't match, so ldapsearch tries again not<br> > using TLS!<br> <br> No it doesn't.<br> <br> ><br> > This seems wasteful to me. It is still *more secure* to continue the encrypted<br> > TLS session than to fallback onto cleartext.<br> <br> No, it's not. If you continued to use TLS, there is no server authentication. Use of cleartext mechanism to an unauthenticated server is quite insecure.<br> <br> Now it might seem that if one said use simple bind w/ password and -Z, that it would be reasonable to assume the user didn't care about server authentication (or data integrity/confidential). But -Z is designed less for use with simple bind w/ password but with SASL mechanisms.<br> <br> Now, if you really want to do that, just tell ldapsearch(1) not to do cert checks.<br> <br> <br> > Web browsers are a good example of<br> > this: if you connect to a self-signed https site, you can choose to continue -<br> > as untrusted https is still secured against other attackers.<br> <br> And some browsers are stupid enough to do basic authentication without first authenticating the server.<br> ><br> > If a user wants to guarantee the trustworthiness of their ldapsearch session,<br> > they can use "-ZZ" to achieve that - but I can't see any reason to stop people<br> > using "-Z" if they want to?<br> <br> Nothing stops those who don't want cert checks from disabling them.<br> <br> > (I'm using ldapsearch to dump Active Directory LDAP data via the DNS round-robin<br> > entry for the domain name: as such the LDAP host *never* matches the hostname<br> > DNS round-robin gives back - and I don't care - I just don't want the network<br> > group sniffing my password ;-)<br> <br> Then you likely should be doing -ZZ (because you care about eavesdropping) while disabling the cert checks (because you seem to not care that you might be sending your password to a man-in-the-middle).<br> <br> -- Kurt<br> </font> </p> </blockquote> <br> <pre class="moz-signature" cols="72">-- Cheers Jason Haar Information Security Manager, Trimble Navigation Ltd. Phone: +1 408 481 8171 PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1 </pre> </body> </html> --------------020600000809090503050207--
