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

[Ken Keys]

On 3/26/2015 9:01 PM, Mike Perry wrote:
> 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.
>
> 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.
> 2. Longer circuit lifetimes may make correlation easier for adversaries
>    that run Tor nodes or can see inside TLS (by stealing node keys).
> 3. Longer circuit lifetimes may distinguish Tor Browser users at the
>    Guard node.
> 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.
> 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.)
>
> 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.
>
> 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.
>
>
> 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).
>
>
> Thoughts?
>
>
>
> _______________________________________________
> tor-dev mailing list
> tor-dev at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
How will this change affect hidden sites? Wouldn't it make them more
vulnerable to discovery through correlation attacks?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20150326/ced4a891/attachment.html>