The story of the fight against censorship: how does the flash proxy method created by scientists from MIT and Stanford

In the early 2010s, a joint group of specialists from Stanford University, the University of Massachusetts, The Tor Project and SRI International presented the results of their research on how to combat online censorship.

Scientists have analyzed the methods of circumventing locks that existed at that time and proposed their own method, called flash proxy. Today we will tell about its essence and development history.
')

Introduction

The Internet began as a network open to data of any type, but over time many countries began to filter traffic. Some states block certain sites, like YouTube or Facebook, while others prohibit access to content that contains certain content. In one form or another, locks are applied in dozens of countries from different regions, including Europe.

Users in the regions where locks are used try to get around them using different proxies. There are several directions of development of such systems, one of the technologies - Tor, was used during the project.

Usually, developers of proxy systems for circumventing locks have three tasks that need to be solved:

1. Rendezvous protocols. The rendezvous protocol allows users in a country with locks to send and receive small amounts of information to establish a connection with a proxy — in the case of Tor, for example, it uses rendezvous to distribute the IP address of the Tor relay (bridges). Such protocols are used for low-rate traffic and blocking them is not so easy.
2. Creating a proxy. Interlocking systems need proxies outside the region with filtered Internet to transfer traffic from the client to the target resources and back. The organizers of the blocking may in response prevent users from recognizing the IP addresses of the proxy servers and blocking them. To counter such an attack by Sibyl, the proxy service must be able to constantly create new proxies. It is the rapid creation of new proxies - this is the main essence of the method proposed by the researchers.
3. Camouflage. When a client receives an address from a non-blocked proxy, he needs to somehow hide his communication with him so that the session cannot be blocked using the traffic analysis tools. It should be camouflaged as “normal” traffic, such as data exchange with an online store, online games, etc.

In their work, scientists have proposed a new approach to the rapid creation of proxies.

How it works

The key idea is to use multiple websites to create a huge number of proxies with a short lifespan not exceeding a few minutes.

For this, a network of small sites is created that are owned by volunteers, such as users' home pages, who live outside the region with Internet locks. These sites are not related to the resources that the user wants to access.

On such a site is installed a small badge, which is a simple interface created using JavaScript. An example of such a code:

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

Here is the badge:



When the browser from a location outside the region with locks gets to such a site with a badge, it begins to send traffic to that region and back. That is, the site visitor's browser becomes a temporary proxy. After this user leaves the site, the proxy is destroyed without any trace whatsoever.

As a result, it is possible to obtain a performance sufficient to maintain the Tor tunnel.

In addition to Tor Relay and the client, the user will need three more items. The so-called facilitator, who receives requests from the client and connects it to the proxy. Communication takes place using transport plugins on the client (here is the version for Chrome ) and Tor-relay switches from WebSockets to pure TCP.



A typical session using this scheme looks like this:

1. The client launches Tor, a flash-proxy client (browser plugin), and sends a registration request to the facilitator using the rendezvous protocol. The plugin starts listening to the remote connection.
2. The flash proxy appears online and contacts the facilitator with a request to connect with the client.
3. The facilitator returns the registration, passing flash-proxy data for the connection.
4. The proxy connects to the client whose data was sent to it.
5. The proxy connects to the transport plug-in Tor-more and starts the data exchange between the client and the relay.

The peculiarity of this architecture is that the client never knows in advance exactly where he will need to connect. In fact, the transport plugin accepts the fake destination address only in order to not violate the requirements of transport protocols. Then this address is ignored and a tunnel is created to another endpoint - the Tor relay.

Conclusion

The flash proxy project has been developing for several years and in 2017 the creators stopped supporting it. The project code is available at this link . The flash proxy was replaced by new blocking bypass tools. One of them is the project Snowflake, built on similar principles.