Tor Browser 4.5a5 will change circuit expiry to 2hrs
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? -- Mike Perry
Mike Perry:
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.
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.
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.
This is still a problem, as OSCP and update requests can arrive at random frequency. We will need to leave this hack in place.
I still want to do this 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.
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
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? 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. 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). Cheers, Aaron
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.
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.
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.
-- Mike Perry
Regardless of whether you use a maximum, I think it is an obvious improvement to randomize the “typical” circuit switch time (use a new randomly-selected time with each new circuit). A deterministic time makes it possible to predict when a client should switch circuits and thereby facilitates tracking. This is a recommendation from Hutha and Danezis’s “Linking Tor Circuits” (Sec. 5.3) [0].
Interesting - I did not know this! An adversarial destinations could still observe new circuits by including resources from other domains that he controls, which would be prevented by per-tab circuits, but this does seem like very good feature. Cheers, Aaron
On 3/28/2015 4:34 AM, A. Johnson wrote:
Indeed, that is a paper I have marked as interesting and more interesting is Paul Syverson's mitigation solution: https://lists.torproject.org/pipermail/tor-dev/2014-September/007518.html This should be implemented everywhere, not just in Tor Browser. So far we didn't research how much additional load such a change will put on the network.
per-tab circuits would help in other aspects too. Take for example the providers who offer multiple different services (hosted on their subdomains) for the same user account. Simple example, google: fist you have to login on accounts.google.com, you are then redirected to mail.google.com and you can also access drive.google.com. maps, calendar, etc. At this moment TBB 4.5a4 will use different circuits for each, regardless all pages are opened in the same tab. At current moment it works, you are not logged out but some providers to kill the session if the IP address changes during the session. Of course such circuits can also be linked. What if all pages opened in a tab would use the same circuit, and if other new links will be opened in a new tab but request came from a previously opened tab (Open link in new tab clicked by client or target="_blank" on link source or other way to open links from a page in a new browser tab) would use the same circuit as the initial tab, where the request came from? This could be useful.
On Fri, Mar 27, 2015 at 1:28 AM, Mike Perry <mikeperry@torproject.org> wrote:
I've posted a couple of questions on the ticket, but I should reply here too.
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?
I think the right answer here is maybe some kind of a randomized upper limit on lifetime.
Could work! Might want to generalize a bit. -- Nick
Indeed, it would be better if this customization will only apply to circuits requested by Tor Browser (web pages, etc.). Many people just keep Tor Browser running in order to open the Tor socks5 port on localhost, and use that socks proxy with other applications/protocols. Are there any clear benefits if this would apply to all circuits, regardless of application requesting them? On 3/27/2015 3:55 PM, Nick Mathewson wrote:
participants (5)
-
A. Johnson -
Ken Keys -
Mike Perry -
Nick Mathewson -
s7r