FlashProxy Howto
When you start the flash proxy software, your computer's external IP address is sent in a covert and encrypted way to the flash proxy facilitator. Shortly after that, several web browsers will try to connect to your computer in order to give you access to Tor. Your computer needs to be able to receive these connections, and port forwarding is the usual way to do that.
In some cases these steps may not be necessary, such as when you use IPv6, or when your computer is not behind network address translation (NAT).
Setting up port forwarding
The steps needed to enable port forwarding unfortunately differ depending on your networking equipment. But the overall procedure is usually the same. You load the IP address of your router (often this is 192.168.0.1 or 192.168.1.1) in a web browser, and follow the configuration instructions. This article has a summary:The default external port you have to open is TCP port 9000. The easiest thing to do is to forward the external port 9000 to port 9000 on your internal IP address. Using a different, randomly chosen port number will make you more resistant to censorship. Doing this requires a bit more setup, described in the next section.
Finding torrc
The flash proxy client transport plugin configuration command is stored in a file called torrc. This file is inside your Tor Browser Bundle, but where it is exactly depends on your operating system. (It should be possible to edit torrc from within Vidalia, but bug #6174 prevents it from working, so you have to do it manually.)
On Windows, open the folder Tor Browser\Data\Tor, right-click on torrc, and edit the file using Notepad.
On OS X, you must right-click or command-click on the browser bundle icon, and select "Show Package Contents". Then go to the folder Library/Vidalia and double-click torrc to open.
On GNU/Linux, open the file tor-browser_en-US\Data\Tor\torrc in a text editor.
Changing settings
Once you have torrc open, you will see a line like this that controls how the flash proxy client is configured:ClientTransportPlugin websocket exec flashproxy-client --register :0 :9000Depending on your platform, the line may have ./App/flashproxy-client in place of flashproxy-client. This is normal. Just remember not to change anything before flashproxy-client.
The --register part tells the client program to send your address to the flash proxy facilitator. You won't get any service without this, so leave it there.
The :0 part is the local SOCKS listening port. This is the port that receives connections from the Tor running in the browser bundle. The special value :0 means that a random port is chosen. You don't have to change this part.
The :9000 part is the external listening port number. This is what you have to change if you have forwarded a different port. Suppose you have forwarded port 39208, for example. Then you would change the line to
ClientTransportPlugin websocket exec flashproxy-client --register :0 :39208For a list of other options you can pass to flashproxy-client, see the man page at https://gitweb.torproject.org/flashproxy.git/blob/HEAD:/doc/flashproxy-client.1.txt.
Using IPv6 (or forcing IPv4)
Sometimes IPv6 connections are less censored, or are not subject to NAT. In this case, you can force the use of IPv6 only by adding the -6 option to the command line. For example,ClientTransportPlugin websocket exec flashproxy-client --register :0 :9000 -6If you are on a dual-stack (both IPv4 and IPv6) system, and have forwarded an IPv4 port, there is a chance that flashproxy-client will use IPv6 anyway, and you won't receive any connections. To force the use of IPv4, use the -4 option.
ClientTransportPlugin websocket exec flashproxy-client --register :0 :9000 -4
Troubleshooting
After starting the browser bundle, you should receive a connection from a flash proxy within 60 seconds. (It can take up to 60 seconds because the email-based rendezvous (#6383) polls every 60 seconds.) If the Tor log shows anything above 10%, it means that you got some level of flash proxy service. Look for the bridge fingerprint of the websocket bridge in the log:[notice] new bridge descriptor '3VXRyxz67OeRoqHn' (fresh): $86FA348B038B6A04F2F50135BF84BB74EF63485B~3VXRyxz67OeRoqHn at 0.0.1.0Try adding the --log option to the flashproxy-client command line. This will create a log file somewhere inside the browser bundle folder. The log file will not whenever a connection is received from a proxy.
Consider making a report of your experience, good or bad, at the flash proxy usability page.
Attachments
-
tbb-showcontents-macosx.png
(12.0 KB) - added by dcf
11 days ago.
A screenshot of the "Show Package Contents" menu on Mac OS X.
-
tbb-torrc-macosx.png
(26.7 KB) - added by dcf
11 days ago.
A screenshot of finding torrc in a Mac OS X browser bundle.
-
tbb-torrc-windows.png
(6.1 KB) - added by dcf
11 days ago.
A screenshot of finding torrc in a Windows browser bundle.
-
tbb-torrc-windows.2.png
(3.7 KB) - added by dcf
11 days ago.
A screenshot of finding torrc in a Windows browser bundle.
Combined flash proxy + pyobfsproxy browser bundles
- Windows (sig)
- Mac OS X (sig)
- GNU/Linux 32-bit (sig)
- GNU/Linux 64-bit (sig)
Flash proxy works differently than other pluggable transports, and you need to take extra steps to make it work. In particular, you will probably need to configure port forwarding in order to receive connections from browser proxies. There are instructions and hints on how to do that at this page: flash proxy howto.
These bundles contain fresh obfs2 bridge addresses, which may work for you if the bridges in the obfsproxy bundle are blocked. The bundles also includes an experimental obfs3 bridge—obfs3 is a new protocol designed to be harder to identify than the previous obfs2. If even these new bridges become blocked, you can find your own obfs2 bridges.
We are looking for feedback on how the bundles work. Please leave comments on the flash proxy usability wiki page or ticket #7824 with your experience, good or bad.
There are other ways you can help beyond testing the bundles. One is to run a bridge with pyobfsproxy. Another is to put the flash proxy badge on your web site or blog, or add it to your Wikipedia profile. If you want your browser to continue to be a proxy after a switch to an opt-in model, click the “Yes” button on the options page.
from https://blog.torproject.org/blog/combined-flash-proxy-pyobfsproxy-browser-bundles
https://blog.torproject.org/blog
----------------------------------------------------------------------
As of 2017, the flash proxy project is deprecated. It was deployed in Tor Browser between 2013 and 2016, but has since been superseded by newer and more effective pluggable transports. If you want to help support a newer circumvention system designed along the same principles as flash proxy, please see Snowflake.
Overview
Flash proxies are a 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 and WebSocket. (In the long-ago past we used Adobe Flash, but do not any longer.)
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 Help
Copy and paste this HTML into your web site or blog. 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>
Browser plugins
Cupcake is an always-on flash proxy plugin for Chrome. Click here to install from the Chrome web store.
Tor Flashproxy Badge is an always-on flash proxy plugin for Firefox. Click here to install from Mozilla Add-Ons.
Wikipedia
Customize your Wikipedia skin to include a flash proxy badge.
Research Paper
This paper contains a fuller description of the system and the results of performance experiments.
- Evading Censorship with Browser-Based Proxies (PDF)
In the Proceedings of the 12th Privacy Enhancing Technologies Symposium (PETS 2012), LNCS 7384, pp. 239–258, 2012.
Video
An overview of the flash proxy system and its state of development as of February 2013.
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. 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 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.
Doesn't the censor win just by blocking the facilitator? Doesn't this shift the problem from bridge-blocking to facilitator-blocking? The short answer to these questions is no. We assume that the censor has blocked the facilitator. For more details, see the FAQ.
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 our README.
How to Use It
Flash proxy is built into Tor Browser. Follow this link to download Tor Browser.
Next, read the flash proxy howto to learn how to configure port forwarding. See the manual configuration in the rest of this section if the browser bundle doesn't work.
Some Technical Information
Limitations on outgoing connections
It is a restriction of WebSockets 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 through gitweb.
History
Flash proxies began as a project in Stanford's CS294s class in spring 2011. David Fifield, Nate Hardison, and Jonathan Ellithorpe were members of the project team. They and Emily Stark, Roger Dingledine, Phil Porras, and Dan Boneh wrote a research paper on the subject. Development continues as part of the Tor Project.Users
Estimated average number of concurrent users. See the metrics site for more control over the graph and historical measurements.
Contact
David Fifield <dcf@cs.stanford.edu>
Try the issue tracker and tor-dev mailing list.