Opened 5 years ago

Closed 4 years ago

Last modified 4 years ago

#13766 closed defect (invalid)

Raise MaxCircuitDirtiness for Tor Browser to 2 hours

Reported by: mikeperry Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Keywords: tbb-usability, tbb-4.5-alpha, TorBrowserTeam201503
Cc: arma, nickm, gk, arthuredelstein, brade, mcs, anonym Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

I just realized that we forgot the second part of #5752 for 4.5-alpha-1, which was to remove the 10 minute circuit lifetime expiry. There are several reasons why we want to do this:

  1. Websites often break when Tor suddenly changes IP address on them. Sometimes, they log you out. Sometimes, they will suddenly change their language. Sites that use captchas will make you solve a new one at this point as well, or your new exit IP will simply suddenly be banned.
  2. Due to tracking cookies, there is much less of a privacy reason to rotate exit IP addresses every 10 minutes. In fact, doing so just exposes you to more of the network, increasing the chance of that session getting exposed to a malicious/compromised/surveilled exit.
  3. Users who want new circuits for their websites should use "New Identity", which gives them this, and also prevents tracking.
  4. It will cause Tor Browser to use less circuits (which was a major concern back before ntor when #5752 was first proposed).

Since this might be a controversial change, I suppose it is best we didn't just roll it out. Does anyone have any serious reasons why we shouldn't do this?

Child Tickets

Change History (14)

comment:1 Changed 5 years ago by nickm

Maybe try "two hours" or something on the way towards "infinite"?

Also, I'm not sure I've thought of every reason why this is a bad idea. It absolutely requires that we be using circuit isolation, so we should make sure that's tested and known to work before we do this.

comment:2 Changed 5 years ago by gk

I think we should fix at least #13670 (+ #9783) first before raising the limit. Especially the OCSP requests make me nervous here. But I don't see a general reason to not raise MaxCircuitDirtiness, quite the contrary I'd say the arguments given in the description are good ones to do so.

comment:3 Changed 4 years ago by arthuredelstein

Cc: arthuredelstein added

comment:4 Changed 4 years ago by mcs

Cc: brade mcs added

comment:5 Changed 4 years ago by mikeperry

Keywords: TorBrowserTeam201501 added; TorBrowserTeam201411 removed

comment:6 Changed 4 years ago by mikeperry

The updater is another thing that may be affected by this. We probably want to ensure we are sending a unique, new nonce as the SOCKS password field for updater requests (both to https://www.torproject.org/projects/torbrowser/RecommendedTBBVersions and to the update manifests at https://dist.torproject.org/torbrowser/update_2/).

comment:7 in reply to:  6 Changed 4 years ago by mikeperry

Replying to mikeperry:

The updater is another thing that may be affected by this. We probably want to ensure we are sending a unique, new nonce as the SOCKS password field for updater requests (both to https://www.torproject.org/projects/torbrowser/RecommendedTBBVersions and to the update manifests at https://dist.torproject.org/torbrowser/update_2/).

At the same time, we want to avoid guard discovery attacks here (see https://trac.torproject.org/projects/tor/ticket/7870#comment:18). This means we want to not give content elements on random websites the ability to generate a ton of script tags with the src set to https://www.torproject.org/projects/torbrowser/RecommendedTBBVersions, for example.

However, if the updates do come from the special "no first party" isolation domain, then this is not that tricky to do, and a special SOCKS password nonce that changes with each request should be sufficient, I think. In fact, this might be sufficient for all "no first party" requests? And also a good idea for all of them?

Last edited 4 years ago by mikeperry (previous) (diff)

comment:8 Changed 4 years ago by mikeperry

Keywords: TorBrowserTeam201502 added; TorBrowserTeam201501 removed

comment:9 Changed 4 years ago by mikeperry

Keywords: tbb-4.5-alpha added

comment:10 Changed 4 years ago by mikeperry

Keywords: TorBrowserTeam201503 added; TorBrowserTeam201502 removed

comment:11 Changed 4 years ago by mikeperry

Resolution: fixed
Status: newclosed
Summary: Raise MaxCircuitDirtiness for Tor Browser (to Infinite)?Raise MaxCircuitDirtiness for Tor Browser to 2 hours

Ok, arthuredelstein reviewed mikeperry/bug13766 in my Torbutton repo (which ensures that any circuit for which we can't find the first party uses an effective 10 minute circuit dirtiness timeout) and said it looked good and behaved fine for him. I also tested it, and verified it was updating the socks isolation every 10 minutes for these circs. I pushed that to torbutton and pushed updates to our torrc files to bump this to 2 hours.

In the long term, we might want to consider doing this via #15458 instead, to avoid keeping circuits open for so long if they are idle. That way, we could set this timeout to much higher than 2 hours without any impact on memory consumption at relays.

comment:12 Changed 4 years ago by mikeperry

Resolution: fixed
Status: closedreopened

comment:13 Changed 4 years ago by mikeperry

Resolution: invalid
Status: reopenedclosed

I reverted this in favor of the Tor patch in #15482 (fork all the things!11). See https://lists.torproject.org/pipermail/tor-dev/2015-March/008550.html for why I think that Tor patch is better.

comment:14 Changed 4 years ago by intrigeri

Cc: anonym added
Note: See TracTickets for help on using tickets.