Menu Search




Affected components

Qpid Proton

Affected versions

0.8 through 0.13.0 inclusive

Fixed versions

0.13.1 and later


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.


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.


PROTON-1228 and PROTON-1233