[tbb-bugs] #15690 [Applications/Tor Browser]: Document how other extensions should ask to isolate their streams

Tor Bug Tracker & Wiki blackhole at torproject.org
Thu Apr 4 06:52:15 UTC 2019

#15690: Document how other extensions should ask to isolate their streams
 Reporter:  arma                      |          Owner:  tbb-team
     Type:  enhancement               |         Status:  new
 Priority:  Medium                    |      Milestone:
Component:  Applications/Tor Browser  |        Version:
 Severity:  Normal                    |     Resolution:
 Keywords:                            |  Actual Points:
Parent ID:                            |         Points:
 Reviewer:                            |        Sponsor:

Comment (by gk):

 Replying to [comment:5 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 SOURCE=EXIT
 > [04-02 23:05:42] Torbutton INFO: controlPort >> 650 STREAM 22 SUCCEEDED
 > [04-02 23:05:42] Torbutton WARN: no SOCKS credentials found for current
 > [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:
 >                        --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).

Ticket URL: <https://trac.torproject.org/projects/tor/ticket/15690#comment:6>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online

More information about the tbb-bugs mailing list