Flash Proxies

David Fifield, Nate Hardison, Jonathan Ellithorpe

Advised by Dan Boneh

Contents

Overview How to Put the Badge on Your Web Page Research Paper How it Works How to Use It Some Technical Information Source Code Contact More Information

Overview

Flash proxies are a new way of providing access to a censorship circumvention system such as Tor. A flash proxy is a miniature proxy that runs in a web browser. It checks for clients that need access, then conveys data between them and a Tor relay.

Tor has bridge relays, but in some cases even these can be blocked despite the fact that their addresses are handed out only a few at a time. The purpose of this project is to create many, generally ephemeral bridge IP addresses, with the goal of outpacing a censor's ability to block them. Rather than increasing the number of bridges at static addresses, we aim to make existing bridges reachable by a larger and changing pool of addresses.

"Flash proxy" is a name that should make you think "quick" and "short-lived." Our implementation uses standard web technologies: JavaScript andWebSocket.

If your browser runs JavaScript and has support for WebSockets then while you are viewing this page your browser is a potential proxy available to help censored Internet users.

How to Put the Badge on Your Web Page

Copy and paste this HTML into your page. An example is at the bottom of this page.

<iframe src="//crypto.stanford.edu/flashproxy/embed.html" width="80" height="15" frameborder="0" scrolling="no"></iframe>

There is an options page (the same page you get by clicking on the badge) with which users can choose whether they want to be a proxy. By default, if a user has not made a choice, they will be a proxy. If you want only people who have explicitly clicked "yes" to be a proxy, add the cookierequired parameter. If a user has selected "no," they will never be a proxy, regardless of the presence of cookierequired.

<iframe src="//crypto.stanford.edu/flashproxy/embed.html?cookierequired" width="80" height="15" frameborder="0" scrolling="no"></iframe>

Research Paper

This paper contains a fuller description of the system and the results of performance experiments.

How It Works

In addition to the Tor client and relay, we provide three new pieces. The Tor client contacts the facilitator to advertise that it needs a connection. The facilitator is responsible for keeping tack of clients and proxies, and assigning one to another. Theflash proxy polls the facilitator for client registrations, then begins a connection to the client when it gets one. The transport plugins on the client and relay broker the connection between WebSockets and plain TCP.

A sample session may go like this:

The client starts Tor and the client transport plugin program (flashproxy-client), and sends a registration to the facilitator using a secure rendezvous. The client transport plugin begins listening for a remote connection. A flash proxy comes online and polls the facilitator. The facilitator returns a client registration, informing the flash proxy where to connect. The proxy makes an outgoing connection to the client, which is received by the client's transport plugin. The proxy makes an outgoing connection to the transport plugin on the Tor relay. The proxy begins sending and receiving data between the client and relay.

The whole reason this is necessary is because the client cannot communicate directly with the relay. (Perhaps the censor has enumerated all the relays and blocked them by IP address.) In the above diagram, there are two arrows that cross the censor boundary; here is why we think they are justified. The initial connection from the client to the facilitator (the client registration) is a very low-bandwidth, write-only communication that ideally may happen only once during a session. A careful, slow, specialized rendezvous protocol can provide this initial communication. The connection from the flash proxy to the client is from an IP address the censor has never seen before. If it is blocked within a few minutes, that's fine; it wasn't expected to run forever anyway, and there are other proxies lined up and waiting to provide service.

From the user's perspective, only a few things change compared to using normal Tor. The user must run the client transport plugin program and use a slightly modified Tor configuration file. Complete details are in ourREADME.

How to Use It

Fuller instructions and troubleshooting are in ourREADME. These instructions require you to be able to receive TCP connections from the Internet (you may have to configure port forwarding on your router). There are some alternative connection scenarios covered in the README.

You must have a version of Tor that supportspluggable transports. This means version 0.2.3.2-alpha or later from the Tor download page. You also need Python.

Download and unzip the flashproxy-client package containing the programs and configuration file you will need. (See the section on verifying the signature.) Start Tor with the included torrc file. tor -f torrc If you already use a custom torrc file, you can instead copy the contents of this one into your own.

By default the flash proxy plugin listens on Internet-facing TCP port 9000. If you have to use a different port (to get through a firewall, for example), edit the ClientTransportLine oftorrc to give a different port number:

ClientTransportPlugin websocket exec ./flashproxy-client --register :0 :8888

If you have installed the flashproxy-client program in a different place, edit the line to give the full path:

ClientTransportPlugin websocket exec /usr/local/bin/flashproxy-client --register

Verifying the package signature

See the Tor Project page onverifying signatures for the commands to run and the expected output. The client packages are signed with subkey 0x5CD388E5 of this key:

pub 8192R/C11F6276 2012-07-21
 Key fingerprint = AD1A B35C 674D F572 FBCE 8B0A 6BC7 58CB C11F 6276
uid David Fifield <david@bamsoftware.com>
sub 4096R/D90A8E40 2012-07-21
sub 4096R/5CD388E5 2012-07-21

You are looking for output like this:

gpg --verify flashproxy-client-version.zip.asc flashproxy-client-version.zip
gpg: Signature made date using RSA key ID 5CD388E5
gpg: Good signature from "David Fifield <david@bamsoftware.com>"

Some Technical Information

Flash and outgoing connections

It is a restriction of WebSockets (and other web technologies like Adobe Flash sockets) that they cannot receive TCP connections, only open them. That is the reason for the client transport plugin; it allows Tor to receive connections instead of making them.

Badge colors

The badge changes color depending on its state.

Dark blue means the proxy is running but no client is being served. Light blue means a client is currently being served. Gray means that the badge has disabled itself. This can be because it has detected it is running on a mobile device, or the browser doesn't support WebSocket (this happens on Internet Explorer 9). Black means that there was an internal error and the proxy is no longer running.

Source Code

All the programs making up the flash proxy system are free software and their source code is visible. To get a copy of everything, run this command:

git clone https://git.torproject.org/flashproxy.git

Or browse the code throughgitweb.

David Fifield <dcf@cs.stanford.edu&gt

Try theissue tracker andtor-talk mailing list.

More Information