directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Emmanuel Lecharny (JIRA)" <>
Subject [jira] [Created] (DIRAPI-289) The startTLS implementation does not check the server's identity
Date Wed, 11 Jan 2017 23:57:16 GMT
Emmanuel Lecharny created DIRAPI-289:

             Summary: The startTLS implementation does not check the server's identity
                 Key: DIRAPI-289
             Project: Directory Client API
          Issue Type: Bug
    Affects Versions: 1.0.0-RC2
            Reporter: Emmanuel Lecharny
             Fix For: 1.0.0-RC3

The {{startTLS}} RFC ( specifies that upon reception of
the response from the server, the client should verify the server's identity :

3.6.  Server Identity Check

   The client MUST check its understanding of the server's hostname
   against the server's identity as presented in the server's
   Certificate message, in order to prevent man-in-the-middle attacks.

   Matching is performed according to these rules:

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

   - If a subjectAltName extension of type dNSName is present in the
     certificate, it SHOULD be used as the source of the server's

   - Matching is case-insensitive.

   - The "*" wildcard character is allowed.  If present, it applies only
     to the left-most name component.

   E.g. * would match,, etc. but not  If more than one identity of a given type is present in the
   certificate (e.g. more than one dNSName name), a match in any one of
   the set is considered acceptable.

   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.

   Beyond the server identity checks described in this section, clients
   SHOULD be prepared to do further checking to ensure that the server
   is authorized to provide the service it is observed to provide. The
   client MAY need to make use of local policy information.

We don't actually do any such check.

This message was sent by Atlassian JIRA

View raw message