Isolate browser streams by url bar domain rather than by time interval

added SponsorZ TorBrowserTeam201410 component::applications/tor browser owner::tbb-team priority::medium resolution::fixed status::closed tbb-firefox-patch tor-client type::project labels

Switching from using milestones to keywords for sponsor deliverables. See #6365 (moved) for details.

Trac:
Milestone: Sponsor Z: November 1, 2013 to N/A
Keywords: N/A deleted, SponsorZ added

Trac:
Milestone: N/A to Tor: unspecified

Trac:
Keywords: SponsorZ deleted, SponsorZ tor-client added

Trac:
Component: Tor Client to Tor

Trac:
Cc: mikeperry to mikeperry, tails@boum.org

Trac:
Summary: Isolate browser streams by domain rather than by time interval to Isolate browser streams by url bar domain rather than by time interval

isis just noted in #tor-dev that Tor retries failed DNS queries on other circuits. It appears that we do this for failed stream attempts too. I agree that's a bad property because it allows a web adversary to cause your browser to keep making new circuits until you pick one that uses its middle node.

We should ensure we disable this "retry on new circuit" behavior for content elements of a given URL bar, so that at least content elements don't get to cause you to create tons of circuits. Once a circuit can load a top-level url correctly, it should be considered reliable enough not to abandon if a DNS or other stream times out. This might actually require a new Tor child ticket and patch, though...

It's not clear what (if anything) we should change about the initial URL bar load behavior, though. Perhaps it is safe to remain unchanged, because Tor would at least rate limit that properly before failing the page load.

Trac:
Cc: mikeperry, tails@boum.org to mikeperry, tails@boum.org, isis

Trac:
Cc: mikeperry, tails@boum.org, isis to mikeperry, tails@boum.org, isis, gk

George Danezis pointed out that there is currently a rather extreme vulnerability in Tor's path selection that we might want to try to fix as part of this. It turns out that if you make your exit allow a very rare port (like 25), you can cause clients to use that exit frequently by ensuring that content elements sourced from port 25 are injected. Once you get Tor to create a circuit for this port, it will currently keep using it for other connections on other ports that are allowed at that exit for at least 10 minutes. We should avoid this behavior if we can in the domain isolation implementation.

One option might be to treat such rare port stream requests as their own isolation, which may or may not be what Tor does with SOCKS username+password right now (does anyone know?)

FWIW: I think this attack might not actually work with port 25, because Firefox will refuse the load before Tor even gets the stream request due to port 25 being a banned port from the browser, but there may be other rare exit ports that can be abused for this purpose that Firefox will allow.

Should this really be a "Tor" ticket? Do we need to make any changes in Tor per se for it?

As for the issue George Danezis notes, it should be mitigated by any kind of application-based isolation done using proposal 171. If we're isolating by "first-party domain" then domain-1's use of port 25 shouldn't make domain-2 get affected. If we're isolating by application (using different ports), then app-1's port 25 can't affect app-2.

Trac:
Owner: N/A to mikeperry
Component: Tor to Firefox Patch Issues

Trac:
Cc: mikeperry, tails@boum.org, isis, gk to mikeperry, tails@boum.org, isis, gk, arthuredelstein@gmail.com

Trac:
Keywords: SponsorZ tor-client deleted, tor-client, tbb-firefox-patch, SponsorZ added

Trac:
Owner: mikeperry to tbb-team
Component: Firefox Patch Issues to Tor Browser

Trac:
Cc: mikeperry, tails@boum.org, isis, gk, arthuredelstein@gmail.com to mikeperry, isis, gk, arthuredelstein@gmail.com, intrigeri

Trac:
Keywords: N/A deleted, TorBrowserTeam201408 added

Removing tickets with non-Tor components from "Tor:Unspecified"

Trac:
Milestone: Tor: unspecified to N/A

Pushing this out until after we get FF31ESR stabilized (probably October). If there is still time in September for this, we can add it back in.

Trac:
Keywords: TorBrowserTeam201408 deleted, TorBrowserTeam201410 added

This is merged and implemented in 4.5-alpha-1.

Trac:
Resolution: N/A to fixed
Status: new to closed

Replying to mikeperry:

isis just noted in #tor-dev that Tor retries failed DNS queries on other circuits. It appears that we do this for failed stream attempts too. I agree that's a bad property because it allows a web adversary to cause your browser to keep making new circuits until you pick one that uses its middle node.

We should ensure we disable this "retry on new circuit" behavior for content elements of a given URL bar, so that at least content elements don't get to cause you to create tons of circuits. Once a circuit can load a top-level url correctly, it should be considered reliable enough not to abandon if a DNS or other stream times out. This might actually require a new Tor child ticket and patch, though...

It's not clear what (if anything) we should change about the initial URL bar load behavior, though. Perhaps it is safe to remain unchanged, because Tor would at least rate limit that properly before failing the page load.

Was there a resolution for this part of the issue?

Trac:
Username: danieleweber7624
Status: closed to reopened
Resolution: fixed to N/A

Trac:
Username: danieleweber7624
Status: reopened to accepted
Owner: tbb-team to danieleweber7624

Replying to arma:

Replying to mikeperry:

isis just noted in #tor-dev that Tor retries failed DNS queries on other circuits. It appears that we do this for failed stream attempts too. I agree that's a bad property because it allows a web adversary to cause your browser to keep making new circuits until you pick one that uses its middle node.

We should ensure we disable this "retry on new circuit" behavior for content elements of a given URL bar, so that at least content elements don't get to cause you to create tons of circuits. Once a circuit can load a top-level url correctly, it should be considered reliable enough not to abandon if a DNS or other stream times out. This might actually require a new Tor child ticket and patch, though...

It's not clear what (if anything) we should change about the initial URL bar load behavior, though. Perhaps it is safe to remain unchanged, because Tor would at least rate limit that properly before failing the page load.

Was there a resolution for this part of the issue?

Not that I am aware of. I've opened a new ticket: #13669 (moved)