Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • Trac Trac
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Issues 246
    • Issues 246
    • List
    • Boards
    • Service Desk
    • Milestones
  • Monitor
    • Monitor
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value stream
  • Wiki
    • Wiki
  • Activity
  • Create a new issue
  • Issue Boards
Collapse sidebar
  • Legacy
  • TracTrac
  • Issues
  • #13337

Closed
Open
Created Oct 05, 2014 by Roger Dingledine@arma

Limit the number of flashproxies that see a client over time

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: https://blog.torproject.org/blog/improving-tors-anonymity-changing-guard-parameters

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 (closed))?), 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.

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking