SSLV3_ALERT_HANDSHAKE_FAILURE after upgrade from 2.31.0 to 2.32.2 #6715
Comments
|
This is running on databricks using python 3.10.12. |
|
@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.contextThoughts? 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 |
|
We have a different error, but probably the same issue. We inject a Anyway, thanks for the quick response. |
|
You will need to fix your code but right now it's not easily doable |
|
when do you expect releasing v2.32.3 which is suggested at #6716? |
|
@DanSIntel See the conversation in the MR: #6716 (review) |
|
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. |
|
@achapkowski I don't see trust store being used there or any kind of traceback |
|
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]> |
|
It recursively occurs here. full stack attached: |
|
Dug in a bit more: The above works on windows Below will fails on windows. Works on Mac/Linux |
|
I posted a response to the recursion issue in #6716 (comment). This is already known behavior that was reported to be broken in arcgis previously due to misuse of truststore (Esri/arcgis-python-api#1698). It will need to be fixed there. That's unrelated to the topic of this issue. For the minimal repro, you're producing this because your repro is also misusing truststore in the same way as You can swap the order of your imports and the above repro works fine on Windows: |
|
I had a similar issue. Try setting the |
|
We used pip-system-certs to trust the os bundle which has custom CAs in. I dont fully understand why but since 2.32.0 we get what I think is the same issue. Someone has raised an issue over at gitab https://gitlab.com/alelec/pip-system-certs/-/issues/27 |
|
#6721 is staged for release on Tuesday. We're going to hold releasing over the weekend to avoid any unnecessary pain for ops teams and will release after the holiday in the US on Monday. You can follow along for the merge of that PR to track the release time. |
|
For the adapter issue with 2.32.x do developers need to modify their logic? Is that documented anywhere if so? Also thank you for the quick fix! |
|
@achapkowski If you're using the |
|
Alright, 2.32.3 is out. Thanks everyone for your patience, please let us know if you're still hitting this failure case after upgrading. |
With 2.32.0-2.32.2 I've been seeing the same issue when using requests_pkcs12; now with 2.32.3, the issue did unfortunately not disappear but rather move to I've opened an issue with requests_pkcs12, but since you specifically asked to point out problems where things do not behave like in 2.31.0... |
|
We also use requests_pkcs12 and I can confirm that 2.32.3 doesn't work with it. Stack trace I saw:
|
…: self-signed certificate in certificate chain" error `requests` versions 2.32.0 to 2.32.3 (included) are affected by a bug breaking the ability to specify custom SSLContexts in sub-classes of HTTPAdapter (psf/requests#6715) and another breaking the ability to load certificates with HTTPAdapters (psf/requests#6730) We skip those versions (and hope that 2.32.4 will provide a fix for psf/requests#6730) Cf #706
|
I am seeing a similar behaviour with Here is my code: import ssl
import requests
from requests.adapters import HTTPAdapter
class SSLAdapter(HTTPAdapter):
"""An HTTPAdapter that uses an arbitrary SSL context."""
def __init__(self, ssl_context: ssl.SSLContext = None, **kwargs):
"""Initialize the SSLAdapter."""
super().__init__(**kwargs)
self.ssl_context = ssl_context
def build_connection_pool_key_attributes(
self,
request: requests.PreparedRequest,
verify: bool | str,
cert: str | tuple[str, str] | None = None,
) -> tuple[dict, dict]:
host_params, ssl_params = super().build_connection_pool_key_attributes(
request, verify, cert
)
if verify is True and self.ssl_context:
ssl_params["ssl_context"] = self.ssl_context
return host_params, ssl_params
if __name__ == "__main__":
# Create a custom SSL context
ssl_context = ssl._create_unverified_context()
ssl_context.set_ciphers("DEFAULT@SECLEVEL=2") # Adjusting the security level to support 2048 bit keys
# Example API call setup
username = "<admin>"
password = "<password>"
protocol = "https"
api_url = f"{protocol}://<host>/"
action = "<action>"
headers = {"Content-Type": "application/json"}
# Create a session with the SSLAdapter
session = requests.Session()
session.auth = (username, password)
session.mount(f"{protocol}://", SSLAdapter(ssl_context = ssl_context))
try:
response = session.get(api_url + action, timeout=15, headers=headers)
response.raise_for_status() # Raise an exception for HTTP errors
print("Response:", response.json())
except requests.exceptions.RequestException as e:
print(f"An error occurred: {e}")which results in this error: What am I doing wrong? Shouldn't |
After upgrading to requests 2.32.* our custom SSL adapter doesn't seem to working anymore. This is how it looks like
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:
The text was updated successfully, but these errors were encountered: