I’ve been quite strict about this. No pre-installation of software which cannot be configured to use a Tor SocksPort. I.e. which pollutes Tor’s TransPort, i.e. that uses system default networking without using a dedicated Tor SocksPort. (That goes for graphical / user applications.) So the DNS for gajim being resolved by Tor’s DnsPort would make gajim unfit for pre-installation in Whonix.
Does the description of the current policy make sense?
I am not sure I have been too strict about this. This for example is one obstacle of installing electrum by default. (ticket) (It’s hard to pre-configure electrum so it would be stream isolated by default.)
When throwing this requirement out of the window, we could end up with users using both gajim and electrum at the same time, all going through the same Tor circuit.
I’m thinking that “stream isolation as a requirement” keeps our hands clean in the event of a highly sophisticated attack, while letting our users fumble in in the dark (such as installing pidgin, or installing gajim but not configuring it) or giving up.
For clarification, my understanding is that some of the pre-installed programs in Whonix-Workstation will share the use of Tor transport. And since IsolateDestPort and IsolateDestAddr can’t be set for Tor transport, this policy will cause programs that can’t be assigned a socksport sharing of same circuit when they are running at the same time. Is this correct?
If so, can we at least somehow document on what those programs are? And maybe even open a brief ticket for each of them so that we can assign them a socksport whenever it’s possible?
I noticed /usr/share/tor/tor-service-defaults-torrc provided the rationale that the reason why IsolateDestPort and IsolateDestAddr cann’t be enabled is because of the file sharing program, is there any other common use case we can come up with that prevents us from enabling them? If not, maybe I can think about how to deal with it.
###############################
## Workstation Trans/Dns-Port #
###############################
## (comment mirrored from /usr/bin/whonix_firewall)
## Transparent Proxy Port for Workstation
## TRANS_PORT_WORKSTATION="9040"
##+# #OptionalFeatureNr.5# Best possible protection against Identity correlation through circuit sharing. ^5^
##
## TransPort is not used for anything preinstalled by default.
## Only as a catch all for user installed applications,
## which is documented.
##
## IsolateDestAddr should not be activated by default,
## if people install filesharing software it would be a nightmare if all connections to the massive amount
## of destination IP's would go through separate circuits.
##
## For the same reason IsolateDestPort should not be activated by default, since BitTorrent (in some cases)
## uses random ports.
TransPort 10.137.5.1:9040
Stream Isolation is one of the most important feature of Whonix. A lot of people try to use their own workstation or even their own gateway because they didn’t know what they may lose.
A program that help/assist/advice users to assign proper socksport may be very helpful to take the full advantage of Whonix. If user can assign a socketport to the file sharing program or other self-installed program, they will be less vulnerable to identity-correlation attack.
However, I know that a lot of programs do not support proxy configuration and some of the file sharing programs are infamous for disobeying the proxy configuration. Therefore, it would be nice if we can somehow force a program to use a certain proxy.
Under windows, there is an application called wincap that can do the job, maybe we can find a linux alternative?
@Patrick Meanwhile an alternative would be to enable something like IsolateClientProtocol so traffic going through TransPort does not carry DNS traffic and so on.
Looking at the DNSPort option I see it also supports an Isolate parameter similar to IsolateAddr but in this case we would be enabling just for DNS traffic if combined with the option above.
For clarification, my understanding is that some of the pre-installed programs in Whonix-Workstation will share the use of Tor transport. And since IsolateDestPort and IsolateDestAddr can’t be set for Tor transport, this policy will cause programs that can’t be assigned a socksport sharing of same circuit when they are running at the same time. Is this correct?
Correct.
If so, can we at least somehow document on what those programs are?
And maybe even open a brief ticket for each of them so that we can assign them a socksport whenever it’s possible?
Good idea.
I noticed /usr/share/tor/tor-service-defaults-torrc provided the rationale that the reason why IsolateDestPort and IsolateDestAddr cann’t be enabled is because of the file sharing program, is there any other common use case we can come up with that prevents us from enabling them?
Any custom installed application by the user that behaves in similar
ways. Cannot be foreseen.
If not, maybe I can think about how to deal with it.
Don’t share circuits with streams using a different protocol. (SOCKS 4, SOCKS 5, TransPort connections, NATDPort connections, and DNSPort requests are all considered to be different protocols.)
The manual no longer mentions what setting is default and which not. Previously it did. I am pretty sure, last time it was saying IsolateClientProtocol is the default already. In case IsolateClientProtocol isn’t the default, we should make a torproject ticket and request it being made the default.
In that case we should also request from Tor Project to make these the default for DnsPort to see their rationale should they refuse.