[Date Prev][Date Next]
TLS Server Identity Check
- To: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
- Subject: TLS Server Identity Check
- From: Norbert Klasen <email@example.com>
- Date: Fri, 24 Nov 2000 17:42:37 +0100
- Cc: openldap-devel <openldap-devel@OpenLDAP.org>
- Organization: DFN Directory Services, ZDV Uni Tübingen
- References: <firstname.lastname@example.org> <email@example.com>
"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?
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