session.http: fix custom SSLContext + verify=False #6205
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Resolves #6204
Really not sure if this is the right approach to solve this. This might just be a bug in
urllib3.When
--http-no-ssl-verifyis set,verifyis set toFalseon theHTTPSession(requests.Session). This leads tocert_reqs=ssl.CERT_NONEbeing set on theHTTPSConnectionPool. Eventually,urllib3will make the TLS connection and verify it. Nothing unusual so far.However, when the user has also set
--http-disable-dh, we mount a customHTTPAdapteron thehttps://scheme, which includes a customSSLContextwhere the Diffie-Hellman key exchange is disabled. ThisSSLContexthas all default values set otherwise. It will of course also be passed to theHTTPSConnectionPooland taken into account while validating the TLS connection.The issue here is that
urllib3does the following:https://github.com/urllib3/urllib3/blob/2.2.3/src/urllib3/connection.py#L860-L871
It tries to set the context's
verify_modeattribute again, based on thecert_reqsparameter which was set on theHTTPSConnectionPoolviaverify=False. This however raises aValueError, because our customSSLContextfrom our customHTTPAdapteris being used, where the default values are set, includingcheck_hostname=True.So when
check_hostname is Trueandverify_modeis attempted to be set tossl.CERT_NONE, this won't work.Hence the
HTTPAdapter.send()override of this PR, which alters the attributes of theSSLContextbased on theverifyvalue before sending the HTTPS request.master
PR