Opened 8 years ago

Closed 6 years ago

#5708 closed task (duplicate)

Don't make too many circuits once we're separating streams by domain

Reported by: arma Owned by:
Priority: Medium Milestone: Tor: 0.2.5.x-final
Component: Core Tor/Tor Version:
Severity: Keywords: maybe-proposal tor-client
Cc: mikeperry, g.koppen@… Actual Points:
Parent ID: #5752 Points:
Reviewer: Sponsor:

Description

In #3455 we're heading toward a world where each Torbutton user has a separate circuit for each referer header. So rather than using the same circuit for an up-to-10-minute period, we could potentially be asking for way way more circuits. That's most bad because of the CPU load it will place on relays.

How many circuits is that exactly, for various client behaviors? We should instrument Tor clients to track how many circuits we would have made under various proposal-171 variations, to get a better handle on how concerned we should be.

Should we consider extending the 10-minute expiry time, to balance the growth in circuits?

Right now we abandon a circuit as soon as any stream takes 10 (or 15) seconds to hear its begin cell. How many circuits are we throwing away early in practice? That's another opportunity to reduce the pain here.

Child Tickets

Change History (17)

comment:1 Changed 8 years ago by Sebastian

The 10 min expiry seems weird in a model where we have one stream per domain anyway. It was meant as a weak form of protection, but with 171 with tor browser support we get something much stronger

comment:2 Changed 8 years ago by mikeperry

Yeah, with #3455 + New Identity, we shouldn't need any auto-expiry time for browser circuits. In fact, the web will work much better for tor users if it auto-expiry goes away. Many websites still log you out if your IP changes.

I'm also not really too worried about the CPU load of this over auto-expiry, especially if we just remove auto-expiry when we deploy it. Users tend to only open a few websites at a time.

comment:3 Changed 8 years ago by mikeperry

The most extreme cases of concurrent website connection I can think of are web searches/portals (which would all have the same referrer, and thus share a circuit even though they are different top-level domains), and Session Restore (which we disable).

comment:4 in reply to:  2 ; Changed 8 years ago by Sebastian

Replying to mikeperry:

I'm also not really too worried about the CPU load of this over auto-expiry, especially if we just remove auto-expiry when we deploy it. Users tend to only open a few websites at a time.

I'm not sure I buy that with the amount of third-party stuff that a lot of websites contain

comment:5 in reply to:  2 Changed 8 years ago by arma

Replying to mikeperry:

I'm also not really too worried about the CPU load of this over auto-expiry, especially if we just remove auto-expiry when we deploy it. Users tend to only open a few websites at a time.

What do you mean by removing auto-expiry in practice? Just hold every circuit open until a relay on it breaks? That seems a poor idea for resource management (the set of circuits just keeps growing) and also privacy (it leaves a much larger window for back-tracking).

comment:6 Changed 8 years ago by mikeperry

Until SIGNAL NEWNYM is sent, or an hour or so of client inactivity, whichever comes first? Doesn't tor already decide to go into some sleep mode if it's inactive for a while?

comment:7 in reply to:  6 Changed 8 years ago by arma

Replying to mikeperry:

Until SIGNAL NEWNYM is sent, or an hour or so of client inactivity, whichever comes first? Doesn't tor already decide to go into some sleep mode if it's inactive for a while?

It does. See rep_hist_circbuilding_dormant() in src/or/rephist.c.

/** For this long after we've seen a request for a given port, assume that
 * we'll want to make connections to the same port in the future.  */
#define PREDICTED_CIRCS_RELEVANCE_TIME (60*60)

But that only applies to making new circuits (and fetching new descriptors). Established circuits will stay open until they have a reason to close.

comment:8 Changed 8 years ago by arma

Milestone: Sponsor Z: November 1, 2013
Parent ID: #5752
Type: projecttask

comment:9 in reply to:  4 ; Changed 8 years ago by mikeperry

Replying to Sebastian:

Replying to mikeperry:

I'm also not really too worried about the CPU load of this over auto-expiry, especially if we just remove auto-expiry when we deploy it. Users tend to only open a few websites at a time.

I'm not sure I buy that with the amount of third-party stuff that a lot of websites contain

That's because you didn't read #3455. It describes how Tor Browser is going to use the feature. Third party elements (user link-click navigation) would all share the same circuit, because they all share referers.

However, I'll add a note in #3455 that we'll need to still force this binding if users somehow disable referers.. That's going to be a pain, though, because there are lots of ways referers can get spoofed/disabled by wacky third party addons...

comment:10 in reply to:  9 Changed 8 years ago by gk

Cc: g.koppen@… added

Replying to mikeperry:

Replying to Sebastian:

Replying to mikeperry:

I'm also not really too worried about the CPU load of this over auto-expiry, especially if we just remove auto-expiry when we deploy it. Users tend to only open a few websites at a time.

I'm not sure I buy that with the amount of third-party stuff that a lot of websites contain

That's because you didn't read #3455. It describes how Tor Browser is going to use the feature. Third party elements (user link-click navigation) would all share the same circuit, because they all share referers.

What about DOS attacks like a folder with _lots_ of bookmarks + right-click on it and "Open all in Tabs"?

However, I'll add a note in #3455 that we'll need to still force this binding if users somehow disable referers.. That's going to be a pain, though, because there are lots of ways referers can get spoofed/disabled by wacky third party addons...

I am wondering whether you would still get the internal referer and could use that somehow: http://stackoverflow.com/questions/7471192/how-do-i-reliably-find-a-requests-referrer-in-a-firefox-addon
Btw: Do not forget requests that have no referer per definition like safebrowsing requests. The latter might not be a problem as they do not happen very often. But what about requests done by the favicon service? Don't they matter either?

comment:11 Changed 8 years ago by nickm

Milestone: Tor: 0.2.3.x-final

Marking for 0.2.3, but it might need to wait for 0.2.4. If it does, we'll need to decide whether the "separate-by-referer" idea also has to wait.

comment:12 Changed 7 years ago by nickm

Milestone: Tor: 0.2.3.x-finalTor: 0.2.4.x-final

Putting this off to 0.2.4.x-final. If there is a solution there, we can consider a backport, but right now I don't see anything above that tells me what to actually build.

comment:13 Changed 7 years ago by nickm

Keywords: maybe-proposal added

comment:14 Changed 7 years ago by nickm

Keywords: tor-client added

comment:15 Changed 7 years ago by nickm

Component: Tor ClientTor

comment:16 Changed 7 years ago by nickm

Milestone: Tor: 0.2.4.x-finalTor: 0.2.5.x-final

comment:17 Changed 6 years ago by mikeperry

Resolution: duplicate
Status: newclosed

Ok we won't make too many circuits while separating circuits by domain. There are ways to reason about this problem without burying it under a decade worth of research, though.

Can we just discuss this as part of the design proposal for #5752, rather than confusing responsibilities and making Nick and others think they actually need to build something in Tor here (which they don't, IMO).

Calling this a dup of #5752 for that reason.

Note: See TracTickets for help on using tickets.