directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Emmanuel Lecharny (JIRA)" <>
Subject [jira] [Resolved] (DIRAPI-289) The startTLS implementation does not check the server's identity
Date Sun, 15 Jan 2017 13:12:27 GMT


Emmanuel Lecharny resolved DIRAPI-289.
    Resolution: Invalid

This was a "oh my god we haven't implemented it properly" while reading the RFC and not checking
the code  moment...

Sorry for the noise. I should have closed the issue earlier.

> The startTLS implementation does not check the server's identity
> ----------------------------------------------------------------
>                 Key: DIRAPI-289
>                 URL:
>             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 :
> {noformat}
> 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
>      identity.
>    - 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.
> {noformat}
> We don't actually do any such check.

This message was sent by Atlassian JIRA

View raw message