[tor-bugs] #13336 [Flashproxy]: Reduce centralization that allows enumeration of flashproxies

Tor Bug Tracker & Wiki blackhole at torproject.org
Sun Oct 5 00:27:41 UTC 2014


#13336: Reduce centralization that allows enumeration of flashproxies
-------------------------+---------------------
 Reporter:  arma         |          Owner:  dcf
     Type:  enhancement  |         Status:  new
 Priority:  normal       |      Milestone:
Component:  Flashproxy   |        Version:
 Keywords:               |  Actual Points:
Parent ID:               |         Points:
-------------------------+---------------------
 One of the cool side effects of the Flashproxy design is that its
 transient addresses provide a buffer between the known IP addresses of the
 Tor network and the clients who use them. So some classes of global
 surveillance-oriented rules will have a tougher time enumerating those
 clients.

 My use case is against an adversary who builds a list of IP addresses and
 then logs all packets for all flows that are to or from any of these IP
 addresses. If that adversary later learns about an IP address whose flows
 it wishes it had logged, it can't go back in time and get the whole flow.

 That is, picture an adversary who wants to write down all flows of all Tor
 users, but can't afford to write down all flows of all Internet users.
 Flashproxy is interesting in that when you see the Tor client <->
 flashproxy flow, you don't yet realize it's worth writing down. Unless
 somehow you learned beforehand that that flashproxy was worth watching.

 (I don't mean to say that defeating this adversary will defeat all large
 surveilling adversaries. But I think this one is still a worthwhile step.)

 So, what are the centralized components in the Flashproxy design that
 would allow the attacker to preemptively put a list of all flashproxy IP
 addresses on his list?

 One is the facilitator -- if you watch connections to it, you see all the
 flash proxies every time they ask if there are new clients that need
 connect-backs -- potentially long before they actually hear about a client
 and connect to it. Can we reduce this vulnerability?

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/13336>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online


More information about the tor-bugs mailing list