[tor-dev] Browser-based proxies for circumvention

[David Fifield]

On Tue, Jan 03, 2012 at 11:32:39AM -0800, Kevin Dyer wrote:
> >>> A sample session goes like this:
> >>> 1. The user starts a connector and a Tor client. The connector sends its
> >>>    address to the facilitator, so that a proxy will know where to
> >>>    connect to. (We call this step "rendezvous.")
> >>> 2. A flash proxy appears in a browser and asks the facilitator for an
> >>>    address.
> >>> 3. The facilitator sends a remembered client address to the proxy.
> >>> 4. The proxy connects to the client address. The client's connector
> >>>    receives the connection.
> >>> 5. The proxy connects to a Tor relay, then begins copying data between
> >>>    its two sockets.
> >>
> >> Where is the list of all facilitators?
> >
> > There is only one (not that there couldn't be more), and its address is
> > hardcoded into the proxy badge.
> 
> I think I am confused about something: Why is it difficult for the
> censor to enumerate, and then block, the facilitators?

That's a good question; it's definitely the most common source of
confusion. We assume that the facilitator is permanently blocked, and
that it is impossible to communicate with it, just as it is impossible
to communicate directly with known relays. Instead client registrations
must go over a special rendezvous channel. I've just uploaded our
research paper, in which we attempt to answer this and other questions:

https://crypto.stanford.edu/flashproxy/flashproxy.pdf

You should look specifically at Section VI, Rendezvous Protocols. I
also tried to address this in my earlier message, under Objections
("Doesn't this shift the problem...?").

https://lists.torproject.org/pipermail/tor-dev/2011-December/003135.html

With the above said, implementations of these rendezvous protocols don't
yet exist except as prototypes. But they are fairly independent from the
rest of the design.

David Fifield