[tor-bugs] #18200 [Tor]: TrackHostExits overrides effects of SOCKSPort isolation flags

[Tor Bug Tracker & Wiki]

#18200: TrackHostExits overrides effects of SOCKSPort isolation flags
-----------------------------+--------------------------
     Reporter:  cypherpunks  |      Owner:
         Type:  defect       |     Status:  new
     Priority:  Medium       |  Milestone:
    Component:  Tor          |    Version:  Tor: 0.2.7.6
     Severity:  Normal       |   Keywords:
Actual Points:               |  Parent ID:
       Points:               |    Sponsor:
-----------------------------+--------------------------
 I've noticed that adding the line
 > TrackHostExits .
 interferes with
 > SOCKSPort 9050 IsolateClientProtocol IsolateSOCKSAuth
 > SOCKSPort 9060 IsolateClientProtocol IsolateSOCKSAuth
 and possibly other isolation flags.

 Steps to reproduce:
 1. Disable TrackHostExits
 2. Run two Tor Browser instances pointed at different SOCKSPorts, or run
 twice `torsocks curl https://check.torproject.org` with IsolatePID=1. You
 should get two different exit IPs.
 3. Enable TrackHostExits and repeat step 2. You will get the same IP
 accross different Tor Browser instances using different SOCKSPorts, or two
 instances of torsocks even when IsolatePID=1.

 Expected result:
 With TrackHostExits, Tor should track the host exit node within the scope
 of the client SOCKSPort (IsolateClientProtocol) and in compliance with
 other isolation flags. That is, 127.0.0.1:9050 to check.torproject.org
 should use the same exit until TrackHostExitsExpire, but should NOT use
 that same exit for 127.0.0.1:9060 to check.torproject.org if
 IsolateClientProtocol is enabled. The same should go for IsolateSOCKSAuth
 (used by torsocks IsolatePID=1), but for the SOCKS username and password
 rather than port, and all other isolation flags based on their respective
 criteria.

 Note, from the Torrc manual page:
 >IsolateClientProtocol
 >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.)
 Although TransPort 9040 and SOCKSPort 9050 are different protocols subject
 to isolation from one another, the language does not make it completely
 clear whether SOCKSPort 9050 is different from SOCKSPort 9060, for
 example. In my testing, different SOCKSPorts **do** seem to be treated as
 different protocols, subject to isolation when TrackHostExits is disabled.
 Even if they are considered the same protocol, not subject to isolation,
 this doesn't explain why unique SOCKS usernames/passwords are not
 isolated.

 Actual result:
 With TrackHostExits enabled, Tor appears to share circuits to the same
 exit across all combinations of SOCKSPorts and SOCKS username/password
 combinations. This effectively negates the effects of IsolatePID=1 and the
 "New Tor circuit for this site" button in Tor Browser, as well as Tor
 Browsers connecting on different SOCKSPorts, and possibly violates all
 other isolation flags.

 Use cases:
 * Using multiple Tor Browsers on different SOCKSPorts that all use the
 system-installed Tor, or the same instance of the user-installed Tor.
 Ideally the user should be able to simultaneously take advantage of:
  * Browser-level (cache, etc) isolation between instances of Tor Browser.
  * Circuit-level exit isolation between those instances.
  * TrackHostExits within, but not between, those instances, in cases where
 sites expire authentication cookies when the exit changes.
 * Using the "New Tor circuit for this site" button in Tor Browser.
 * Using IsolatePID=1 with torsocks. Long lived applications should be able
 to reuse exits until TrackHostExitsExpire, but NOT share them with other
 PIDs.

 Workarounds:
 * Run multiple instances of Tor.
  * Requires multiple users, or some kind of chroot, in order to work
 around hardcoded paths, and manual torrc/browser port configuration.
 Running multiple instances of Tor as the same user is non-trivial.
  * Consumes additional bandwidth and machine resources.
  * Makes it more difficult to firewall non-Tor traffic using `iptables -m
 owner --uid-owner "tor"`
 * Disable TrackHostExits
  * Some sites will expire authentication cookies frequently and require
 the user to login again. As this is often a security measure, it is not
 really a bug on the site's part.
 * Use the site's .onion address.
  * Many sites do not have a .onion address.

 Possible fixes:
 TrackHostExits in compliance with existing isolation flags, the same way
 as if TrackHostExits is disabled, as described above.

 Alternatively, allow TrackHostExits to be set on a port-by-port basis.
 E.g.
 > SocksPort 9050 IsolateClientProtocol TrackHostExits="."
 > SocksPort 9060 IsolateClientProtocol
 TrackHostExits="example.org,example.com"
 > SocksPort 9070 IsolateClientProtocol
 In this example, exit tracking is disabled for 9070, enabled for 9050 and
 9060, but Tor should NOT share circuits between 9050 and 9060. This
 alternative solution is more of an enhancement while the first one is a
 bug fix.

 Not tested:
 IsolateClientAddr
 IsolateDestAddr
 IsolateDestPort
 SessionGroup

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/18200>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online