StrongSocksIsolation option (w/ virtual circuits?)

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 (moved) and https://trac.torproject.org/projects/tor/ticket/7870#comment:18).

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 (moved) and #9442 (moved) using TrackhostExits instead of MaxCircuitDirtiness (which will mean less idle circuits staying open on relays, taking up memory).

changed milestone to %Tor: unspecified

added component::core tor/tor intro isolation mike-can milestone::Tor: unspecified needs-design points::medium priority::low severity::normal status::new tbb-needs tor-client type::enhancement labels

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

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 (moved) and #7870 (moved) 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).

Trac:
Summary: Provide StrongSocksIsolation torrc option to Determine optimal circuit usage for Tor Browser

Trac:
Cc: N/A to gk

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.

Trac:
Keywords: tor-client deleted, tor-client needs-proposal added

Trac:
Cc: gk to gk, mcs

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 127.23.23.23:25, 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.

Trac:
Cc: gk, mcs to gk, mcs, arthuredelstein

Trac:
Cc: gk, mcs, arthuredelstein to gk, mcs, arthuredelstein, anonym

Trac:
Summary: Determine optimal circuit usage for Tor Browser to StrongSocksIsolation option (w/ virtual circuits?)
Keywords: tor-client needs-proposal deleted, tor-client needs-proposal 028-triage added

Trac:
Milestone: N/A to Tor: 0.2.8.x-final

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

Trac:
Sponsor: N/A to N/A

Trac:
Keywords: tor-client needs-proposal 028-triage deleted, tor-client needs-proposal 028-triage mike-can added

Trac:
Points: N/A to medium

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.

Trac:
Milestone: Tor: 0.2.8.x-final to Tor: 0.2.9.x-final

Trac:
Keywords: tor-client needs-proposal 028-triage mike-can deleted, 028-triage, tor-client, needs-proposal, intro, mike-can added

Trac:
Priority: Medium to Low

tickets market to be removed from milestone 029

Trac:
Milestone: Tor: 0.2.9.x-final to Tor: 0.2.???

Milestone renamed

Trac:
Milestone: Tor: 0.2.??? to Tor: 0.3.???

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

Trac:
Milestone: Tor: 0.3.??? to Tor: unspecified
Keywords: N/A deleted, tor-03-unspecified-201612 added

Remove an old triaging keyword.

Trac:
Keywords: tor-03-unspecified-201612 deleted, N/A added

Trac:
Keywords: 028-triage deleted, N/A added

Trac:
Reviewer: N/A to N/A
Keywords: needs-proposal deleted, needs-design, isolation added
Severity: N/A to Normal

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

Trac:
Keywords: tbb-wants deleted, tbb-needs added

mentioned in issue #20555 (moved)

moved to tpo/core/tor#15458 (closed)