Isolation flag. see man.
See OnionTrafficOnly. It does exactly what you are reading, per socks port.
Can ports be added with this flag by default?
IsolateDestAddr IsolateDestPort OnionTrafficOnly
IsolateDestAddr OnionTrafficOnly
IsolateDestPort OnionTrafficOnly
OnionTrafficOnly → I don’t see much reason for this one alone, but you decide
Sure, for Tor SocksPorts that are only supposed to have onion traffic, this should be enabled.
Contributions are welcomed.
Didn’t test but I don’t see why not. For applications that use very few IPs / ports, we can enable it.
TPO however expressed in the past that they prefer we don’t enable IsolateDestAddr IsolateDestPort for lets say Tor Browser.
Contributions are welcomed.
On my todo.
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).
But line
SocksPort 10.152.152.10:9108 IsolateDestAddr IsolateDestPort
could and should probably be modified to
SocksPort 10.152.152.10:9108 IsolateDestAddr IsolateDestPort OnionTrafficOnlyYes
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.
Could be kept pretty basic. With VM networking disabled. It could be the case that simply having the port configured already leads to a higher use of RAM.
Cool ideal.
Yes, that would be nice if there is something missing.
Is it already documented under https://www.whonix.org/wiki/Stream_Isolation#Basic_Protection
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.
I am running a Gateway capped to 600 ram
total used free shared buff/cache available
Mem: 528Mi 383Mi 40Mi 14Mi 104Mi 46Mi
only 383Mi being used
sudo pmap $(pgrep tor) | tail -1
reports 80452 K, which are 78.5MB.
Just a basic report now.
Oh, didn’t notice, I was expecting it to be in a table format as it was done for the other specified applications.
Creted a new Gateway, configured tor normally.
Initial mem used is 351Mi.
After removing all SocksPorts and HTTPTunnelPorts,
except socks 9050, commend the include line of the defaults file in 70_gateway.conf, restarted tor.
Mem used is 347Mi.
Edit:
Moved the files back to location and uncommented the include line, restarted tor. Mem used now is 348Mi. This means that the first tor start had some memory fragments caused by C language.
I consider this irrelevant for the amount of ports used, 1Mi is for that many ports is not gonna impact anything.
So I assume I can change the defaults of whonix to add more ports?
The other price to pay is the log spam.
sudo journalctl -u tor@default -f
Just an except.
sudo systemctl restart tor
Sep 26 19:03:59 host tor[1429]: 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[1429]: 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[1429]: 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[1429]: Sep 26 19:03:59.435 [notice] Opening Socks listener on 127.0.0.1:9101
Sep 26 19:03:59 host tor[1429]: 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[1429]: Sep 26 19:03:59.436 [notice] Opening Socks listener on 127.0.0.1:9102
Sep 26 19:03:59 host tor[1429]: 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[1429]: Sep 26 19:03:59.436 [notice] Opening Socks listener on 127.0.0.1:9103
Sep 26 19:03:59 host tor[1429]: 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
and decide.
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:
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.
Instead of including 10 OnionTrafficOnly of each combination as I intended on the first post.
We are at: Reduce default ports because:
Maybe add OnionTrafficOnly for onionshare and other onion only applications.
Maybe reduce the number of default ports? They don’t impact on memory but does impact on configuration and log readability.
That all makes sense. We’re on the same page now.
Should I open another thread to discuss the ports?
Like for example:
/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
for OnionShare.
Some port with
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.
TYPEPort → SocksPort or HTTPTunnelPort
TYPEPort
TYPEPort IsolateDestAddr
TYPEPort IsolateDestPort
TYPEPort IsolateDestAddr IsolateDestPort
TYPEPort IsolateDestAddr IsolateDestPort OnionTrafficOnly
So I propose reducing from 80 ports to 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:
Maybe:
TYPEPort
TYPEPort IsolateDestAddr
TYPEPort IsolateDestAddr IsolateDestPort
TYPEPort IsolateDestAddr OnionTrafficOnly
TYPEPort IsolateDestAddr IsolateDestPort OnionTrafficOnly
I give a higher priority to IsolateDestAddr than IsolateDestPort because there are other means a website can you are reaching its different ports, fingerprinting, cookies, session activity time.
Not sure in this case. Topic seems pretty similar. Whatever you feel works best here.
[A] Good question. Defense in depth? Better prepared in case torsocks is ever deprecated or breaks?
Sure.
Yes, for sure.
Pending outcome of discussion of A) (top of this post).
Seems better.
Yeah.
Let’s see if any others care about this proposed change. Going to post on social media just in case. Just giving a bit more time for input.
Yeah. No realistic use case example where that would make sense is known.
So maybe in this case there should be a prepared proxy config for each of these applications?
/etc/apt/apt.conf.d
/etc/gitconfig
etc
Maybe maintain the configs commented?
Because else it is not prepared, as the config is not shipped by anon-apps-config.
Also HTTPTunnelPort seems to be very very unused
https://forums.whonix.org/search?q=HTTPTunnelPort
But ok to leave it with a few ports.
Great, let me know when you have results. Maybe post on qubes forums? Although most of Whonix is probably using other hypervisors, the qubes forum is more active then for example Whonix’s Twitter.
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.
Ok.
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.
Do you mean should either
A) uwt (torsocks), or
B) proxy settings method
be used?
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.
In the wiki in chapter
https://www.whonix.org/wiki/Stream_Isolation#How_to_mitigate_identity_correlation
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.