Opened 4 years ago

Closed 4 years ago

Last modified 10 months ago

#16856 closed defect (not a bug)

'network.http.speculative-parallel-limit' default setting provides tracking-risk

Reported by: RickGeex_ Owned by: tbb-team
Priority: High Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords:
Cc: brade, mcs, floweb Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

'network.http.speculative-parallel-limit' default setting provides tracking-risk

(thanks to Yuri Khan for the original scenario - 2015-08-14 22:33:56 PDT)

Potential tracking scenario:

  • Attacker sends an e-mail to the Victim with a text around a URL
  • Victim leaves the cursor in the area of the text
  • Tor Browser speculatively connects to the destination URL in the email
  • the Attacker logs this attempts and assigns the exit-node IP-address to the Victims email address

The result is that the exit-node's IP-address can be linked with the e-mail address of the targetted victim. Which (in case of seizing a exit-node) can result in de-anonimizing the un-aware user behind it.

This is exploitable in the Tor browser because the default value of the pre-connections API ('network.http.speculative-parallel-limit') is 6

A fix to mitigate this problem is to set 'network.http.speculative-parallel-limit' to 0 by default.

References

Child Tickets

Change History (9)

comment:1 Changed 4 years ago by gk

Keywords: tor tracking default removed
Milestone: TorBrowserBundle 2.3.x-stable
Version: Tor: unspecified

What makes you sure we are susceptible to this risk given that

a) We set network.predictor.enabled to false
b) We are in Private Browsing Mode and "The seer does not record any data, nor does it take any action, when in private browsing mode." (https://wiki.mozilla.org/Privacy/Reviews/Necko)
c) The seer should not be active at all given that we are using a proxy, see: https://gitweb.torproject.org/tor-browser.git/tree/netwerk/base/nsIOService.cpp?h=tor-browser-38.2.0esr-5.5-1#n1540)

?

comment:2 Changed 4 years ago by gk

Status: newneeds_information

comment:3 Changed 4 years ago by mcs

Cc: brade mcs added

comment:4 Changed 4 years ago by mcs

Kathy and I agree with gk's analysis (#comment:1). We looked at code and did some testing in gdb to confirm.

There is one more related preference: network.predictor.enable-hover-on-ssl. This is false by default, which further disables "on hover" speculative connections when the containing page is an https:// one.

comment:5 in reply to:  1 ; Changed 4 years ago by hap-penis

Duplicate of #16840 https://trac.torproject.org/projects/tor/ticket/16840

Replying to gk:

What makes you sure we are susceptible to this risk given that

a) We set network.predictor.enabled to false
b) We are in Private Browsing Mode and "The seer does not record any data, nor does it take any action, when in private browsing mode." (https://wiki.mozilla.org/Privacy/Reviews/Necko)
c) The seer should not be active at all given that we are using a proxy, see: https://gitweb.torproject.org/tor-browser.git/tree/netwerk/base/nsIOService.cpp?h=tor-browser-38.2.0esr-5.5-1#n1540)

?

That's good news! So... are we sure there's no new connections on link hover?

Aside / off topic: What about some of the other automatic connections listed in: https://support.mozilla.org/en-US/kb/how-stop-firefox-making-automatic-connections#w_prefetching
Like link prefetching?:
<link rel="prefetch" href="/images/big.jpeg">
network.prefetch-next is set to true in TBB.

comment:6 in reply to:  5 Changed 4 years ago by RickGeex_

Not a duplicate of #16840 https://trac.torproject.org/projects/tor/ticket/16840
#16840 was about a way to control the speculative connections

Replying to hap-penis:

Duplicate of #16840 https://trac.torproject.org/projects/tor/ticket/16840

Replying to gk:

What makes you sure we are susceptible to this risk given that

a) We set network.predictor.enabled to false
b) We are in Private Browsing Mode and "The seer does not record any data, nor does it take any action, when in private browsing mode." (https://wiki.mozilla.org/Privacy/Reviews/Necko)
c) The seer should not be active at all given that we are using a proxy, see: https://gitweb.torproject.org/tor-browser.git/tree/netwerk/base/nsIOService.cpp?h=tor-browser-38.2.0esr-5.5-1#n1540)

?

That's good news! So... are we sure there's no new connections on link hover?

If the rel-tag is accepted in e-mail clients, it can be method of tracking indeed.

Aside / off topic: What about some of the other automatic connections listed in: https://support.mozilla.org/en-US/kb/how-stop-firefox-making-automatic-connections#w_prefetching
Like link prefetching?:
<link rel="prefetch" href="/images/big.jpeg">
network.prefetch-next is set to true in TBB.

comment:7 Changed 4 years ago by gk

Resolution: not a bug
Status: needs_informationclosed

Seems we are done here? Please re-open with steps to reproduce the speculative connect related tracking issues found in the latest Tor Browser.

comment:8 Changed 10 months ago by gk

Cc: floweb added
Severity: Blocker

#27889 is a duplicate.

comment:9 Changed 10 months ago by gk

Severity: BlockerNormal
Note: See TracTickets for help on using tickets.