[
https://issues.apache.org/jira/browse/DIRAPI-289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15823246#comment-15823246
]
Stefan Seelmann commented on DIRAPI-289:
----------------------------------------
But I think there is a big issue: When creating a LdapNetworkConnection it
creates a LdapConnectionConfig which configures by default the
NoVerificationTrustManager which doesn't check anything, neither the
certificate chain nor the server's hostname.
By default we should configure the default Java TrustManager which uses the JDK
cacerts file.
It makes sense to provide the NoVerificationTrustManager, but users should set
that explicitely if they know what they do. But using it by default is bad,
nobody expects that by default, we'll receive CVEs and bad rants.
BTW: in Studio DirectoryApiConnectionWrapper we override the
LdapConnectionConfig's trust manager with our own StudioTrustManager which
wraps the JDK's default TrustManager and asks the user what to do in case
verification fails.
> 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)
