GHSA-8988-9cw3-xx77: Pip/urllib3 vulnerability

Impact

urllib3 supports configuring TLS independently for an HTTPS proxy and the target server.

proxysslcontext, proxyasserthostname, and proxyassertfingerprint configure the TLS connection to the proxy. sslcontext and the other target-specific TLS parameters configure the connection to the target server.

In urllib3 versions 1.26.0 through 2.7.0, these configurations were not consistently separated. Depending on the proxy mode, urllib3 could:

1. Ignore proxysslcontext and use the target server's SSL context for the TLS connection to an HTTPS forwarding proxy. 2. Override the HTTPS proxy's certificate-verification policy with the target server's certificate-verification policy. 3. Apply target-specific SNI, hostname assertions, certificate fingerprint assertions, or TLS client credentials to the TLS connection to an HTTPS forwarding proxy.

In particular, configuring certreqs="CERTNONE" for a target server could overwrite the verifymode of the SSL context configured for the HTTPS proxy. This modification occurred in place and persisted on the context object, potentially disabling proxy certificate verification for later connections that reused the same context.

An attacker able to intercept the connection to an HTTPS proxy may be able to impersonate the proxy when the effective proxy TLS configuration disables certificate verification or otherwise accepts the attacker's certificate. This may occur, for example, when the target server's trust or identity policy is incorrectly applied to the proxy connection.

When HTTPS forwarding is enabled, an impersonated proxy can observe or modify forwarded requests and responses, potentially exposing credentials, authentication tokens, request bodies, response data, and other sensitive information.

A TLS client certificate intended for the target server may also be presented to the proxy or to an attacker impersonating it. This can disclose the client's identity and provide proof of possession of the corresponding private key. The private key itself is not transmitted during the TLS handshake.

In CONNECT tunneling mode, impersonating the HTTPS proxy does not by itself defeat the separate end-to-end TLS connection between the client and the target server.

Affected Usages

Code using urllib3 versions 1.26.0 through 2.7.0 may be affected in any of the following cases.

1. The target SSL context is used for an HTTPS forwarding proxy

HTTPS requests are forwarded through an HTTPS proxy with useforwardingforhttps=True, and proxysslcontext is configured for the proxy.

urllib3 may ignore proxysslcontext and use the target server's sslcontext for the proxy TLS handshake. The proxy may therefore be verified using the target server's trust and certificate policy instead of the policy explicitly configured for the proxy.

2. The target verification policy overrides the proxy policy

An HTTPS proxy is configured with proxysslcontext, while the target server uses a different certificate-verification policy.

urllib3 may apply the target server's certreqs value to the proxy SSL context. For example, setting certreqs="CERTNONE" for the target server may also disable certificate verification for the HTTPS proxy, even when proxysslcontext was configured to require verification.

This issue can affect the TLS connection to an HTTPS proxy in both forwarding and CONNECT tunneling configurations.

3. A mutated proxy SSL context is reused

The same SSL context is reused as proxysslcontext across multiple connections, and certificate verification is disabled for one target server.

urllib3 may modify the proxy SSL context's verifymode in place. Later connections that reuse the same context may therefore connect to the HTTPS proxy without certificate verification.

4. Target-specific TLS identity or credentials are applied to the proxy

HTTPS requests are forwarded through an HTTPS proxy with useforwardingforhttps=True, and target-specific SNI, hostname assertions, certificate fingerprint assertions, or TLS client credentials are configured.

urllib3 may apply these target-specific settings to the proxy TLS handshake. This may cause urllib3 to:

- send SNI intended for the target server to the proxy; - verify the proxy using a hostname or certificate fingerprint intended for the target server; or - present a TLS client certificate intended for the target server to the proxy.

Code connecting through a plain HTTP proxy does not establish a TLS connection to the proxy and is not affected by this issue.

Remediation

Upgrade to urllib3 2.8.0 or later.

urllib3 2.8.0 independently applies the explicitly configured proxysslcontext and proxy-specific certificate assertions to the HTTPS proxy connection. Target-specific SNI, certificate assertions, and TLS client certificate parameters are no longer applied to the HTTPS proxy handshake.

For backward compatibility, when an HTTPS proxy is used with useforwardingforhttps=True and proxysslcontext is not provided, urllib3 2.8.0 continues to use sslcontext for the TLS connection to the proxy. This configuration emits a FutureWarning. In urllib3 3.0, passing sslcontext with useforwardingforhttps=True for an HTTPS proxy will raise an error. Applications should use proxysslcontext to configure TLS for an HTTPS forwarding proxy.

The fixes were implemented in commits b6447295fff7b38fdffc67e0df9712d60cef3cc3 and 07408cec79d1856d81bb42c74a904a24fdb9e465.