[tor-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
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).
--
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 tor-bugs
mailing list