Messaging APIs

Servers and tools

Resources

CVE-2016-4467

Severity

Affected components

Qpid Proton

Affected versions

0.8 through 0.13.0 inclusive

Fixed versions

0.13.1 and later

Description

Failure to verify that the server host name matches the certificate
host name 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 pn_ssl_t object.

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
authentication step.

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.

Resolution

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.