HTTPS proxy connection (p_use_ssl/proxy_use_ssl) does not verify the proxy's certificate
Dieses Issue hat noch niemand übernommen.
- Vorherrschende Sprache
- Ruby
- Sterne
- 148
- Forks
- 95
- Ø Merge
- 10 Std. 54 Min.
- Gemergte PRs (30 T.)
- 4
Beschreibung
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(theif @proxy_use_sslbranch) — the proxy SSLSocket is built without a context and gets nopost_connection_check.
Related
- jnunemaker/httparty#839 tracks a separate, complementary gap: HTTParty can't even set p_use_ssl (it passes only 6 of
Net::HTTP.new's proxy args). This net-http issue is about the flag existing but not verifying the proxy cert.
Beitragsleitfaden
Für dieses Repository ist kein Beitragsleitfaden indexiert
Erste Schritte
- Lies das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreib ins Issue, dass du es übernimmst — das erspart doppelte Arbeit.
- Forke das Repository und arbeite in einem Branch.
- Öffne einen Pull Request, der die Issue-Nummer nennt.
Rechercherichtung
Beginne in lib/net/http.rb#connect, insbesondere im @proxy_use_ssl-Zweig, der den Proxy-SSLSocket erstellt. Vergleiche dessen Einrichtung mit der TLS-Verbindung zum Ziel und ermittle, wie die Verifizierung des Proxy-Zertifikats und die Hostnamenprüfung getrennt konfiguriert werden sollten. Als erledigt gilt dies, wenn das Proxy-Zertifikat standardmäßig verifiziert wird, bevor Proxy-Authorization gesendet wird, und alle erforderlichen Verifizierungseinstellungen abgedeckt sind.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Bewertung
- Tech-Stack
- ruby
- Bereich
- networking, security
- Issue-Typ
- Bug
- Schwierigkeit
- 4/5
- Geschätzter Aufwand
- 3-5 Tage
- Aktivitätsstatus
- Ruhig
- Klarheit
- Größtenteils klar
- Anfängerfreundlichkeit
- 55/100