cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Akitoshi Yoshida (JIRA)" <>
Subject [jira] [Commented] (CXF-6143) SSL/TLS hostname verification does not strictly follow HTTPS RFC2818
Date Tue, 20 Jan 2015 07:46:36 GMT


Akitoshi Yoshida commented on CXF-6143:

Hi Colm,
for the first part, while reading the page at, I saw the following

The copy on, linked below, is updated daily from's source code
management system. If you wish to make your app download an updated list periodically, please
use this URL and have your app download the list no more than once per day. (The list usually
changes a few times per month; more frequent downloading is pointless and hammers our servers.)

Fetching this file every time at each build and then including it statically in the jar file
seems to go against this advice?

regards, aki

> SSL/TLS hostname verification does not strictly follow HTTPS RFC2818
> --------------------------------------------------------------------
>                 Key: CXF-6143
>                 URL:
>             Project: CXF
>          Issue Type: Bug
>          Components: Transports
>    Affects Versions: 3.0.2
>            Reporter: Chad Loder
>            Assignee: Colm O hEigeartaigh
>              Labels: security,, ssl
>             Fix For: 3.0.4, 2.7.15
> The HTTPS specification [RFC 2818, section 3.1|]
> {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|;a=blob;f=rt/transports/http/src/main/java/org/apache/cxf/transport/https/]
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|]
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 (for future reference
and background on where implementations are going) and

This message was sent by Atlassian JIRA

View raw message