[tor-dev] Flash proxy deployment
david at bamsoftware.com
Tue Jul 3 23:31:53 UTC 2012
During the development meeting today, the group interested in pluggable
transports decided to begin to deploy the flash proxy transport in the
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.
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
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
* 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.
More information about the tor-dev