Opened 4 years ago

Last modified 7 weeks ago

#15690 new enhancement

Document how other extensions should ask to isolate their streams

Reported by: arma Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords:
Cc: jrf@…, gk, mcs, brade Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

I'm talking to a Firefox extension developer who is installing his extension into Tor Browser and giving the resulting bundle to his users.

His extension makes network requests, and it occurred to me that the new per-tab stream isolation feature in Tor Browser probably lumps the requests from his extension into the catch-all circuit.

Is there a URL I can send him to that explains how his extension should set its socks username/password (or whatever it needs to do) to request its own isolation from Tor?

Child Tickets

Change History (6)

comment:1 in reply to:  description ; Changed 4 years ago by gk

Replying to arma:

I'm talking to a Firefox extension developer who is installing his extension into Tor Browser and giving the resulting bundle to his users.

His extension makes network requests, and it occurred to me that the new per-tab stream isolation feature in Tor Browser probably lumps the requests from his extension into the catch-all circuit.

This is true, yes.

Is there a URL I can send him to that explains how his extension should set its socks username/password (or whatever it needs to do) to request its own isolation from Tor?

Not yet. We could write something and link to it from https://trac.torproject.org/projects/tor/wiki/doc/TorBrowser/Hacking in the Other Resources section. That said I am not sure whether there should be anything done in this case at all as the paradigm is that we isolate all requests to the URL bar domain in the current tab. But extensions don't have anything like that. How is this supposed to work? The extension hard-codes a particular domain and every time it "sees" particularly formed requests which would get put on the catch-all circuit it sets the socksname to this domain + increments the password if necessary?

comment:2 Changed 4 years ago by gk

Cc: gk added

comment:3 Changed 4 years ago by mcs

Cc: mcs brade added

comment:4 Changed 18 months ago by teor

Severity: Normal

Set all open tickets without a severity to "Normal"

comment:5 in reply to:  1 ; Changed 7 weeks ago by sysrqb

Last night I noticed if the browser is closed for more than 24 hours, then at startup both torbutton and https-everywhere check for updates at the same time - and they use the same catch-all circuit.

[04-02 23:05:41] Torbutton INFO: Checking version with socks port: 9150
[04-02 23:05:41] Torbutton INFO: tor SOCKS: https://www.torproject.org/projects/torbrowser/RecommendedTBBVersions via
                       --unknown--:ccf852ed7d4b2ab5dee2e90ae4950456
[04-02 23:05:42] Torbutton INFO: controlPort >> 650 STREAM 22 REMAP 4 138.201.14.197:443 SOURCE=EXIT
[04-02 23:05:42] Torbutton INFO: controlPort >> 650 STREAM 22 SUCCEEDED 4 138.201.14.197:443
[04-02 23:05:42] Torbutton WARN: no SOCKS credentials found for current document.
[04-02 23:05:42] Torbutton INFO: tor SOCKS: https://www.https-rulesets.org/v1//rulesets-signature.1554143726.sha256 via
                       --unknown--:ccf852ed7d4b2ab5dee2e90ae4950456
[04-02 23:05:42] Torbutton INFO: tor SOCKS: https://www.https-rulesets.org/v1//default.rulesets.1554143726.gz via
                       --unknown--:ccf852ed7d4b2ab5dee2e90ae4950456
[04-02 23:05:42] Torbutton INFO: tor SOCKS: https://2019.www.torproject.org/projects/torbrowser/RecommendedTBBVersions via
                       --unknown--:ccf852ed7d4b2ab5dee2e90ae4950456

My feeling is this is a bug, and these requests should be FPI-respecting (meaning each extension should be considered as its own first-party in this context). It seems like there should be some mechanism for linking a connection (when it reaches the proxy service) with the extension where it originated. Unforunately, it seems like this doesn't currently exist(?).

In spite of my feeling, I'm not sure about the harm imposed by not isolating these requests. It potentially leaks to an exit node there is (with high probability) a Tor Browser user who started the browser after 24+ hours of it not running. This could mean they didn't upgrade to the latest version yet, and this could expose them to an attack vector (if a severe vulnerability in Tor Browser was recently patched). But I'm not sure leaking this information is different than many other traffic patterns (such as connecting to aus1.tp.o and downloading megabytes of data at a time when there wasn't a recent release). It would be nice if we can quantify the risk associated with this.

comment:6 in reply to:  5 Changed 7 weeks ago by gk

Replying to sysrqb:

Last night I noticed if the browser is closed for more than 24 hours, then at startup both torbutton and https-everywhere check for updates at the same time - and they use the same catch-all circuit.

[04-02 23:05:41] Torbutton INFO: Checking version with socks port: 9150
[04-02 23:05:41] Torbutton INFO: tor SOCKS: https://www.torproject.org/projects/torbrowser/RecommendedTBBVersions via
                       --unknown--:ccf852ed7d4b2ab5dee2e90ae4950456
[04-02 23:05:42] Torbutton INFO: controlPort >> 650 STREAM 22 REMAP 4 138.201.14.197:443 SOURCE=EXIT
[04-02 23:05:42] Torbutton INFO: controlPort >> 650 STREAM 22 SUCCEEDED 4 138.201.14.197:443
[04-02 23:05:42] Torbutton WARN: no SOCKS credentials found for current document.
[04-02 23:05:42] Torbutton INFO: tor SOCKS: https://www.https-rulesets.org/v1//rulesets-signature.1554143726.sha256 via
                       --unknown--:ccf852ed7d4b2ab5dee2e90ae4950456
[04-02 23:05:42] Torbutton INFO: tor SOCKS: https://www.https-rulesets.org/v1//default.rulesets.1554143726.gz via
                       --unknown--:ccf852ed7d4b2ab5dee2e90ae4950456
[04-02 23:05:42] Torbutton INFO: tor SOCKS: https://2019.www.torproject.org/projects/torbrowser/RecommendedTBBVersions via
                       --unknown--:ccf852ed7d4b2ab5dee2e90ae4950456

My feeling is this is a bug, and these requests should be FPI-respecting (meaning each extension should be considered as its own first-party in this context). It seems like there should be some mechanism for linking a connection (when it reaches the proxy service) with the extension where it originated. Unforunately, it seems like this doesn't currently exist(?).

In spite of my feeling, I'm not sure about the harm imposed by not isolating these requests. It potentially leaks to an exit node there is (with high probability) a Tor Browser user who started the browser after 24+ hours of it not running.

That's true.

This could mean they didn't upgrade to the latest version yet, and this could expose them to an attack vector (if a severe vulnerability in Tor Browser was recently patched). But I'm not sure

How so? That check is done at any rate whether you have an updated Tor Browser or not. So, the not-updated/updated bit is not leaked here.

leaking this information is different than many other traffic patterns (such as connecting to aus1.tp.o and downloading megabytes of data at a time when there wasn't a recent release). It would be nice if we can quantify the risk associated with this.

Not sure how to quantify that. I've not thought much about it yet. However, we could easily put the requests on different catch-all circuits if we wanted. While FPI is bound to the URL bar domain and we therefore don't have a first party in case of background requests like extenion update checks, we could hardcode a bunch of those request URLs (e.g. from extensions we ship ourselves) and then change the catch-all circuit every time we see such a URL (or have seen it).

Note: See TracTickets for help on using tickets.