Tor at the Heart: Flash Proxy

by ssteele | December 16, 2016

During the month of December, we're highlighting other organizations and projects that rely on Tor, build on Tor, or are accomplishing their missions better because Tor exists. Check out our blog each day to learn about our fellow travelers. And please support the Tor Project! We're at the heart of Internet freedom. Donate today!

Flash Proxy

Sometimes Tor bridge relays can be blocked despite the fact that their addresses are handed out only a few at a time. Flash proxies 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, flash proxies 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 and WebSocket. (In the long-ago past we used Adobe Flash, but do not any longer.)

Flash Proxy is built into Tor Browser. In fact, any browser that runs JavaScript and has support for WebSockets is a potential proxy available to help censored Internet users.

How It Works

In addition to the Tor client and relay, we provide three new pieces. The Tor client contacts the flash proxy facilitator to advertise that it needs a connection. The facilitator is responsible for keeping track of clients and proxies, and assigning one to another. The flash 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 the relay broker the connection between WebSockets and plain TCP.

A sample session may go like this:

1. 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.
2. A flash proxy comes online and polls the facilitator.
3. The facilitator returns a client registration, informing the flash proxy where to connect.
4. The proxy makes an outgoing connection to the client, which is received by the client's transport plugin.
5. 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.

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.

Cupcake

Cupcake is an easy way to distribute Flash Proxy, with the goal of getting as many people to become bridges as possible.

Cupcake can be distributed in two ways:

  • As a Chrome or Firefox add-on (turning your computer into a less temporary proxy)
  • As a module/theme/app on popular web platforms (turning every visitor to your site into a temporary proxy)

Comments

Please note that the comment area below has been archived.

December 16, 2016

Permalink

Heh, when I read the headline I thought this must refer to protections for Adobe Flash--- as in on-line video--- but you explained what you really mean very clearly, and its awesome!

More innovation like this please!

You must be causing great dismay in authoritarian circles, and that's wonderful!

December 16, 2016

Permalink

but i cannot add the addon on tbb ! so i cannot try this flash proxy (i never heard about that) in short i do not understand what it is could you show us an example a swf or something clearer ?

December 16, 2016

Permalink

> "Flash proxy" is a name that should make you think "quick" and "short-lived." Our implementation uses standard web technologies: JavaScript and WebSocket. (In the long-ago past we used Adobe Flash, but do not any longer.)

What a brilliant wordplay on an unlikely coincidence. I love it!

December 16, 2016

Permalink

Washnt flash proxy functionality removed from the Tor Browser Bundle a year ago?

December 16, 2016

Permalink

Wow, I am learning a lot from these blogs. Thanks for all the good work!

A happy contributor.

December 17, 2016

Permalink

It appears to me that the facilitator is the long-lived component. Could censors not then block clients' ability to connect to the facilitators the same way they block bridges?

Moreover, what exactly is the facilitator? A binary that listens for WebSocket connections? And are they run by volunteers like bridges?

December 18, 2016

Permalink

I added it to my browser!! This is my first contribution to Tor project (so smaller than what you did to you...) Really appreciate your help!