[tor-dev] Browser-based proxies for circumvention
jacob at appelbaum.net
Thu Dec 22 07:37:21 UTC 2011
On 12/21/2011 09:31 PM, David Fifield wrote:
> A few months ago, Roger wrote about ideas for getting more bridge
> addresses (https://blog.torproject.org/blog/strategies-getting-more-bridge-addresses).
> One of the ideas is to make lightweight bridges that can run in a web
> browser. I and some others have been working on this for a few months. I
> want to promulgate our ideas and code among you developers, and ask for
> your opinions and suggestions.
Thanks, I think this is great work!
> == Summary
> The overall idea is a little applet that can be installed on a web page.
> We call it a "flash proxy." As long as you have the page open in your
> browser, you are a proxy. These proxies may only last a few seconds or
> minutes, but the code we've written allows switching between active
> proxies in a fairly transparent manner, enough to make web browsing
> possible. The idea is that web browsers provide a large, diverse, and
> ever-changing pool of bridge addresses. A censor will not be able to
> block all of them in a timely manner--at least that's what we hope.
> This is our overview and demo page. Down at the bottom of the page is a
> flash proxy badge.
> It's called a "flash proxy," and the implementation happens to be in
> Flash, but the "flash" should rather make you think "quick." I'm pretty
> sure the same thing can be done with WebSockets or other technologies.
That was my read at first - has anyone tried the basic concept with
> == Howto
> You can easily but slightly artificially test the flash proxy transport
> with this command:
> $ tor UseBridges 1 Bridge 127.0.0.1:9001 Socks4Proxy tor-facilitator.bamsoftware.com:9999
> (Make sure a flash proxy is running somewhere, and wait about 30 seconds
> for a connection.) What's artificial about this example is that the
> service at tor-facilitator.bamsoftware.com:9999 (the "connector") is
> something you would normally run on your own computer. We run one on the
> Internet for the ease of demos like this. See the instructions in the
> README for how to test it more realistically.
That worked for me as expected:
Dec 21 23:29:08.000 [notice] new bridge descriptor '3VXRyxz67OeRoqHn'
(fresh): $7C03D29CA58BE8EED5F483F31A2DEDF6FD7CC444~3VXRyxz67OeRoqHn at
> We are using the torproject.org git server, so our code is
> $ git clone git://git.torproject.org/flashproxy.git
> Though you need Adobe's Flash Player to *run* the flash proxy, you can
> *build* it using only free software (details are in the README).
Thanks for ensuring that this works with Free Software!
> == Architecture
> Most of the architecture is dictated by a limitation of web socket
> technologies, namely that they can only make outgoing TCP connections,
> and cannot receive connections. This leads to a funny model where the
> proxy connects to the client, instead of the other way around.
> The pieces that work together are:
> * Tor client (e.g. /usr/sbin/tor on the local host).
> * Tor relay (e.g. /usr/sbin/tor on the Internet).
> * Flash proxy, running in someone's web browser. Imagine that there are
> many of these online at once, but they have a lifetime on the order
> of minutes.
> * Connector, a little program that sits between the flash proxy and the
> Tor client, and receives connections from the proxy. It acts as an
> upstream SOCKS4 proxy to Tor (but ignores whatever address Tor gives
> it). The connector also does the switching between proxies as they go
> * Facilitator, which keeps track of clients that need addresses, and
> gives those addresses to proxies as they come online. We are running
> one of these at tor-facilitator.bamsoftware.com:9002.
This all reduces to a very time limited set of bridges - they provide
availability and nothing more.
> 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
> 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?
> Something to note is that the flash proxy doesn't do any crypto. It is
> just a dumb pipe for ciphertext. There are still three relay hops after
> the proxy. (But the proxy effectively gets to pick the first hop.)
Perhaps TLS or HTTP would be a good idea? If the blocking of bridges is
done by protocol fingerprinting, I worry that this will also be
> == Objections
> Doesn't this shift the problem from bridges begin blocked to the
> facilitator being blocked, since the client has to send its address to
> the facilitator? The short answer is yes, we expect the facilitator to
> be permanently blocked by IP address, so the client must find a covert,
> uncensorable channel over which to rendezvous. The good news is that
> we've turned a big problem--how to make all your Tor traffic
> unblockable--into a small problem--how to make a one-time, write-only
> connection of a dozen bytes unblockable. This lesser constraint opens up
> new possibilities, for example you could email your address to someone
> you know and have them rendezvous on your behalf, even though you
> couldn't push all your Tor traffic over such a channel.
DNS names generated from a shared secret come to mind.
> Isn't blocking by protocol/DPI still possible? Yes, there are many
> components to circumvention, and bridge creation is just one part.
> Against such a censor it will be necessary to layer some kind of
> obfuscation, but that's an issue of its own. It also may be a revealing
> signature for a client IP address to receive lots of incoming
> connections, but how much this stands out we don't know yet.
You could transform the Tor client's first hop into something that looks
a lot like HTTP. I think sjm was working on this?
> == Shortcomings
> I should mention that the implementation doesn't live up to everything
> I've stated above. The "rendezvous" step is just an HTTP POST to the
> facilitator. Also, the connector re-registers itself unnecessarily: that
> should happen only once, and thereafter the facilitator should remember
> == Next steps
> Here are the next things I'd like to accomplish:
> * Get the proxy installed on more blogs and web pages. Currently it's
> only on the demo page and on my web site, which only provide enough
> proxies to have service about 60% of the time.
I think the demo text is missing some bytes?
> * Implement a bona fide rendezvous protocol. Though this is somewhat
> separable from flash proxies themselves, it's essential for a complete
> working system. We have done a couple of limited prototypes; please
> ask me if you are interested in or have knowledge of this.
Do you mean something similar to the way GNUnet does nat punching?
> * Build an installer for client programs.
This would be good to bundle in the Tor Browser bundle, I bet.
I like that idea very much - I don't use Adobe anything and while I'd
like to try it with Gnash, I'm not sure that Gnash is ready, is it?
> Unfortunately this has been very much a spare-time project for me. I'd
> love to share some of this development with anyone who's interested.
> I've had a couple of people contact me about possibly supporting
> development in various ways.
Thanks for working on this!
> But what I'd like most of all are your comments and ideas. I really want
> to invite discussion on the architecture, with the goal of making it
> robust and secure. Though the system is already partly usable, I still
> consider it a research project, not a finished product. Circumvention is
> such a big topic I haven't covered all the details in this message, so I
> value your clarifying questions.
Have you tried this with gnash?
All the best,
More information about the tor-dev