In `LibcloudHTTPSConnection.connect()` there's a check for `self.verify`
and if it isn't set, it falls through to
`httplib.HTTPSConnection.connect()`; if verify is set, then it does
hostname verification.
However, there's a difference between Python 3.4 and Python 3.5 where
bypassing verification no longer works. The constructor for
`httplib.client.HTTPSConnection` differs from Python 3.4 and Python 3.5:
# Python 3.4
if context is None:
context = ssl._create_stdlib_context()
# Python 3.5
if context is None:
context = ssl._create_default_https_context()
It has the effect of ultimately changing whether or not the hostname is
checked.
>>> ssl._create_stdlib_context().check_hostname
False
>>> ssl._create_default_https_context().check_hostname
True
Here's a patch. It probably isn't the correct solution for other versions
of Python, and I'm unsure if Libcloud needs its own hostname verification
going forward since the standard SSL library provides it.
$ hg diff
diff -r 9d7d5f6222d0 libcloud/httplib_ssl.py
--- a/libcloud/httplib_ssl.py Thu Jul 07 17:15:29 2016 -0500
+++ b/libcloud/httplib_ssl.py Mon Jul 18 18:32:33 2016 +0000
@@ -224,6 +224,13 @@
Constructor
"""
self._setup_verify()
+ if not self.verify:
+ context = ssl.SSLContext (ssl.PROTOCOL_SSLv23)
+ context.options |= ssl.OP_NO_SSLv2
+ context.options |= ssl.OP_NO_SSLv3
+ context.check_hostname = False
+ kwargs['context'] = context
+
# Support for HTTP proxy
proxy_url_env = os.environ.get(HTTP_PROXY_ENV_VARIABLE_NAME, None)
proxy_url = kwargs.pop('proxy_url', proxy_url_env)
Cheers,
Chris