Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
Trac
Trac
  • Project overview
    • Project overview
    • Details
    • Activity
  • Issues 246
    • Issues 246
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Operations
    • Operations
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value Stream
  • Wiki
    • Wiki
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Create a new issue
  • Issue Boards

GitLab is used only for code review, issue tracking and project management. Canonical locations for source code are still https://gitweb.torproject.org/ https://git.torproject.org/ and git-rw.torproject.org.

  • Legacy
  • TracTrac
  • Issues
  • #13337

Closed
Open
Opened 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 admin enable hashed storage. More information
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: legacy/trac#13337