[tor-dev] Tor Browser 4.5a5 will change circuit expiry to 2hrs

[Mike Perry]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20150326/8a96b4ae/attachment-0001.sig>