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

[Nick Mathewson]

On Fri, Mar 27, 2015 at 1:28 AM, Mike Perry <mikeperry at torproject.org> 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.

I've  posted a couple of questions on the ticket, but I should reply here too.

> 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.

My main problems with the patch are:

 A) that it potentially *never* closes a circuit, which is probably
not what we want.

 B) It should not apply to applies to every circuit; only to circuits
where applications manage stream isolation.  By applying to every
circuit, it makes the copy of Tor distributed with TorBrowser a bad
choice for general use by applications that don't want this behavior
... but I'm given to understand that there are plenty of folks who
rely on that binary for general-purpose use.

Because of B, I would strongly suggest that the patch not apply as-is.
As a workaround, you could have the behavior apply only when stream
isolation is set via SOCKS password on a given stream?

>> 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 :/

I think the right answer here is maybe some kind of a randomized upper
limit on lifetime.

>> 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.

Could work! Might want to generalize a bit.

-- 
Nick