At what range?
SocksPort default is using 9150-9189 and HTTPTunnelPort range 9190-9229.
So socksport range would have to jump the httptunnel port and I think this is bad for documentation and understanding, it is better if ports of the same protocol are on the same range instead of on different ranges.
Is it viable to change socksport to use all 9150-9349 range and httptunnelport 9350-9500?
Big range to think about the futured.
Could even be 300 ports of range, but will wait for a reply, what is the range you think whonix should use for socksport and httptunnelport.
Ah. You mean default prepared Tor ports? I didn’t have this in mind. On the contrary, I was wondering if Whonix already prepared too many SocksPorts / HTTPTunnelPorts by default. Could you test please if lowering the amount of these, would lower the amount of RAM used? If RAM use increases, then we should be careful. OnionTrafficOnly doesn’t seem to be requested enough (never before) to warrant increased RAM requirements.
Instead I was wondering to review /usr/share/tor/tor-service-defaults-torrc.anondist for applications that exclusivly use onions such as maybe OnionShare but now after looking there, OnionShare doesn’t have a dedicated prepared SocksPort in that file anyhow (probably doesn’t need one anyhow).
Yes, I can test this, I am thinking of testing how much the Gateway is using of memory for tor and how much in total, and compare that to a Gateway with almost not Socks and HTTPTunnels ports configured. But will need to have a well defined method to attest this, such as how many clients, how many requests and traffic requested.
Ok, I just noticed OnionTrafficOnly recently acctually, don’t know at which tor version it was included but just noted that on the man page yesterday.
Only for OnionShare then no, but some good defaults for onion applications only might be good.
I was thinking of:
SocksPort X IsolateDestPort
SocksPort X IsolateDestAddr
SocksPort X IsolateDestAddr IsolateDestPort
SocksPort X IsolateDestAddr IsolateDestPort OnionTrafficOnly
I think SocksPort X IsolateDestPort is more useful for single Workstations, because they may speak different protocols, such as a user using ssh, http, irc, on the same workstation. But it does not make much difference if you isolate the protocol per Workstation, because then they already have a different client addr and isolation is made by IsolateClientAddr.
But if we consider the majority of Whonix users probably only use one Workstation then yes, IsolateDestPort makes a huge difference for them.
Checked now, sdwdate, agreed, enforcing onion only by the socks port flag as a “firewall” for non onion traffic.
I also think it is a mean to enforce tor browser for onion only, but this would be for experts, are third party requests of site wouldn’t load at all.
But as we are on this topic, it took some time for me to find these default ports, found them using anon-verify, but it is not documented under the stream isolation page Stream Isolation
maybe it should be documented? I think it is important to explain why which isolation flag was chosen.
On Whonix-Gateway ™ there are already a lot custom socks ports prepared for use with custom installed applications
But maybe too much hidden in a long chapter. Perhaps moving that content to a dedicated chapter and/or moving it around to make that page easier to read. That stream isolation page is probably non-ideal usability wise anyhow and help welcome.
Sep 26 19:03:59 host tor: Sep 26 19:03:59.435 [notice] You configured a non-loopback address ‘10.137.0.14:9101’ for SocksPort. This allows everybody on your local network to use your machine as a proxy. Make sure this is what you wanted.
Sep 26 19:03:59 host tor: Sep 26 19:03:59.435 [notice] You configured a non-loopback address ‘10.137.0.14:9102’ for SocksPort. This allows everybody on your local network to use your machine as a proxy. Make sure this is what you wanted.
Sep 26 19:03:59 host tor: Sep 26 19:03:59.435 [notice] You configured a non-loopback address ‘10.137.0.14:9103’ for SocksPort. This allows everybody on your local network to use your machine as a proxy. Make sure this is what you wanted.
Sep 26 19:03:59 host tor: Sep 26 19:03:59.435 [notice] Opening Socks listener on 127.0.0.1:9101
Sep 26 19:03:59 host tor: Sep 26 19:03:59.436 [notice] Opened Socks listener connection (ready) on 127.0.0.1:9101
Sep 26 19:03:59 host tor: Sep 26 19:03:59.436 [notice] Opening Socks listener on 127.0.0.1:9102
Sep 26 19:03:59 host tor: Sep 26 19:03:59.436 [notice] Opened Socks listener connection (ready) on 127.0.0.1:9102
Sep 26 19:03:59 host tor: Sep 26 19:03:59.436 [notice] Opening Socks listener on 127.0.0.1:9103
Sep 26 19:03:59 host tor: Sep 26 19:03:59.436 [notice] Opened Socks listener connection (ready) on 127.0.0.1:9103
480 log messages just for a simple Tor restart. Mostly such types of messages.
Any thing we can do against the log spam?
Why Do we need lots of IsolateDestAddr IsolateDestPort OnionTrafficOnly? Any real world use case? Or just out of principle? If you personally have a use case for one, two… Yeah. Sure. As a favor for a contributor we could add one, two more. But adding 10 more just because out of principle seems not to be a great improvement.
These seem even more specific use cases.
user: I want IsolateDestAddr OnionTrafficOnly but I don’t want IsolateDestAddr IsolateDestPort OnionTrafficOnly. Seems pretty unlikely?
I don’t think it is possible because notice log level shows included and read files which I think is essential.
If you can eliminate some ports what you think are unnecessary, see the output of:
sudo tor -f /etc/tor/torrc --defaults-torrc /usr/share/tor/tor-service-defaults-torrc --dump-config full | grep -i -e socksport -e httptunnelport
Maybe cut each section to 5 which would make the log almost be cut in half.
Some real use cases if for applications onion only:
briar if some day it works on whonix
cwtch when it becomes stable
bitcoind with onlynet=onion
But yes, 10 different ports doesn’t make sense, because if I am running those applications, I will be using different Workstations so the isolation will come from IsolateClientAddr, the OnionTrafficOnly will be just to enforce pure onion.
Or maybe, the simple solution might be to get rid of all the custom ports without applications. User would need to configure them manually.
The problem is with each flag there is N combinations it can be arranged, with itself and with others flags, so I understand the burden.
There is no need to have 10 of each combination also, or even add OnionTrafficOnly broadly, maybe just for OnionShare for now?
I can configure the port myself, just asking to see if it was interesting if set by default, but seeing this again now, maybe too much?
Replied on the text above when I said about N combinations. Yes, unlikely and does not need to be supported by Whonix by default.
Should I open another thread to discuss the ports?
Like for example:
why the uwt wrapped programs (ssh, git, gpg etc) still have their own SocksPort, is this legacy? These ports are not configured on /etc/gitconfig for example, what is used is the torsocks IsolatePID set in /etc/tor/torsocks.conf in combinartion with uwt to call the configured applications via that in the end, using tor’s IsolateSocksAuth.
So, can we discuss which ports should be removed?
IsolateDestAddr IsolateDestPort OnionTrafficOnly
Some port with
9100 - tb - legacy
9104 - apt - superseded by uwt
9105 - gpg - superseded by uwt
9106 - ssh - superseded by uwt
9107 - git - superseded by uwt
9109 - wget - superseded by uwt
9117 - curl - superseded by uwt
9124 - aptitude-curser - superseded by uwt
These ports are mostly unused, 4 sets of 10 SocksPorts and 4 sets of 10 HTTPTunnelPorts. Total: 80 ports
Can we make them 5 sets of 3 ports? and as we used SocksPort and HTTPTunnelPort, double that to get the count of 5x3x2=30 ports.
If a person is using multiple applications that need more then 3 ports per type, they will need to learn how to configure it but I suggest that they should use a separate workstation for isolation of activities and isolation of streams with IsolateClientAddr, which is already the default.
but to be real, I find IsolateDestPort alone futile:
normally we are connecting to different hosts on the same port, eg. http 80, the IsolateDestPort will only apply if using a different protocol like ssh 22, https 443. So you are gonna isolate requests to different protocols, but not the remote addresses…
So maybe in this case there should be a prepared proxy config for each of these applications? /etc/apt/apt.conf.d /etc/gitconfig
Maybe maintain the configs commented?
Because else it is not prepared, as the config is not shipped by anon-apps-config.
Would be useful. Maybe best to keep these in a separate repository or in the wiki to avoid confusion. Or in anon-apps-config but not in /etc folder but in a folder that will not be part of the package being built? The case that this will happen doesn’t have terribly high probability I speculate so no need to go too worried about it. And even if it would happen, doesn’t seem to difficult to invent these configs in a short period of time.
Not against it but would be confusing to migrate Whonix discussions there are usually users there are told to ask in Whonix forums if Whonix specific.
Agree, the point is that if there is already configured socksport but not configured proxy in the workstation for those applications, then either remove the socksports or add configuration to anon-apps-config.
Could be, easier to correct.
Yeah, I don’t believe that will happen because when torsocks fails on normal debian, it is because of the library LD_PRELOAD only used for C programs. And as that does not matter for us, because we just need the random SOCKSAuth from torsocks.
That would be a difficult question to resolve. Very application specific. Whonix “dodged” that question and added a leak shield instead so we don’t need to be very sure which method is better. However, in context of perfect stream isolation, the same question arises.
What is better, configure the application’s proxy settings or using a proxifier?
Not sure I am answering the right question here…
Example configured SocksPort but not configured for uwt / proxy settings?
From that point of view, the torsocks approach is better.
(That doesn’t invalidate above question of which is less likely to result in miscellaneous traffic not using the SocksPort (therefore using TransPort), torsocks or proxy settings.)
In doubt and since probably no further research can be expected on this topic anytime soon, I’d say keep the existing torsocks approach unless in a specific application case (Tor Browser) the proxy settings are actually better researched.