1593774 - HTTPS via SOCKS proxy (“ssh -D”) no longer works

Status: RESOLVED DUPLICATE of bug 1593394

(Core :: Networking, defect)

Description

[Jan Moesen]

When trying to open an HTTPS URL (e.g. https://www.example.com/) via a SOCKS proxy set up with “ssh -D …”, the page simply keeps on loading and the CPU usage climbs to 100%. I have been using this method for years and it seems to have stopped working on 2019-11-02. See below for mozregression.

There is no log message in the Browser Console. When I use MOZ_LOG=timestamp,sync,nsHttp:5,nsSocketTransport:5,nsHostResolver:5, this keeps on showing up on stderr in a seemingly endless loop while the CPU usage spikes:

2019-11-04 17:20:14.135129 UTC - [Parent 33568: Socket Thread]: E/nsSocketTransport nsSocketTransport::OnSocketReady [this=0x1884a3000 outFlags=2]
2019-11-04 17:20:14.135133 UTC - [Parent 33568: Socket Thread]: D/nsSocketTransport nsSocketOutputStream::OnSocketReady [this=0x1884a32c8 cond=0]
2019-11-04 17:20:14.135137 UTC - [Parent 33568: Socket Thread]: V/nsHttp nsHttpConnection::OnSocketWritable [this=0x18be94c00] host=www.example.com
2019-11-04 17:20:14.135141 UTC - [Parent 33568: Socket Thread]: V/nsHttp nsHttpConnection::GetSecurityInfo trans=0x1884a3800 tlsfilter=0x0 socket=0x1884a3018
2019-11-04 17:20:14.135146 UTC - [Parent 33568: Socket Thread]: E/nsHttp nsHttpTransaction::OnSocketStatus [this=0x1884a3800 status=804b000c progress=0]
2019-11-04 17:20:14.135152 UTC - [Parent 33568: Socket Thread]: V/nsHttp nsHttpConnection::OnSocketWritable 0x18be94c00 ReadSegments returned [rv=0 read=0 sock-cond=80470007 again=1]
2019-11-04 17:20:14.135452 UTC - [Parent 33568: Socket Thread]: D/nsSocketTransport nsSocketOutputStream::AsyncWait [this=0x1884a32c8]
2019-11-04 17:20:14.135462 UTC - [Parent 33568: Socket Thread]: D/nsSocketTransport STS poll iter
2019-11-04 17:20:14.135467 UTC - [Parent 33568: Socket Thread]: D/nsSocketTransport   active [0] { handler=0x1884a3000 condition=0 pollflags=7 }
2019-11-04 17:20:14.135470 UTC - [Parent 33568: Socket Thread]: D/nsSocketTransport SocketContext::EnsureTimeout socket=0x1884a3000
2019-11-04 17:20:14.135473 UTC - [Parent 33568: Socket Thread]: D/nsSocketTransport   engaging
2019-11-04 17:20:14.135476 UTC - [Parent 33568: Socket Thread]: D/nsSocketTransport   calling PR_Poll [active=1 idle=0]
2019-11-04 17:20:14.135480 UTC - [Parent 33568: Socket Thread]: D/nsSocketTransport SocketContext::TimeoutIn socket=0x1884a3000, timeout=65535s
2019-11-04 17:20:14.135484 UTC - [Parent 33568: Socket Thread]: D/nsSocketTransport   not engaged
2019-11-04 17:20:14.135487 UTC - [Parent 33568: Socket Thread]: D/nsSocketTransport poll timeout: none
2019-11-04 17:20:14.135491 UTC - [Parent 33568: Socket Thread]: D/nsSocketTransport     timeout = -1 milliseconds
2019-11-04 17:20:14.135537 UTC - [Parent 33568: Socket Thread]: D/nsSocketTransport     ...returned after 0 milliseconds
2019-11-04 17:20:14.135541 UTC - [Parent 33568: Socket Thread]: D/nsSocketTransport SocketContext::DisengageTimeout socket=0x1884a3000

mozregression-3.0.1 can’t pinpoint the exact regression:

 4:35.32 INFO: Narrowed nightly regression window from [2019-11-01, 2019-11-03] (2 days) to [2019-11-01, 2019-11-02] (1 days) (~0 steps left)
 4:35.32 INFO: Got as far as we can go bisecting nightlies...
 4:35.32 INFO: Last good revision: 518df4329a20f76b3bffd5f6201b007fdebc274f (2019-11-01)
 4:35.32 INFO: First bad revision: 8aa8ed80ea4325031cd613b5f85a3d694231c2ba (2019-11-02)
 4:35.32 INFO: Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=518df4329a20f76b3bffd5f6201b007fdebc274f&tochange=8aa8ed80ea4325031cd613b5f85a3d694231c2ba

 4:35.32 INFO: Switching bisection method to taskcluster
 4:35.32 INFO: Getting mozilla-central builds between 518df4329a20f76b3bffd5f6201b007fdebc274f and 8aa8ed80ea4325031cd613b5f85a3d694231c2ba
 4:39.04 INFO: No more inbound revisions, bisection finished.
 4:39.04 INFO: Last good revision: 518df4329a20f76b3bffd5f6201b007fdebc274f
 4:39.04 INFO: First bad revision: 8aa8ed80ea4325031cd613b5f85a3d694231c2ba
 4:39.04 INFO: Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=518df4329a20f76b3bffd5f6201b007fdebc274f&tochange=8aa8ed80ea4325031cd613b5f85a3d694231c2ba

 4:40.57 ERROR: The url u'https://hg.mozilla.org/integration/mozilla-inbound/json-pushes?changeset=8aa8ed80ea4325031cd613b5f85a3d694231c2ba&full=1' returned a 404 error. Please check the validity of the url.

From the pushlog, I am guessing it could be related to:
J.C. Jones — Bug 1592007 - land NSS fcdda17cdc36 UPGRADE_NSS_RELEASE, r=kjacobs

My user agent is “Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:72.0) Gecko/20100101 Firefox/72.0” (latest nightly on macOS Mojave).

Steps to reproduce:

• Create a SOCKS proxy (e.g. ssh -D 1234 [e-mail])
• Configure Firefox to use the manual proxy, SOCKS host localhost and port 1234
• Try to load http://www.example.com/ — this works
• Try to load https://www.example.com/ — this does not work

Comment 1

[Dragana Damjanovic [:dragana]]

This is probably dup of 1593394. Anyway the same problem.

Comment 2

[J.C. Jones [:jcj] (he/they)]

Ah, thanks Dragana. I couldn't find a reason why anything in that uplift could have caused this, but HTTP3 makes sense.

Comment 3

[Jan Moesen]

Sorry for the bad guess / red herring / false accusation, and thanks for pointing me to the correct bug. (And for this bugspam, but I wanted to apologize.)