[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: TLS behavior

On Mon, May 20, 2002 at 02:09:41PM -0700, David Margrave wrote:

> My understanding of client TLS support (i.e.  command line tools like
> ldapsearch, or apps that use libldap) is the following:
> 1) it enforces the requirement that the subject DN in the certificate
> contain the FQDN of the hostname you supplied,


> 2) if the FQDN does not match the cn in the subject DN, it will look in
> the subjectAltName extension for a match.  This is helpful for load
> balancers scenarios where the FQDN would not match the subject DN,


> 3) no CA certificate checking is done.

Not so. See the 'Client Authentication' section in my recent paper on
Security with LDAP:


(Last item on the page, available in HTML and PDF)

> Supposedly steps 1 and 2 are to guard against man-in-the-middle attacks,
> but I can't find any reference anywhere for how to configure a client with
> a local store of 'trusted root CA certificates'.  This means that a
> man-in-the-middle attack is still possible.  I have run 'strace' on
> ldapsearch and have not seen it trying to find trusted roots anywhere.

It will only do that if you configure it.

> Can anyone provide a bit of insight?  Is there any provision for
> certificate verification callbacks to override this default behavior.
> Also my understanding is that the practice of two ports for each app (one
> regular port and one SSL/TLS port) is being deprecated.  Does the openldap
> library only support the start-tls on port 389 now, or is SSL/TLS on port
> 636 still supported?

Both, but it is probably better to stick with port 389 and use TLS.

|                 From Andrew Findlay, Skills 1st Ltd                 |
| Consultant in large-scale systems, networks, and directory services |
|        Andrew.Findlay@skills-1st.co.uk       +44 1628 782565        |