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

Re: TLS Server Identity Check

At 05:42 PM 11/24/00 +0100, Norbert Klasen wrote:
>"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? 

I believe the implementation of KBIND and SASL are correct for
KBIND and SASL.  RFC2830 only applies to TLS as used by LDAP.


>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?

There should be some callback which the caller can provide to
provide user feedback.  In lieu of such a callback (or callback
mechanism), the library should be viewed as an "automated" client.