[
https://issues.apache.org/jira/browse/CXF-6143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chad Loder updated CXF-6143:
----------------------------
Description:
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/
was:
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/
> 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
> 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)
