[tbb-bugs] #16840 [Tor Browser]: Introduce preference for controlling speculative pre-connections (Related to Tor Browser / present in Firefox)

[Tor Bug Tracker & Wiki]

#16840: Introduce preference for controlling speculative pre-connections (Related
to Tor Browser / present in Firefox)
-----------------------------+---------------------------------------------
     Reporter:  RickGeex_    |      Owner:  tbb-team
         Type:  defect       |     Status:  closed
     Priority:  major        |  Milestone:
    Component:  Tor Browser  |    Version:  Tor: unspecified
   Resolution:  invalid      |   Keywords:  firefox, default, configuration
Actual Points:               |  Parent ID:
       Points:               |
-----------------------------+---------------------------------------------

Comment (by RickGeex_):

 Replying to [comment:5 hap-penis]:

 see https://trac.torproject.org/projects/tor/ticket/16856 for an
 explanation about the issue itself, it appears to be disabled by default
 (i'm still running some tests on it).

 > Copy paste from tails bugtracker.
 >
 > TLDR: Yea. It's a problem. Attackers can know when a target user is
 connected to the tor network. The rest is just data mining. (Look at 10-A
 and 10-B.)
 >
 > May not be a programming "bug". But it's still dangerous.
 > Why are we not turning this off by default?
 >
 > {{{
 > There's a new feature in firefox: Link pre-fetching / pre-loading on
 mouse hover.
 > (It initiates the first part of the tcp handshake with the webserver and
 then waits for the user to click the link before continuing.)
 > So every time a user hovers over a link, the browser will send a packet
 to the destination server, starting a tcp handshake, but not completing
 it.
 >
 > https://bugzilla.mozilla.org/show_bug.cgi?id=814169
 >
 > If someone sends a private message on a website to user who uses tails,
 (or an email to a user who uses webmail and tails), then they can know
 when the user is online, on tor.
 >
 > Steps:
 > 1) An attacker sets up a webserver that is only known to him.
 > 2) The attacker monitors all incoming packets to that webserver.
 > 3) The attacker monitors some of the users connecting to known tor entry
 nodes.
 > 4) The attacker sends an html email to his target containing a link to
 his webserver.
 >
 > 5) The target launches tails, connects to the tor network, and opens his
 email in webmail in firefox.
 > 6) IF the webmail service provider displays emails in html OR if the
 webmail service provider displays urls as click-able links, then the
 target is vulnerable.
 > 7) The target does not click the link. He only hovers over it by
 accident, or to see the full url in the status bar.
 > 8) Firefox will initiate the first part of a tcp handshake over the tor
 network to the attacker webserver.
 >
 > 9) The attacker sees the incoming packet, and concludes that the target
 is currently online connected to the tor network.
 > 10)
 > A) If the target user is connecting via a tor entry node that the
 attacker is monitoring, they can correlate the data going into the entry
 node (size/timing) to identify the target.
 > B) If the target user is connecting via a tor entry node that the
 attacker is NOT monitoring, they will see no correlation, or little
 correlation due to random chance. They can use this information to mark
 the monitored users as not the target. This lets them reduce the number of
 candidates.
 >
 > A or B, they can reduce the list of possible candidates.
 >
 > If they repeat this attack multiple times, they will eventually reduce
 the list of candidates and identify the target.
 >
 > Variants of this technique can be used on public or onion forums to
 estimate the number of users reading a forum thread. Or any page that
 accepts user urls as links.
 > }}}

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