[
https://issues.apache.org/jira/browse/CXF-6143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh reassigned CXF-6143:
----------------------------------------
Assignee: Colm O hEigeartaigh
> 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
> Assignee: Colm O hEigeartaigh
> Labels: security,, ssl
>
> 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 matches. 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)
