[tor-bugs] #15482 [Tor]: Don't surprise users with new circuits in the middle of browsing

[Tor Bug Tracker & Wiki]

#15482: Don't surprise users with new circuits in the middle of browsing
-------------------------+-------------------------------------------------
     Reporter:           |      Owner:  mikeperry
  mikeperry              |     Status:  new
         Type:           |  Milestone:  Tor: 0.2.7.x-final
  enhancement            |    Version:
     Priority:  normal   |   Keywords:  tbb-usability, tbb-4.5-alpha,
    Component:  Tor      |  MikePerry201503, tbb-wants,
   Resolution:           |  TorBrowserTeam201504
Actual Points:           |  Parent ID:
       Points:           |
-------------------------+-------------------------------------------------

Comment (by mikeperry):

 Replying to [comment:4 nickm]:
 > The way I thought I implemented the randomness didn't allow for short-
 lived circuits.  It wasn't choosing randomly between [0,X], but instead
 between [X, X*9/8].

 You're right. In my haste I misread this.

 > For me, the idea of no maximum at all is a bit scary; it means that
 keepalive-type stuff will keep a circuit open forever even if the user
 doesn't expect that it would.

 Are there specific attacks or types of attacks that make you nervous here?

 I believe there is a potential concern that we're making e2e correlation
 easier with longer circuit lifespans, but I think I am more worried about
 the case where I leave my browser open overnight and some website keeps
 pinging itself every so often to cause a new circuit to get built in order
 to discover my guard node. I am also worried about non-malicious but dumb
 websites that do this anyway, and end up exposing me to the entire Tor
 exit node population over the course of a few hours (during which time
 malicious exits get more chances to try to own my browser, sniff my
 cookies, perform e2e correlation, mount their own guard discovery attacks,
 or otherwise mess with me).

 Guard discovery and exit node churn were the main security reasons I
 wanted a huge circuit dirtiness timeout in #13766, until Roger pointed out
 that a fixed-length custom circuit dirtiness would provide a 100% accurate
 distinguisher for Tor Browser users at the Guard node.

 In my ideal world, we would find some way to make this distinguisher
 statistical (instead of absolute, instantaneous certainty) while still
 ensuring really long circuit lifetimes for websites that would otherwise
 cause circuit churn. Plenty of long-term semi-accurate statistical
 classifiers likely exist for Tor Browser traffic at the guard node, so
 this tradeoff seems like the right one to me.

 > Finally -- did somebody test out the isolation thing, to make sure that
 only authentication-isolated circuits get the new behavior?  I only wrote
 it; it does need some testing.

 That's what alphas are for :). In fact, I'm revisiting this ticket right
 now because I'm still personally experiencing cases where my exit IP has
 changed in the middle of actively interacting with a website, and this
 change has disrupted my browsing activity. I'd like to brainstorm ways of
 making the circuit dirtiness larger without exposing us to attacks.
 However, I'm also heavily biased in the usability and experimentation
 direction here, due to the uncertain (and conflicting) nature of the
 security issues at hand...

 My current (admittedly completely haphazard and half-baked) inclination is
 to do something like randomizing the initial per-circuit dirtiness between
 10 minutes and a much larger value, reset the dirtiness to rand(0,10min)
 upon stream close (in circuit_detach_stream()), and still omit any maximum
 value on dirtiness. I'm updating this ticket to give you a chance to talk
 me down from this cliff, ideally within the next few days before I jump
 and commit a patch to do something insane like this for 4.5-stable ;).

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