Opened 7 years ago

Closed 5 years ago

Last modified 5 years ago

#5752 closed project (fixed)

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

Reported by: arma Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Keywords: SponsorZ, tor-client, tbb-firefox-patch, TorBrowserTeam201410
Cc: mikeperry, isis, gk, arthuredelstein@…, intrigeri Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

I'm creating this parent project ticket for all the components of Mike's "use the prop171 support in Tor to stop putting unrelated streams onto the same circuit" plan.

Child Tickets

TicketStatusOwnerSummaryComponent
#3455closedarthuredelsteinTor Browser should set SOCKS username for a request based on first party domainApplications/Tor Browser
#5708closedDon't make too many circuits once we're separating streams by domainCore Tor/Tor
#8641closedmikeperryCreate Browser UI indication for current circuit status and exit IPTorBrowserButton

Change History (27)

comment:1 Changed 7 years ago by karsten

Keywords: SponsorZ added
Milestone: Sponsor Z: November 1, 2013

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

comment:2 Changed 7 years ago by nickm

Milestone: Tor: unspecified

comment:3 Changed 7 years ago by nickm

Keywords: tor-client added

comment:4 Changed 7 years ago by nickm

Component: Tor ClientTor

comment:5 Changed 7 years ago by T(A)ILS developers

Cc: tails@… added

comment:6 Changed 6 years ago by mikeperry

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

comment:7 Changed 6 years ago by mikeperry

Cc: isis added

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.

comment:8 Changed 6 years ago by gk

Cc: gk added

comment:9 Changed 5 years ago by mikeperry

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.

comment:10 Changed 5 years ago by nickm

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.

comment:11 Changed 5 years ago by mikeperry

Component: TorFirefox Patch Issues
Owner: set to mikeperry

comment:12 Changed 5 years ago by arthuredelstein

Cc: arthuredelstein@… added

comment:13 Changed 5 years ago by erinn

Keywords: tbb-firefox-patch added

comment:14 Changed 5 years ago by erinn

Component: Firefox Patch IssuesTor Browser
Owner: changed from mikeperry to tbb-team

comment:15 Changed 5 years ago by intrigeri

Cc: intrigeri added; tails@… removed

comment:16 Changed 5 years ago by arthuredelstein

Keywords: TorBrowserTeam201408 added

comment:17 Changed 5 years ago by nickm

Milestone: Tor: unspecified

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

comment:18 Changed 5 years ago by mikeperry

Keywords: TorBrowserTeam201410 added; TorBrowserTeam201408 removed

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.

comment:19 Changed 5 years ago by mikeperry

Resolution: fixed
Status: newclosed

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

comment:20 in reply to:  7 ; Changed 5 years ago by 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?

comment:21 Changed 5 years ago by danieleweber7624

Resolution: fixed
Status: closedreopened

comment:22 Changed 5 years ago by danieleweber7624

Owner: changed from tbb-team to danieleweber7624
Status: reopenedaccepted

comment:23 in reply to:  20 Changed 5 years ago by arthuredelstein

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

comment:24 Changed 5 years ago by arthuredelstein

Owner: changed from danieleweber7624 to tbb-team
Status: acceptedassigned

comment:25 Changed 5 years ago by arthuredelstein

Resolution: fixed
Status: assignedclosed

comment:26 Changed 5 years ago by T(A)ILS developers

Cc: tails@… added

comment:27 Changed 5 years ago by T(A)ILS developers

Cc: tails@… removed
Note: See TracTickets for help on using tickets.