[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[tor-bugs] #13337 [Flashproxy]: Limit the number of flashproxies that see a client over time
#13337: Limit the number of flashproxies that see a client over time
-------------------------+---------------------
Reporter: arma | Owner: dcf
Type: enhancement | Status: new
Priority: normal | Milestone:
Component: Flashproxy | Version:
Keywords: | Actual Points:
Parent ID: | Points:
-------------------------+---------------------
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)?), 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.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/13337>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs