Opened 5 years ago

Last modified 3 years ago

#18200 new defect

TrackHostExits forces circuits to same exit, regardless of SOCKSPort isolation flags

Reported by: cypherpunks Owned by:
Priority: High Milestone: Tor: unspecified
Component: Core Tor/Tor Version: Tor:
Severity: Major Keywords: needs-analysis needs-diagnosis isolation trackhostexits
Cc: Actual Points:
Parent ID: Points: 2
Reviewer: 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 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, to should use the same exit until TrackHostExitsExpire, but should NOT use that same exit for to 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:

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.


  • 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=","
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:

Child Tickets

Change History (14)

comment:1 Changed 5 years ago by nickm

Keywords: 027-backport TorCoreTeam201602 added
Milestone: Tor: 0.2.8.x-final
Severity: NormalMajor

comment:2 Changed 5 years ago by nickm

Milestone: Tor: 0.2.8.x-finalTor: 0.2.9.x-final

Throw most 0.2.8 "NEW" tickets into 0.2.9. I expect that many of them will subsequently get triaged out.

comment:3 Changed 5 years ago by nickm

Points: small/medium

comment:4 Changed 5 years ago by nickm

Keywords: TorCoreTeam201602 removed

comment:5 Changed 5 years ago by nickm

Priority: MediumHigh

comment:6 Changed 4 years ago by nickm

Points: small/medium2

small/medium => 2.

comment:7 Changed 4 years ago by isabela

Keywords: isaremoved added
Milestone: Tor: 0.2.9.x-finalTor: 0.2.???

comment:8 Changed 4 years ago by teor

Milestone: Tor: 0.2.???Tor: 0.3.???

Milestone renamed

comment:9 Changed 4 years ago by nickm

Keywords: tor-03-unspecified-201612 added
Milestone: Tor: 0.3.???Tor: unspecified

Finally admitting that 0.3.??? was a euphemism for Tor: unspecified all along.

comment:10 Changed 3 years ago by nickm

Keywords: tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:11 Changed 3 years ago by nickm

Keywords: isaremoved removed

comment:12 Changed 3 years ago by nickm

Keywords: 027-backport removed

These are not ripe for an 027 backport

comment:13 Changed 3 years ago by nickm

Keywords: needs-analysis needs-diagnosis isolation trackhostexits added

comment:14 Changed 3 years ago by nickm

Summary: TrackHostExits overrides effects of SOCKSPort isolation flagsTrackHostExits forces circuits to same exit, regardless of SOCKSPort isolation flags

I think the issue here is that we have only one addressmap for trackhostexits, whereas the reporter thinks (and I kind of agree) that it would make more sense to have one per isolation domain.

Note: See TracTickets for help on using tickets.