anon-ws-disable-stacked-tor considered useless

Support
1

I’m especially curious about the thing.
Let’s assume we have a not-Whonix, but Whonix-like configuration where 2 virtual machines have Tor proxy clients installed on both, and there is a Tor Browser in the one of. The browser still can be configured not to use Tor ever and behave just as secure non-anonymous browser, so, therefore, if we don’t want Tor-over-Tor scenario to accuse, we just change the browser proxy settings so they point to only one proxy client. Examples are:

network.proxy.socks;127.0.0.1
network.proxy.socks.port;9150 - to use a proxy client in the same VM.

network.proxy.socks;10.12.34.56
network.proxy.socks.port;9150 - to use a proxy client in the other VM.

Both cases will cause Tor Browser to connect only the one Tor client, thus initiating a normal 3-nodes paths and not giving Tor-over-Tor scenario a chance to appear.

Well, well. So, why the browser is configured to use socket file to understand proxying? That’s just useless. Why just don’t connect it directly to the gateway.ip.address:stream.isolation.port? I don’t ever wonder why such a wild “fix” is in usage. When I run Tor Browser through Burp Suite and that one thing prevents me from doing it while in common Debian Buster attached to Whonix Gateway it plays great only edited to follow the Burp HTTP intercepter before Tor network. It really pisses me off. And yes, I do know anonymous penetration testing talks are restricted on the forum. I don’t try to remain anonymous. I’m dealing with very nasty WAF that makes use of too advanced blocking technologies so I’m not able to enter the site again within the testing environment even after I terminated my browser. It’s important to use a lot of virtual machines which Qubes assists me with, but that Whonix architecture surprise pisses me all off.

2

Reliability, future-proofness and simplicity.

Reliability:
Using settings files to change socks proxy settings is not as reliable as keeping Tor Browser as unmodified as possible.

TOR_SOCKS_HOST, TOR_SOCKS_PORT regression

Above was the original reason for giving up on modifying Tor Browser settings. Keep modifications of Tor Browser as minimal as possible. Differences are documented here: Tor Browser Essentials

Some users reported to have lost settings when they upgraded Tor Browser. This then also could break connectivity. Happened in past.

SocksSocket is nowadays Tor Browser default. It is prudent for Whonix to stick with the defaults as much as possible. The smaller the difference, the less likely are any Tor Browser bugs introduced by Whonix.

Tor Browser connectivity was bumpy during the first year of Whonix’s existence but it’s stable for 6 years now. My development experiences of 7 years Whonix maintainance manifesting in various design choices.

future-proofness:
Tor Browser was ported from using TCP to be using SocksSocket. Tor Project once planned to remove TCP support from Tor Browser to make it more leak-proof. (Tor Project has the perspective of a regular host operating system, not Whonix.) Their idea was that Tor Browser should only be able to talk to a unix domain socket file (provided by Tor) with no capability of system default TCP / DNS.

Simplicity:
When Tor Browser changes things, these changes are reported to and blamed on Whonix. Here are some examples:

1 Like