[jira] [Resolved] (DIRAPI-289) The startTLS implementation does not check the server's identity

["Emmanuel Lecharny (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/DIRAPI-289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

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: https://issues.apache.org/jira/browse/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 (https://tools.ietf.org/html/rfc2830) 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. *.bar.com would match a.bar.com, b.bar.com, etc. but not
>    bar.com.  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
(v6.3.4#6332)