Chad Loder created CXF-6143:
-------------------------------
Summary: SSL/TLS hostname verification does not strictly follow
HTTPS RFC2818
Key: CXF-6143
URL: https://issues.apache.org/jira/browse/CXF-6143
Project: CXF
Issue Type: Bug
Components: Transports
Affects Versions: 3.0.2
Reporter: Chad Loder
The HTTPS specification [RFC 2818, section
3.1|http://tools.ietf.org/html/rfc2818#section-3.1] states:
{quote}
If a subjectAltName extension of type dNSName is present, that MUST
be used as the identity. Otherwise, the (most specific) Common Name
field in the Subject field of the certificate MUST be used. Although
the use of the Common Name is existing practice, it is deprecated and
Certification Authorities are encouraged to use the dNSName instead.
{quote}
The current
[CertificateHostnameVerifier|https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=blob;f=rt/transports/http/src/main/java/org/apache/cxf/transport/https/CertificateHostnameVerifier.java]
implementation in CXF does not follow this logic, even in STRICT mode.
Instead, it builds an array of both CNs and subjectAltNames and checks each of
them sequentially, in the order returned in the certificate.
The proper approach would be to build a list of subjectAltNames having type
dNSName. If the list is non-empty, matching should proceed against this list
ONLY - and validation should fail if no subjectAltName. Otherwise, only if the
subjectAltName list is empty, a list of CNs from the Subject field should be
built, and perhaps sorted from most- to least-specific. A match should then
proceed against this list, taking into account wildcards of course.
Likewise, the [HostnameVerifier implementation in
not-yet-commons-ssl|http://juliusdavies.ca/svn/viewvc.cgi/not-yet-commons-ssl/trunk/src/java/org/apache/commons/ssl/HostnameVerifier.java?revision=121&pathrev=172]
has the same issue. However, since not-yet-commons-ssl is a generic SSL/TLS
transport library, it should not be made to follow HTTPS application layer
rules for all TLS connections - instead a STRICT_HTTPS mode could be
implemented for this purpose.
For more information, see http://tools.ietf.org/search/rfc6125 (for future
reference and background on where implementations are going) and
http://tersesystems.com/2014/03/23/fixing-hostname-verification/
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
