Bogus CN check in ldap_pvt_tls_start (ITS#1422)

[dom@idealx.com]

Full_Name: Dominique Quatravaux
Version: 2.0.11
OS: Linux RedHat 7.2
URL: 
Submission from: (NULL) (213.41.87.82)


The code of ldap_pvt_tls_start in libraries/libldap/tls.c checks that the
certificate displayed by the LDAP server has a CommonName (CN) field, and that
it 
is the same as the hostname that the client is trying to reach.

This behaviour is a non-standard Netscapism, according to RFCs 2459 and 2246:
  * RFC2246 does not specify any condition whereby a client should reject the
    server's certificate. This does not mean that there shouln't be any
    (since we do want to prevent man-in-the-middle attacks), but it means
    that the Netscape strategy is not the One True;
  * RFC2459 specifies that valid X.509 certificates can omit the DN altogether,
    and base the identification on the SubjectAltName only (section 4.2.1.7).
    This definitely is incompatible with the 2.0.8 OpenLDAP implementation.

To the best of my knowledge, identification of the CN part of the DN with a
hostname
is not standardized in any RFC. This is quite sound, since that would mean that
there can be at most one TLS server per DNS host (or at least that they should
share
the same certificate and private key). Not even speaking of multi-homed hosts
etc.

It breaks our code (http://idx-pki.idealx.org), that successfully uses 2.0.7.

Possible fixes, by decreasing order of difficulty and usefulness:
 * enable policy-bound checking of the peer's certificate (e.g. Keynote,
RFC2704)
 * allow a command-line switch to specify the expected peer's DN, and omit the
   test altogether if the switch is not present
 * allow the validation to occur with the SubjectAltName first
 * wrap the current code with a disable switch