This is to avoid telling TB all the socks listener on Whonix-Gateway. Many. Not useful information.
- pattern: 'net/listeners/socks'
- pattern: '250-net/listeners/socks=".*"'
So the SocksPort hiding feature isn’t built-in. It’s also just an onion-grater profile. Even though the default one.
But maybe not important enough. If it confuses cwtch, then feel free to remove that (if that works) or replace with something more suitable. Or maybe the cwtch onion-grater profile could overrule that as required.
Also in case anyone doesn’t know yet, this might be useful to know…
Might be useful to look at the profile which onion-grater is actually going to use. See file:
Generally, we shouldn’t require applications to suite Whonix if that is avoidable. Ideally onion-grater is modified instead. This is because by default, applications are unaware of Whonix and talk to Tor’s
ControlPort. Whonix / Tails adding onion-grater in between as a proxy is another layer of complexity. But now if applications are adding their own logic to react different in case of anonymity distribution versus non-anonymity distribution, that makes his even more entangled.
#550 - cwtch overwrites custom torrc options with replies from controller - cwtch-ui - Open Privacy Gitea
Thanks for this information. Is there a standard way of discovering this this from Whonix?
Not from the Workstation and that is the objective.
Which information? About which Tor
SocksPorts can be discovered through Tor control protocol? If yes, then Whonix would be better off having an optional cwtch onion-grater profile to show any ports which cwtch would be interested in.
cwtch (or similar applications) could also share Tor Browser’s default IP 127.0.0.1 port 9150. (If these are cwtch’s defaults. I didn’t check.) This is because Tor Browser sets a socks user name anyhow. (A different socks user name per top level domain at time of writing afaik.) Based on Tor’s
IsolateSOCKSAuth feature. So sharing that port isn’t a big deal.
A feature which Tor friendly applications would be good would be to set their own socks user name to benefit from Tor’s
IsolateSOCKSAuth feature. Ideally contextually a different Tor socks user name. The context be for example could be “connection to server 1 versus connection to server 2”. Then even in theory if Tor socks user name setting feature was broken, Tor still stream isolate the traffic.
These are features that can be required without needing to mention Whonix. These are for the benefit of any user anywhere. Unrelated to Whonix. Often this motivates some upstreams more.
Another common issue of Tor friendly applications versus Whonix is the listen interface. Does their web server (such as in case of OnionShare) (or other server for chat) listen on 127.0.0.1? That cannot work. It needs to listen on all interfaces. (Technical nitpick: on Whonix-Workstation external interface.)
related wiki pages: