A. Johnson:
> Hi Mike,
>
> Would you still set a max lifetime for a circuit to accept new streams of 2 hours, or would the circuit potentially persist forever?
Nick set a max lifetime in his updated version of the patch that also
deals with non-Tor Browser activity, but I am not convinced that a max
is a great idea yet. He also randomized the per-circuit max from
[0,max], which seemed not great for usability.
> Security losses that such a change would result in (some of which you mention) include:
> 1. Making it easier for an exit to profile the user because it sees all the userâs traffic for a longer period of time
> 2. Giving an adversary that can observe the client and the destination more time to perform the correlation attack
> 3. Longer time for an adversary to actively compromise relays to walk up the circuit to the client
> 4. If just TorBrowser changes the MaxCircuitDirtiness parameter), then TorBrowser users choose circuits differently from other Tor users (including hidden services), making it possible to split the set of users into two and identify which set a given user belongs to. I think this not an issue in the modification to circuituse.c that you describe.
>
> Security gains include:
> 1. Potentially exposing the user to fewer exit relays and thereby increasing an adversaryâs expected wait time to be chosen as an exit for profiling/correlation attack
> 2. Making it more difficult for an adversary observing a destination to be chosen as a middle relay and thereby observe the guard
>
> My opinion is that the gains outweigh the losses.
With respect to a max on how long we can keep extending dirtiness, I
think so too. At least, it is not clear at all to me that any usable
value of a max will help against losses #1, #2, and #4. It might help
against #3, but the ability to mount that attack is also dependent on
the user activity and the website.
On the other hand, omitting the max (or making it very, very long) does
substantially improve gains #1 and #2, and the risks from attacks
related to gain #1 extend beyond just correlation attacks to arbitrary
attacks against the browser.
Incidentally, the ticket for this change is now
https://trac.torproject.org/projects/tor/ticket/15482. I went with the
SOCKS isolation checks (to avoid impacting non-Tor Browser activity
sharing the same Tor client) but removed the max checks.
> In fact, I think it would be great for TorBrowser to treat each
> tab/window as a separate identity and send *all* streams in a
> given tab/window over the same path (i.e. sequence of relays).
The 4.5 series of Tor Browser actually already does a form of this, but
instead of per tab, we do per URL bar domain. If you have two tabs open
to Facebook, all of those content elements will use the same circuit,
but Facebook like buttons on cnn.com will use the cnn.com circuit.
In addition to being a more sane way of handling web browsing, it also
enables a very simple circuit status UI. The Torbutton menu now tells
you the current circuit for the site in the URL bar in a compact display
that is no larger than the dropdown menu itself.
> > On Mar 27, 2015, at 1:28 AM, Mike Perry <mikeperry@xxxxxxxxxxxxxx> wrote:
> >
> > Mike Perry:
> >> In Tor Browser 4.5a5, we decided to increase MaxCircuitDirtiness to 2
> >> hours (https://trac.torproject.org/projects/tor/ticket/13766).
> >>
> >> Because we also use Tor's SOCKS username isolation using the URL bar
> >> domain as the SOCKS username in Tor Browser 4.5 now, this has the effect
> >> that websites you visit will continue to use the same circuit (and thus
> >> the same exit IP) for all of their content elements for 2 hours, or
> >> until you click "New Identity" or "New Tor Circuit for this Site" (which
> >> appeared in Tor Browser 4.5a4).
> >>
> >> The reasons for this change are detailed in that ticket description, but
> >> in summary I think it is a really, really bad user experience when a
> >> website switches languages, bans you, or logs you out every 10 minutes.
> >> My own workflow in Tor Browser has been frequently interrupted by this
> >> in ways that have caused lost work and/or lost access due to this
> >> problem.
> >
> > Ken's hidden services question (which is a tricky one to answer
> > unfortunately, so I will leave that to someone else) made me think that
> > there is a better way to solve this usability problem: Treat normal
> > circuits like hidden service circuits with respect to dirtiness.
> >
> > This means that instead of simply raising the dirtiness timeout, instead
> > reset the circuit's timestamp_dirty with the current time every time a
> > new stream has been attached. This would be a one line change in
> > connection_ap_handshake_attach_chosen_circuit() in circuituse.c (to
> > remove the 'if (!circ->base_.timestamp_dirty)' check before setting
> > timestamp_dirty).
> >
> > This has the effect that while you are continuing to use a website, it
> > keeps the circuit from being closed, because new streams will keep being
> > attached and the circuit should never hit its dirtiness expiry time.
> >
> > I think this behavior is a good enough compromise such that we don't
> > have to touch the circuit dirtiness timeout. I will reply to the
> > problems of the previous approach in-line below with how it changes
> > them.
> >
> >> With this change in combination with the "New Tor Circuit for this Site"
> >> Torbutton menu option, you now have the ability to get a good circuit
> >> for a site that you can actually use long enough to get something done.
> >>
> >> However, there are some downsides to this change:
> >>
> >> 1. Longer circuit lifetimes may mean more memory consumption at relays.
> >
> > We will no longer be keeping circuits around while not in use. In fact,
> > we should actually use the same amount of circuits per time period with
> > as TBB 4.5a4, with the added benefit of consuming less CPU on ntor
> > handshakes for new circuits.
> >
> >> 2. Longer circuit lifetimes may make correlation easier for adversaries
> >> that run Tor nodes or can see inside TLS (by stealing node keys).
> >
> > This is still a problem with the new timestamp_dirty update approach :/
> >
> >> 3. Longer circuit lifetimes may distinguish Tor Browser users at the
> >> Guard node.
> >
> > This goes from being a certainty ("Hey, this client IP always waits
> > exactly 2 hours from the last cell I saw before tearing down its
> > circuits!") to a statistical classification problem ("Hrmm. Is this
> > circuit still alive because it has an idle but open stream still
> > attached to it, or for some other reason?").
> >
> > There are probably lots of statistical classifiers that can be used to
> > detect Tor Browser clients, so this is a solid improvement, and also not
> > much worse than status quo with 4.5a4.
> >
> >> 4. Longer circuit lifetimes may mean that the Tor client is less able
> >> to adapt to transient changes in Tor relay overload - the load
> >> conditions that caused the Circuit Build Timeout code to pick
> >> your current path may have long since changed over the span of 2
> >> hours.
> >
> > This is still a problem, so long as you continue to use the browser. If
> > you stop for 10 minutes, you will now get a fresh new circuit with
> > better latency properties.
> >
> >> 5. We actually had to hack update, OCSP, and favicon requests to
> >> continue to use 10 minute circuits, because Firefox does not make it
> >> easy to determine the URL bar associated with them. (We opted to keep
> >> the circuits for these requests at 10 minutes to avoid excessive
> >> linkability at the exit.)
> >
> > This is still a problem, as OSCP and update requests can arrive at
> > random frequency. We will need to leave this hack in place.
> >
> >> Did I miss any?
> >>
> >> Long term, I think what I'd rather do to achieve this functionality is
> >> to create a "TrackIsolationExits" Tor feature that ensures that Tor
> >> Browser keeps the same exit IP for a given URL bar domain independent of
> >> the underlying circuit lifespan, as I mentioned in
> >> https://trac.torproject.org/projects/tor/ticket/15458#comment:2.
> >
> > I still want to do this long term.
> >
> >> So: How do we make the decision as to if it is more important to improve
> >> usability in the short term while we design and implement
> >> "TrackIsolationExits", or if the above concerns (and others) trump poor
> >> usability?
> >>
> >> Right now, I am inclined to make the choice that leads to more people
> >> being able to effectively use Tor Browser in the short term, and then
> >> try to provide a better solution that gives similar user-facing
> >> behaviors with better network usage properties in the long term.
> >
> > I am still so inclined. I think I am also crazy enough to throw this Tor
> > patch in to 4.5a5, as it strikes me as a strict improvement over a 2
> > hour circuit timeout, as well as the 4.5a4 status quo.
> >
> >> To complicate matters, as ticket #15458 indicates, there are several
> >> other security concerns related to circuit use by Tor Browser that also
> >> need to be ironed out. In particular, it is actually somewhat dangerous
> >> to allow websites to use a new circuit every 10 minutes for things like
> >> Javascript/AJAX requests, because this enables Guard discovery. SOCKS
> >> isolation and a long circuit lifespan may actually make such Guard
> >> discovery harder, but unfortunately, there may still be other ways to do
> >> this in Tor today (See
> >> https://trac.torproject.org/projects/tor/ticket/13669 and
> >> https://trac.torproject.org/projects/tor/ticket/7870).
> >
> > The change to reset the timestamp_dirty timestamp more often also has
> > the same beneficial effects against Guard discovery: A website that
> > tries to keep doing AJAX in the background will *not* get new circuits
> > every 10 minutes now (though it still may be able to exploit #7870 or
> > #13669).
> >
> > --
> > Mike Perry
> > _______________________________________________
> > tor-dev mailing list
> > tor-dev@xxxxxxxxxxxxxxxxxxxx
> > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>
> _______________________________________________
> tor-dev mailing list
> tor-dev@xxxxxxxxxxxxxxxxxxxx
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
--
Mike Perry
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev