Opened 4 years ago

Closed 4 years ago

#21944 closed enhancement (wontfix)

Makeing all TBB users into middle nodes to make website traffic fingerprinting attacks much harder for a attacker

Reported by: Dbryrtfbcbhgf Owned by: tbb-team
Priority: High Milestone:
Component: Applications/Tor Browser Version:
Severity: Major Keywords:
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


Making every user that uses tor into a middle node would increase the overall network bandwidth and have a constant flow of data entering and leaving each users network. This could make a website traffic fingerprinting attack much harder for a observer watching the traffic on the users end. When the user starts Tor Browser bundle it could randomize the advertised bandwidth to prevent a attacker from subtracting the max bandwidth from the users network and get a estimation on how much the user and not the middle node is using. This could also make it much harder for a time correlation attack to be preformed on users because of the constant traffic flow entering and leaving the users network.

Child Tickets

Change History (2)

comment:1 Changed 4 years ago by blockflare

See the FAQ

You should make every Tor user be a relay.

Requiring every Tor user to be a relay would help with scaling the network to handle all our users, and running a Tor relay may help your anonymity. However, many Tor users cannot be good relays — for example, some Tor clients operate from behind restrictive firewalls, connect via modem, or otherwise aren't in a position where they can relay traffic. Providing service to these clients is a critical part of providing effective anonymity for everyone, since many Tor users are subject to these or similar constraints and including these clients increases the size of the anonymity set.

That said, we do want to encourage Tor users to run relays, so what we really want to do is simplify the process of setting up and maintaining a relay. We've made a lot of progress with easy configuration in the past few years: Tor is good at automatically detecting whether it's reachable and how much bandwidth it can offer.

There are five steps we need to address before we can do this though:

First, we need to make Tor stable as a relay on all common operating systems. The main remaining platform is Windows, and we're mostly there. See Section 4.1 of our development roadmap.

Second, we still need to get better at automatically estimating the right amount of bandwidth to allow. See item #7 on the research section of the volunteer page: "Tor doesn't work very well when relays have asymmetric bandwidth (e.g. cable or DSL)". It might be that switching to UDP transport is the simplest answer here — which alas is not a very simple answer at all.

Third, we need to work on scalability, both of the network (how to stop requiring that all Tor relays be able to connect to all Tor relays) and of the directory (how to stop requiring that all Tor users know about all Tor relays). Changes like this can have large impact on potential and actual anonymity. See Section 5 of the Challenges paper for details. Again, UDP transport would help here.

Fourth, we need to better understand the risks from letting the attacker send traffic through your relay while you're also initiating your own anonymized traffic. Three different research papers describe ways to identify the relays in a circuit by running traffic through candidate relays and looking for dips in the traffic while the circuit is active. These clogging attacks are not that scary in the Tor context so long as relays are never clients too. But if we're trying to encourage more clients to turn on relay functionality too (whether as bridge relays or as normal relays), then we need to understand this threat better and learn how to mitigate it.

Fifth, we might need some sort of incentive scheme to encourage people to relay traffic for others, and/or to become exit nodes. Here are our current thoughts on Tor incentives.

Please help on all of these!

comment:2 Changed 4 years ago by gk

Resolution: wontfix
Status: newclosed

The FAQ quote has a good rationale for this WONTFIX.

Note: See TracTickets for help on using tickets.