[tor-dev] Browser-based proxies for circumvention
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: (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: (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
Re: [tor-dev] Browser-based proxies for circumvention
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: (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: (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
