When connecting to a destination over TLS through a TLS proxy (an "HTTPS proxy"), enabling p_use_ssl encrypts the client→proxy hop but does not authenticate the proxy's certificate. The proxy TLS socket is built with no SSLContext and no post-connection check, so it defaults to VERIFY_NONE. This makes the proxy hop MITM-able, which matters because the Proxy-Authorization (Basic) credential is written over that socket in the CONNECT request.
Setup
Either of the documented ways to enable a TLS proxy:
proxy = Net::HTTP.Proxy('proxy.example.com', 8080, 'user', 'pass', true) # 5th arg -> @proxy_use_ssl
http = proxy.new('login.example.com', 443)
http.use_ssl = true
# ...or Net::HTTP.new(addr, port, p_addr, p_port, p_user, p_pass, p_no_proxy, true)
http.get('/')What happens
In Net::HTTP#connect, when @proxy_use_ssl is set, the proxy socket is wrapped as:
proxy_sock = OpenSSL::SSL::SSLSocket.new(s) # no SSLContext passed
ssl_socket_connect(proxy_sock, @open_timeout)
# ... then CONNECT + "Proxy-Authorization: Basic <creds>" is written to proxy_sock
SSLSocket.new(s) with no context uses a default context (verify_mode effectively VERIFY_NONE), and there is no post_connection_check on proxy_sock— the only post_connection_check in connect targets @address (the destination). So:
- The destination cert is verified (via
@ssl_context + post_connection_check(@address)). ✅
- The proxy cert is neither verified nor hostname-checked. ❌
A MITM on the client→proxy path can therefore present any certificate, terminate the TLS, and read the Proxy-Authorization credential — the same credential exposure that enabling proxy TLS is meant to prevent.
Expected
The proxy TLS connection should verify the proxy certificate by default (use an SSLContext with VERIFY_PEER and run post_connection_check against the proxy host), consistent with how the destination connection is verified. At minimum there should be a way to supply verification settings (CA store, verify_mode, hostname) for the proxy connection distinct from the destination's.
Environment
- Ruby 4.0.5
- net-http 0.9.1
- Reproduced by reading
lib/net/http.rb#connect (the if @proxy_use_ssl branch) — the proxy SSLSocket is built without a context and gets no post_connection_check.
Related
When connecting to a destination over TLS through a TLS proxy (an "HTTPS proxy"), enabling p_use_ssl encrypts the client→proxy hop but does not authenticate the proxy's certificate. The proxy TLS socket is built with no SSLContext and no post-connection check, so it defaults to
VERIFY_NONE. This makes the proxy hop MITM-able, which matters because the Proxy-Authorization (Basic) credential is written over that socket in the CONNECT request.Setup
Either of the documented ways to enable a TLS proxy:
What happens
In Net::HTTP#connect, when @proxy_use_ssl is set, the proxy socket is wrapped as:
SSLSocket.new(s)with no context uses a default context (verify_modeeffectivelyVERIFY_NONE), and there is nopost_connection_checkonproxy_sock— the onlypost_connection_checkin connect targets@address(the destination). So:@ssl_context+post_connection_check(@address)). ✅A MITM on the client→proxy path can therefore present any certificate, terminate the TLS, and read the Proxy-Authorization credential — the same credential exposure that enabling proxy TLS is meant to prevent.
Expected
The proxy TLS connection should verify the proxy certificate by default (use an SSLContext with
VERIFY_PEERand runpost_connection_checkagainst the proxy host), consistent with how the destination connection is verified. At minimum there should be a way to supply verification settings (CA store, verify_mode, hostname) for the proxy connection distinct from the destination's.Environment
lib/net/http.rb#connect(theif @proxy_use_sslbranch) — the proxy SSLSocket is built without a context and gets nopost_connection_check.Related
Net::HTTP.new's proxy args). This net-http issue is about the flag existing but not verifying the proxy cert.