[tor-dev] Flash proxy deployment

[David Fifield]

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