[tor-dev] Browser-based proxies for circumvention

[David Fifield]

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.

== 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.
	https://crypto.stanford.edu/flashproxy/

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.

== 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.

We are using the torproject.org git server, so our code is
	$ git clone git://git.torproject.org/flashproxy.git
	https://gitweb.torproject.org/flashproxy.git
	https://gitweb.torproject.org/flashproxy.git/blob/HEAD:/README
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).

== 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
   offline.
 * 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.

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.

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.)

== 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.

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.

== 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
it.

== 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.
* 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.
* Build an installer for client programs.
* Try a plain JavaScript proxy.

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.

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.

David Fifield