[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: (ITS#7045) "ldapsearch -Z" should continue using TLS one cert mis-match
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, Jason_Haar@trimble.com 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:F5AC234D-558A-4BFE-A053-EDB0B082FC41@openldap.org"
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:Jason_Haar@trimble.com";>Jason_Haar@trimble.com</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--