TLS Server Identity Check

[Norbert Klasen <klasen@zdv.uni-tuebingen.de>]

"Kurt D. Zeilenga" wrote:
> 
> I crossed by replies...  It was tls.c change I made a couple
> very minor changes to.  Also, I have yet to review the changes
> in terms of RFC 2830 compliance (which states exactly how
> server certs must be checked).

Good point. RFC2830 states that:
   - The client MUST use the server hostname it used to open the LDAP
     connection as the value to compare against the server name as
     expressed in the server's certificate.  The client MUST NOT use the
     server's canonical DNS name or any other derived form of name.

Currently I get the hostname from ldap_host_connected_to() which DOES
make an reverse lookup. ldap_host_connected_to() is also used in KBIND
and SASL to determine the remote hostname. Shouldn't Kerberos and SASL
also go by the initially specified hostname? 

And another point:
   If the hostname does not match the dNSName-based identity in the
   certificate per the above check, user-oriented clients SHOULD either
   notify the user (clients MAY give the user the opportunity to
   continue with the connection in any case) or terminate the connection
   and indicate that the server's identity is suspect. Automated clients
   SHOULD close the connection, returning and/or logging an error
   indicating that the server's identity is suspect.

If we want to give clients a chance to let users override, the server
identity check must be moved from ldap_pvt_tls_start(). But then what
about automated clients. How's this best accounted for in a library?

-- 
Norbert Klasen
DFN Directory Services                           tel: +49 7071 29 70335
ZDV, Universität Tübingen                        fax: +49 7071 29 5912
Wächterstr. 76, 72074 Tübingen              http://www.directory.dfn.de
Germany                             norbert.klasen@zdv.uni-tuebingen.de