Hello. We are trying to safely deal with programs that don't support Tor DNS stream isolation so they don't pollute TransPort.
I've read the manual but it's not clear if you enable IsolateClientProtocol by default. Is that the case?
Also if the former is enabled, do you have IsolateDest enabled for DnsPort or not? If no then what is the rationale for this decision?
Thanks.
On 25 Jun 2018, at 02:41, procmem procmem@riseup.net wrote:
Hello. We are trying to safely deal with programs that don't support Tor DNS stream isolation so they don't pollute TransPort.
We don't recommend TransPort for this reason. (See below.)
I've read the manual but it's not clear if you enable IsolateClientProtocol by default. Is that the case?
No, but you're probably looking for *Port isolation instead, which is documented as on by default under SessionGroup:
By default, streams received on different SocksPorts, TransPorts, etc are always isolated from one another. This option overrides that behavior. https://www.torproject.org/docs/tor-manual.html.en
The other default isolation flags are documented in the man page: IsolateClientAddr and IsolateSOCKSAuth There are also some internal flags that are always on: https://gitweb.torproject.org/tor.git/tree/src/or/or.h#n1673
All the isolation flags that aren't named as defaults are not defaults.
Also if the former is enabled, do you have IsolateDest enabled for DnsPort or not? If no then what is the rationale for this decision?
I don't think IsolateDest makes sense for DNSPort. Building a separate circuit for each DNS request is slow (for clients) and expensive (for the network).
And regardless of isolation, resolving DNS addresses at a different exit to the one that connects can cause privacy issues, and it can result in slower connections.
So we recommend SOCKSPort or HTTPTunnelPort instead, because they support sending DNS names to exits as part of the connection request.
Here are a few general reasons for the defaults: * many applications expect to have a single source IP address for all their connections, and * building a circuit for each destination is expensive, but * isolating different users is important, so we automatically isolate different source IP addresses, and automatically isolate applications which have different socks usernames or passwords (users or developers should configure each application with a random socks username and password)
T
teor:
So we recommend SOCKSPort or HTTPTunnelPort instead, because they support sending DNS names to exits as part of the connection request.
Looks like this can also be achieved for TransPort by configuring:
AutomapHostsOnResolve 1 AutomapHostsSuffixes .
Then tor will tor (instantly) hand out an IP address in the VirtualAddrNetworkIPv{4,6} range for _all_ domains, not just .onion etc. With these options, if I watch STREAM events on the control port I see SENTCONNECT to the hostname.
Rusty