RE: TLS behavior

["Howard Chu" <hyc@highlandsun.com>]

> -----Original Message-----
> From: owner-openldap-software@OpenLDAP.org
> [mailto:owner-openldap-software@OpenLDAP.org]On Behalf Of David Margrave

> Hello,
>
> I'm interested in TLS support in openldap client apps and libraries.  I
> have been meaning look at this for some time, but only recently I finally
> downloaded and worked a bit with openldap 2.0.23.
>
> 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,

The DN in the server's certificate, right.
>
> 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,

Right.
>
> 3) no CA certificate checking is done.

Wrong. In order to validate a server certificate, the certification chain
must be validated up to some known/trusted CA. This is a feature of SSL and
X.509, not something particular to the LDAP library.
>
> 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.

See the TLS_CACERT option in the ldap.conf (or ~/.ldaprc).
>
> Can anyone provide a bit of insight?  Is there any provision for
> certificate verification callbacks to override this default behavior.

Yes and yes. The library establishes a default context with its own verify
callback. You can retrieve the context (using ldap_get_option(NULL,
LDAP_OPT_X_TLS_CTX, &ptr)) and then reset the callback as you wish. However,
since the SSL library is already performing certificate verification
correctly, there is no need to change the current 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 access methods are supported.

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support