directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefan Seelmann (JIRA)" <>
Subject [jira] [Commented] (DIRAPI-289) The startTLS implementation does not check the server's identity
Date Sun, 15 Jan 2017 19:55:26 GMT


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