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
On Tue, Jul 03, 2012 at 04:31:53PM -0700, David Fifield wrote:
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
I made packages containing the necessary client programs. If you are going to test, please try these.
http://www.bamsoftware.com/dist/flashproxy/flashproxy-client-0.0.zip http://www.bamsoftware.com/dist/flashproxy/flashproxy-client-0.0.zip.asc
David Fifield
Perhaps, the flash proxy concept could also be used for bridge reachability scanning [1].
Web sites could embed JavaScript code which tries to establish a connection to a provided bridge. The result (reachable or not) is then sent back. When users from different censoring countries visit one of these web sites, they scan the given bridge and report whether it is reachable or not from their vantage point. That way, we could get a more detailed idea of which bridges are blocked and where. This would open the gates for reputation-based bridge distribution strategies [3].
Naturally, there are problems:
- How do we give the bridges to be scanned to the web site visitors without making it easy to enumerate them?
- Bridges are not just blocked on the IP layer but also on the TCP layer or during the SSL handshake. Flash/WebSockets lack the flexibility to do fine-grained scanning across protocol layers. Maybe this problem could be solved by the web server impersonating proposal [2].
- Web site visitors need to get the script as well as the bridges to scan from somewhere. This "somewhere" can be blocked. In order to avoid that, the script could be hosted on a large provider which the censor is unwilling to block.
- Making web site visitors scan bridges without their knowledge or informed consent is problematic.
I don't have a lot of faith in this idea but I figured it would be worth posting it here.
[1] https://blog.torproject.org/blog/research-problem-five-ways-test-bridge-reac... [2] https://lists.torproject.org/pipermail/tor-dev/2012-June/003673.html [3] http://freehaven.net/anonbib/#proximax11
On Fri, Jul 13, 2012 at 12:09:51PM +0200, Philipp Winter wrote:
- Web site visitors need to get the script as well as the bridges to scan from somewhere. This "somewhere" can be blocked. In order to avoid that, the script could be hosted on a large provider which the censor is unwilling to block.
This is a good point. With flash proxies, we want the JavaScript program to be visible from the uncensored Internet. For bridge scanning, we want just the opposite: the program has to be accessible from the censored Internet.
David Fifield
-
David Fifield -
Philipp Winter