Opened 6 years ago

Closed 2 years ago

#13337 closed enhancement (wontfix)

Limit the number of flashproxies that see a client over time

Reported by: arma Owned by: dcf
Priority: Medium Milestone:
Component: Archived/Flashproxy Version:
Severity: Normal Keywords: archived-closed-2018-07-04
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


In this blog post, I talk about the various things that go wrong when a node adversary or network adversary gets more and more chances over time to see a Tor client's traffic:

The principle behind the guard design is to limit the number of different points that the client uses to reach the Tor network. (The risk is from not just the operator of the flashproxy, but also from the network hops between the user and the flashproxy, and the flashproxy and the bridge. Changing flashproxies exposes you to a new set of network links each time.)

It seems there's a tradeoff in the Flashproxy design space: using many transient proxies in succession is better for being unpredictable (is that related to being unblockable, or unsurveillable (c.f. #13336)?), but it is worse with respect to this "sample the client's entry connections" attack.

Is there a straightforward way to "pin" a flashproxy to a client, so when the flashproxy is available it ends up being the one chosen to give the client a connect-back? We should explore the tradeoffs here.

Child Tickets

Change History (2)

comment:1 Changed 3 years ago by teor

Severity: Normal

Set all open tickets without a severity to "Normal"

comment:2 Changed 2 years ago by teor

Keywords: archived-closed-2018-07-04 added
Resolution: wontfix
Status: newclosed

Close all tickets in archived components

Note: See TracTickets for help on using tickets.