SSLV3_ALERT_HANDSHAKE_FAILURE after upgrade from 2.31.0 to 2.32.2

[luisvicenteatprima]

After upgrading to requests 2.32.* our custom SSL adapter doesn't seem to working anymore. This is how it looks like

class CustomSSLAdapter(HTTPAdapter):
    def __init__(self):
        self.context = ssl.create_default_context()

        certfile = ...
        keyfile = ...
        password = ...
        self.context.load_cert_chain(certfile=certfile, keyfile=keyfile, password=password)
        
        super().__init__()

    def init_poolmanager(self, *args, **kwargs):
        kwargs['ssl_context'] = self.context
        return super().init_poolmanager(*args, **kwargs)

We have tried to mount this only for the target url but also for "http://". The code was working find with version 2.31.0.

Expected Result

The adapter should still work.

Actual Result

We got the following error:

SSLError: HTTPSConnectionPool(host=..., port=543): Max retries exceeded with url: ... (Caused by SSLError(SSLError(1, '[SSL: SSLV3_ALERT_HANDSHAKE_FAILURE] sslv3 alert handshake failure (_ssl.c:1007)')))

[luisvicenteatprima]

This is running on databricks using python 3.10.12.

[sigmavirus24]

@nateprewitt this is a different side-effect of #6655. I think to enable this particular use case we need to expose a way for sub-classes to muck with the pool kwargs, something like

class HTTPAdapter(BaseAdapter):
    def build_pool_kwargs(self, request, verify, cert=None):
        return _urllib3_request_context(request, verify, cert)

That way a subclass like this could do something like:

class CustomSSLAdapter(HTTPAdapter):
    def build_pool_kwargs(self, request, verify, cert=None):
        params, kwargs = super().build_pool_kwargs(request, verify, cert)
        params["ssl_context"] = self.context

Thoughts? I'm not particularly fond of this but it seems like the least intrusive way to preserve the fix for the CVE while giving people the ability to use custom SSLContexts the way they already were

[Marco-Kaulea]

We have a different error, but probably the same issue. We inject a ssl_context with a custom cipher selection. If there is a more "correct" way to do this I can also update our code, but a fix in the library would be appreciated.

Anyway, thanks for the quick response.

[sigmavirus24]

You will need to fix your code but right now it's not easily doable

[DanSIntel]

when do you expect releasing v2.32.3 which is suggested at #6716?

[Marco-Kaulea]

@DanSIntel See the conversation in the MR: #6716 (review)

[achapkowski]

On requests 2.32.x with truststore we are seeing a maximum recursion error with verify=True on windows Jupyter labs and jupyter notebook environments.

import requests
with requests.Session() as session:
   
     print(session.get("https://www.arcgis.com/sharing/rest/portals/self?f=json").text)

[sigmavirus24]

@achapkowski I don't see trust store being used there or any kind of traceback

[sigmavirus24]

I also can't reproduce your claim @achapkowski but I don't have windows available:

>>> import truststore; truststore.inject_into_ssl()
>>> import requests
>>> requests.get('https://google.com')
<Response [200]>
>>> requests.get('https://www.arcgis.com/sharing/rest/portals/self?f=json')
<Response [200]>