I'm using python's requests library inside Google App Engine to send GET requests to a private server. When I make the request I get this warning:
requests/packages/urllib3/util/ssl_.py:79: InsecurePlatformWarning: A true SSLContext object is not available. This prevents urllib3 from configuring SSL appropriately and may cause certain SSL connections to fail. For more information, see https://urllib3.readthedocs.org/en/latest/security.html#insecureplatformwarning
According to the documentation that points to, I need to either upgrade past Python 2.7.x which GAE uses, or use pyopenssl. Since I don't believe that I can force GAE to use Python 2.7.9 I tried to use pyopenssl.
Following the instruction on the page, I've downloaded the three libraries suggested into the lib directory of my app and where I use requests I try to inject pyopenssl into urllib3 with:
import requests.packages.urllib3.contrib.pyopenssl
requests.packages.urllib3.contrib.pyopenssl.inject_into_urllib3()
This however, fails in the devserver and the production server with the following traceback:
Traceback (most recent call last):
File "/base/data/home/runtimes/python27/python27_lib/versions/1/google/appengine/runtime/wsgi.py", line 240, in Handle
handler = _config_handle.add_wsgi_middleware(self._LoadHandler())
File "/base/data/home/runtimes/python27/python27_lib/versions/1/google/appengine/runtime/wsgi.py", line 299, in _LoadHandler
handler, path, err = LoadObject(self._handler)
File "/base/data/home/runtimes/python27/python27_lib/versions/1/google/appengine/runtime/wsgi.py", line 85, in LoadObject
obj = __import__(path[0])
File "/base/data/home/apps/s~servicey1564/1.383321878696068897/main.py", line 24, in <module>
from API import setupautomatorAPI
File "/base/data/home/apps/s~servicey1564/1.383321878696068897/API.py", line 12, in <module>
from ServiceActivationTest import uploadSAT, getSATsForService
File "/base/data/home/apps/s~servicey1564/1.383321878696068897/ServiceActivationTest/__init__.py", line 3, in <module>
from requests.packages.urllib3.contrib import pyopenssl as pyopenssl
File "/base/data/home/apps/s~servicey1564/1.383321878696068897/lib/requests/packages/__init__.py", line 95, in load_module
raise ImportError("No module named '%s'" % (name,))
ImportError: No module named 'requests.packages.urllib3.contrib.pyopenssl'
This import statement works fine in the Python interpreter, and works if I take off the pyopenssl on the end. pyopenssl is also the first .py file besides __init__.py files in that path.
Am I doing something wrong here? Is there an easier way to fix the InsecurePlatformWarning?
UPDATE: After going to the sockets API page(Thanks shazow!) I found that part of my problem was that httplib was misbehaving because I lacked an environment variable. This didn't get rid of the warning, but my certificate is being accepted now!
(I'm not 100% sure this is what you mean, but this might be a more relevant answer to your question:)
Turns out there is a new behaviour that is a bug in urllib3 manifested by AppEngine changing their default modules available.
Traditionally, urllib3 tries to import ssl which would fail on old AppEngine, then it would fallback to plain httplib which is AppEngine's URLFetch behind the scenes. Now, looks like AppEngine added an ssl module as part of their sockets beta, which screwed up our fallback.
This bug is being investigated here: https://github.com/shazow/urllib3/issues/583
For the time being, you can manually override the default HTTPSConnection type that urllib3 uses to be the plain httplib one rather than the PyOpenSSL one by doing something like this before making any pools:
from urllib3.connection import UnverifiedHTTPSConnection
from urllib3.connectionpool import HTTPSConnectionPool
# Override the default Connection class for the HTTPSConnectionPool.
HTTPSConnectionPool.ConnectionCls = UnverifiedHTTPSConnection
Now whenever urllib3 uses an HTTPSConnectionPool (which things like PoolManager allocate automatically), it will use UnverifiedHTTPSConnections which are equivalent to the URL Fetch service on AppEngine.
Once issue #583 is fixed, you won't need to do this anymore.