This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author christian.heimes
Recipients christian.heimes
Date 2018-03-25.09:19:22
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1521969562.74.0.467229070634.issue33136@psf.upfronthosting.co.za>
In-reply-to
Content
Since 3.7, the ssl module uses X509_VERIFY_PARAM_set1_host() to put the burden of hostname matching on OpenSSL. More specific, it calls X509_VERIFY_PARAM_set1_host(param, server_hostname, 0). The namelen=0 parameter means that OpenSSL handles server_hostname as a NUL-terminated C string.

LibreSSL 2.7.0 added X509_VERIFY_PARAM_set1_host(), but took the implementation from BoringSSL instead of OpenSSL. The BoringSSL implementation doesn't support namelen=0. X509_VERIFY_PARAM_set1_host(param, server_hostname, 0) returns success but doesn't configure the SSL connection for hostname verification. As a result, LibreSSL 2.7.0 doesn't perform any hostname matching. All trusted certificates are accepted for just any arbitrary hostname. This misbehavior left Python 3.7 beta open to man-in-the-middle attack.

LibreSSL 2.7.1 has fixed the issue. To harden the ssl module against, I'm also changing our implementation to use strlen() instead of 0.


https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-8970
https://bugs.chromium.org/p/boringssl/issues/detail?id=30
https://bugs.chromium.org/p/chromium/issues/detail?id=824799 (restricted for now)
History
Date User Action Args
2018-03-25 09:19:22christian.heimessetrecipients: + christian.heimes
2018-03-25 09:19:22christian.heimessetmessageid: <1521969562.74.0.467229070634.issue33136@psf.upfronthosting.co.za>
2018-03-25 09:19:22christian.heimeslinkissue33136 messages
2018-03-25 09:19:22christian.heimescreate