During the development meeting today, the group interested in pluggable transports decided to begin to deploy the flash proxy transport in the near future. As a reminder, flash proxies use a small JavaScript/WebSocket program to run proxies in a web browser and provide a hard-to-block pool of IP addresses. This message is a call for testing and comment, and a list of known issues that we are working on. I get the impression that some people have unresolved questions and concerns, and I will do my best to answer those.
Here are links with some background information. The first URL here has a proxy on it; it's the "I support Internet freedom" graphic at the bottom of the page.
http://crypto.stanford.edu/flashproxy/ http://crypto.stanford.edu/flashproxy/flashproxy.pdf https://gitweb.torproject.org/flashproxy.git/blob/HEAD:/README https://lists.torproject.org/pipermail/tor-dev/2011-December/003135.html
You don't have to install anything nor configure port forwarding in order to try the flash proxy transport using this command:
tor ClientTransportPlugin "websocket socks4 tor-facilitator.bamsoftware.com:9999" UseBridges 1 Bridge "websocket 127.0.0.1:9001"
If you're on the miserable hotel wi-fi, try adding: LearnCircuitBuildTimeout 0 CircuitBuildTimeout 1000
Since the last message on this topic, flash proxies no longer use Adobe Flash. They are implemented in JavaScript with WebSocket. We now also work as a pluggable transport.
Here is a list of known issues and things on which I especially invite comment. (There is also a Flashproxy Trac ticket component at https://trac.torproject.org/projects/tor/query?component=Flashproxy.) * There is a central host (or hosts) that sees all proxy and client addresses. The facilitator is the component to which clients advertise their addresses and from which proxies pull addresses to connect to. A compromise of the facilitator would lead to disclosure of Tor users' addresses (and retroactively if logs are being kept). * The censored client must be able to receive a TCP connection; i.e., it can't be behind NAT. There are potential avenues to investigate to remove this restriction, but none of them have been looked at. (The command I gave above works even behind NAT, because it is using a client transport plugin running on the public Internet.) * Some of the infrastructure is running on domains other than torproject.org, namely stanford.edu and bamsoftware.com. The proxy badge itself is hosted at http://crypto.stanford.edu/flashproxy/embed.html. The facilitator is at tor-facilitator.bamsoftware.com. bamsoftware.com is mine and it's being used only because I have control of DNS for that domain. I think it would be more seemly for these to have torproject.org addresses (or maybe even just IP addresses). Also, the only relay that supports the websocket transport is mine, tor1.bamsoftware.com, and all flash proxy traffic will use this as a first hop until there are more. * The flash proxy system is supposed to have a covert rendezvous method for the client to register its need for a connection. All we have now is a dumb blockable HTTP-based rendezvous. The plan is to use this until it is blocked and see what we can learn.
My idea of "deployment" is that we provide packages for download (with a warning that they are only for testing), and make a blog post publicizing them. The packages will contain the client transport plugin program, a README, and a preconfigured torrc file (but not tor the program nor a Tor Browser). My goal is to begin receiving bug reports from users and other developers, and to begin collecting usage metrics.
I wish to enter upon this with due caution and slowness; but I don't want to sit forever on something that could possibly help people. To this purpose I'm trying to be very forthright about the abilities and shortcomings of the flash proxy system. I do hope to receive your consideration and honest feedback, positive and negative.
David Fifield