Emmanuel Lecharny created DIRAPI-289:
----------------------------------------
Summary: 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)
