Apache Qpid Proton Library Lets Remote Users Bypass Certificate Validation on Windows-Based Systems
SecurityTracker Alert ID: 1036316|
SecurityTracker URL: http://securitytracker.com/id/1036316
(Links to External Site)
Date: Jul 15 2016
Disclosure of system information, Disclosure of user information, Modification of system information, Modification of user information|
Fix Available: Yes Vendor Confirmed: Yes |
Version(s): 0.8 - 0.13.0|
A vulnerability was reported in Apache Qpid Proton Library. A remote user can bypass certificate validation on the target system.|
The Proton C client and C-based client bindings on Windows-based systems do not properly verify that the server host name matches the domain name in the certificate's Common Name (CN) or subjectAltName fields.
Applications that use the Proton C library for SSL/TLS authentication on Windows-based systems with the default SChannel-based security layer are affected.
A remote user can bypass certificate validation on the target system.|
The vendor has issued a fix (Qpid Proton 0.13.1).|
The vendor's advisory is available at:
Vendor URL: qpid.apache.org/ (Links to External Site)
|Underlying OS: Windows (Any)|
Source Message Contents
Subject: [oss-security] [SECURITY] CVE-2016-4467: Apache Qpid Proton: Failure to verify that the server host name matches the certificate host name on Windows|
Content-Type: text/plain; charset=UTF-8
Affected versions: 0.8 through 0.13.0 (inclusive)
Fixed in Versions: 0.13.1 and later
The Proton C client and C-based client bindings may fail to verify that the
server host name matches the domain name in the subject's Common Name (CN)
or subjectAltName field in X.509 certificates when running on Windows
Messaging applications using the Proton C library to provide SSL/TLS
authentication on Windows can falsely authenticate a server whose name does
not match the server name in the connection specifier. Proton C bindings
are affected to a greater or lesser degree depending on how they use the
underlying Proton C library.
In Proton C, this can only happen if PN_SSL_VERIFY_PEER_NAME has been
specified as the verification mode and pn_ssl_set_peer_hostname() has not
been called at all or has been called with a NULL value for a particular
In the Proton C++ binding, this will always happen unless the application
has separately specified a virtual_host name for an SSL/TLS connection.
In the Proton Python and Ruby bindings, this will only happen if the
application has separately specified a NULL virtual_host name for an
SSL/TLS connection after creating the connection but before the
This issue only occurs on Windows versions of Proton that use the default
SChannel-based security layer.
In any of the preceding cases, it is possible for a man-in-the-middle
attacker to spoof an SSL/TLS server if they had a certificate that was
valid for any of the application's Certificate Authorities.
Proton release 0.13.1 resolves this issue in the SChannel-based security
layer by obtaining a default non-NULL peer hostname from the associated
connection address when initialized and by always failing hostname
verification if PN_SSL_VERIFY_PEER_NAME has been specified along with a
NULL peer hostname. This resolution matches the associated behaviour of
the OpenSSL-based security layer.