+| CVE-ID | Severity | Affected versions | Fixed versions | Summary | +| ------ | -------- | ----------------- | -------------- | ------- | +| [CVE-2016-4467]({{site_url}}/cves/CVE-2016-4467.html) | Medium | 0.8 through 0.13.0 inclusive | 0.13.1 and later | Failure to verify that the server host name matches the certificate host name on Windows | +| [CVE-2016-2166]({{site_url}}/cves/CVE-2016-2166.html) | Moderate | 0.9 through 0.12.0 inclusive | 0.12.1 and later | Python bindings silently ignore request for amqps if SSL/TLS not supported | -## Proton - - - - - - - - - - - - - - - - - - - - - - - -

CVE-ID	Severity	Affected Versions	Fixed in Versions	Description
CVE-2016-4467	Medium	0.8 through 0.13.0 (inclusive)	0.13.1 and later	Failure to verify that the server host name matches the certificate host name on Windows - show more - - - 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. - - References: PROTON-1228 - and PROTON-1233. - -
CVE-2016-2166	Moderate	0.9 through 0.12.0 (inclusive)	0.12.1 and later	- Python bindings silently ignore request for amqps if SSL/TLS not supported. show more - - Versions Affected: Apache Qpid Proton python API starting - at 0.9 up to and including version 0.12.0. - Description: Messaging applications using the Proton - Python API to provision an SSL/TLS encrypted TCP connection - may actually instantiate a non-encrypted connection without - notice if SSL support is unavailable. This will result in - all messages being sent in the clear without the knowledge - of the user. This issue affects those applications - that use the Proton Reactor Python API to create SSL/TLS - connections. Specifically the proton.reactor.Connector, - proton.reactor.Container, and - proton.utils.BlockingConnection classes are vulnerable. - These classes can create an unencrypted connections if the - "amqps://" URL prefix is used. The issue only occurs - if the installed Proton libraries do not support SSL. This - would be the case if the libraries were built without SSL - support or the necessary SSL libraries are not present on - the system (e.g. OpenSSL in the case of *nix). To - check whether or not the Python API provides SSL support, - use the following console command: python -c "import - proton; print('%s' % 'SSL present' if proton.SSL.present() - else 'SSL NOT AVAILBLE')" In addition, the issue can - only occur if both ends of the connection connect without - SSL. This would be the case if the vulnerability is active - on both ends of the connection, or the non-affected endpoint - allows cleartext connections. - Resolution: Proton release 0.12.1 resolves this issue by - raising an SSLUnavailable exception when SSL is not - available and a SSL/TLS connection is requested via the - "amqps://" URL - prefix. A patch - is also available. - References: PROTON-1157 - Credit: This issue was discovered by M. Farrellee from Red Hat. - -

- -