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