Opened 5 years ago

Last modified 2 years ago

#15458 new enhancement

StrongSocksIsolation option (w/ virtual circuits?)

Reported by: mikeperry Owned by:
Priority: Low Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-client, needs-design, mike-can, intro, isolation, tbb-needs
Cc: gk, mcs, arthuredelstein, anonym Actual Points:
Parent ID: Points: medium
Reviewer: Sponsor:


For tor browser security and usability, it would be nice to have an option that instructs Tor to try harder with SocksIsolation. In particular, if this is set, Tor should not retry any stream requests on new circuits once a circuit is successfully used. This will prevent guard discovery attacks from working against the browser (see #13669 and

Additionally, if this value is set, TrackHostExits should also follow the socks username and password isolation. In other words, Tor should track the exits used by hostnames independently for each socks username+password. This would allow us to re-implement #13766 and #9442 using TrackhostExits instead of MaxCircuitDirtiness (which will mean less idle circuits staying open on relays, taking up memory).

Child Tickets

Change History (23)

comment:1 Changed 5 years ago by mikeperry

Hrmm, it also occurs to me that if we use this as a replacement for #13766, we might want TrackHostExits to avoid cannibalizing circuits, and always build fresh ones instead?

comment:2 Changed 5 years ago by mikeperry

Summary: Provide StrongSocksIsolation torrc optionDetermine optimal circuit usage for Tor Browser

I'm think I'm actually asking for two separate things here, which probably should actually be two different tickets. I think what I actually want is a 'TrackIsolationExits' option, and additionally a 'DontAbandonAlreadySuccessfulCircuits' option. In fact, I don't even know if I want the latter, as opposed to just a couple of fixes. That really depends on how common things like #13669 and #7870 are, and now many non-TBB applications actually want Tor to keep building more and more circuits for them until something finally succeeds.

I'm retitling this ticket to reflect that I need to actually talk to Nick to decide what I want. Once that happens, we should close this ticket and make one or two more well-defined tickets that actually reflect the optimal approach. (In truth, I filed this ticket in the first place because I realized it may be a week or more before I actually have a chance to revisit this issue).

comment:3 Changed 5 years ago by gk

Cc: gk added

comment:4 Changed 5 years ago by nickm

Keywords: needs-proposal added

Very interesting; I think there are even more things we'd like to examine in this case, and we might want to think about whether it's Isolation or something else entirely.

comment:5 Changed 5 years ago by mcs

Cc: mcs added

comment:6 Changed 5 years ago by mikeperry

Some notes for potential proposals:

On the DontAbandonAlreadySuccessfulCircuits/StrongSocksIsolation side of this, one additional property we may want is for Tor to reject stream attempts that would be invalid if sent over a currently live circuit with the same socks username+password. This would mitigate weird attacks where sites can collude with exits to redirect a portion of their traffic over to the only exit on the network that allows connections to, or similar. It might also ensure that the Torbutton circuit display is always correct to the extent that only one circuit was used for the site.

On the TrackIsolationExits side, we'll want to specify what to do about cannibalization as well as predictive circuit building, so we can avoid both 4 hop circuits as well as latency while waiting for circuit construction for as many cases as possible.

comment:7 Changed 5 years ago by arthuredelstein

Cc: arthuredelstein added

comment:8 Changed 5 years ago by intrigeri

Cc: anonym added

comment:9 Changed 4 years ago by mikeperry

Keywords: 028-triage added
Summary: Determine optimal circuit usage for Tor BrowserStrongSocksIsolation option (w/ virtual circuits?)

comment:10 Changed 4 years ago by nickm

Milestone: Tor: 0.2.8.x-final

comment:11 Changed 4 years ago by mikeperry

This will become much easier if we consider it while solving #9241.

comment:12 Changed 4 years ago by mikeperry

Keywords: mike-can added

comment:13 Changed 4 years ago by nickm

Points: medium

comment:14 Changed 4 years ago by nickm

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

It is impossible that we will fix all 226 currently open 028 tickets before 028 releases. Time to move some out. This is my second pass through the "new" and tickets, looking for things to move to 0.2.9.

comment:15 Changed 4 years ago by nickm

Keywords: intro added

comment:16 Changed 4 years ago by nickm

Priority: MediumLow

comment:17 Changed 4 years ago by isabela

Milestone: Tor: 0.2.9.x-finalTor: 0.2.???

tickets market to be removed from milestone 029

comment:18 Changed 3 years ago by teor

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

Milestone renamed

comment:19 Changed 3 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:20 Changed 3 years ago by nickm

Keywords: tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:21 Changed 3 years ago by nickm

Keywords: 028-triage removed

comment:22 Changed 3 years ago by nickm

Keywords: needs-design isolation added; needs-proposal removed
Severity: Normal

comment:23 Changed 2 years ago by gk

Keywords: tbb-needs added; tbb-wants removed

Let's just use tbb-needs and use priority there to indicate how urgent we'd like to have those tickets fixed.

Note: See TracTickets for help on using tickets.