cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chad Loder (JIRA)" <j...@apache.org>
Subject [jira] [Created] (CXF-6143) SSL/TLS hostname verification does not strictly follow HTTPS RFC2818
Date Tue, 09 Dec 2014 11:51:12 GMT
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)

Mime
View raw message