Post by procmemHello. 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.)
Post by procmemI'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.
Post by procmemAlso 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