[tor-dev] Browser-based proxies for circumvention

[Jacob Appelbaum]

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

That was my read at first - has anyone tried the basic concept with
WebSockets?

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

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

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

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
>    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?

> 
> 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
automatically blocked.

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

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.

> * Try a plain JavaScript proxy.

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,
Jake