You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by "Stefan Seelmann (JIRA)" <ji...@apache.org> on 2017/01/15 11:00:29 UTC
[jira] [Commented] (DIRAPI-289) The startTLS implementation does
not check the server's identity
[ https://issues.apache.org/jira/browse/DIRAPI-289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15823104#comment-15823104 ]
Stefan Seelmann commented on DIRAPI-289:
----------------------------------------
We use a "NoVerificationTrustManager" by default, right?
> 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)