Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#16840 closed defect (invalid)

Introduce preference for controlling speculative pre-connections (Related to Tor Browser / present in Firefox)

Reported by: RickGeex_ Owned by: tbb-team
Priority: High Milestone:
Component: Applications/Tor Browser Version: Tor: unspecified
Severity: Keywords: firefox, default, configuration
Cc: hap-penis Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Introduce preference for controlling speculative pre-connections - (original source - https://bugzilla.mozilla.org/show_bug.cgi?id=814169) is also present in the Tor Browser Bundle

Yuri Khan 2015-08-14 22:33:56 PDT

Hey,

here’s a potential tracking scenario:

* Mallory has a database of unverified email addresses. He wants to know which of them are read regularly.
* Mallory associates with each unverified email address a unique IPv6 address within his /64 network.
* Mallory sends each unverified recipient a message which consists of a hyperlink to this unique IPv6 address, wrapped around a lot of text.
* Alice views this message in a web mail client in Firefox. She inadvertently leaves the mouse in the area where the message is to be displayed.
* Firefox speculatively connects to the address of the link.
* Mallory’s router receives all connection attempts and logs destination addresses.
* Because each recipient got a unique IPv6 address, Mallory marks Alice’s email address as verified.

(source: https://bugzilla.mozilla.org/show_bug.cgi?id=814169#c18)

This scenario is also exploitable in the Tor browser because the default value of this 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.

Child Tickets

Change History (6)

comment:1 Changed 5 years ago by hap-penis

Cc: hap-penis added

Moz recommended guide to stop most automatic / speculative connections: https://support.mozilla.org/en-US/kb/how-stop-firefox-making-automatic-connections
How this hasn't been noticed before is UN-believable!

Bug also appears in Tails: https://labs.riseup.net/code/issues/10054
But it is more of a tor browser bundle problem.

If hackers didn't know about this "feature" before, they soon will now.

Can't we include wrapper around ff to prevent this kind of shit?

comment:2 Changed 5 years ago by gk

Resolution: not a bug
Status: newclosed

There is already a way to control speculative pre-connections, see: https://support.mozilla.org/en-US/kb/how-stop-firefox-making-automatic-connections. Thus, this is not a bug.

comment:3 Changed 5 years ago by RickGeex_

Resolution: not a bug
Status: closedreopened

The problem is not that there is a way to control only, but that the default configuration is to use the API in the Tor Browser. Thus this can be marked as a bug.

comment:4 Changed 5 years ago by RickGeex_

Resolution: invalid
Status: reopenedclosed

comment:5 Changed 5 years ago by hap-penis

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.

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

Replying to 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.
Note: See TracTickets for help on using tickets.