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:
- 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.")
- A flash proxy appears in a browser and asks the facilitator for an address.
- The facilitator sends a remembered client address to the proxy.
- The proxy connects to the client address. The client's connector receives the connection.
- 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