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

Reply via email to