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

In the early 2010s, a joint team of experts from Stanford University, the University of Massachusetts, The Tor Project and SRI International presented the results of their research ways to combat censorship on the Internet.

Scientists analyzed the methods of bypassing blocking that existed at that time and proposed their own method, called flash proxy. Today we will talk about its essence and history of development.

Introduction

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

Users in regions where blocks are used try to bypass them using various proxies. There are several directions for the development of such systems, one of the technologies, Tor, was used during the project.

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

1. Rendezvous protocols. The rendezvous protocol allows users in a blocking country to send and receive small amounts of information to establish a connection with a proxy - in the case of Tor, for example, uses rendezvous to propagate the IP address of Tor relays (bridges). Such protocols are used for low-rate traffic and it is not so easy to block them.
2. Creating a proxy. Block traversal systems need proxies outside the region with filtered internet in order to pass traffic from the client to the target resources and vice versa. Blocking organizers can respond by preventing users from learning the IP addresses of proxy servers and blocking them. To resist such Sibyl attack the proxy service must be able to constantly create new proxies. It is the rapid creation of new proxies that is the main essence of the method proposed by the researchers.
3. Camouflage. When a client receives the address of an unblocked proxy, it needs to somehow hide its communication with it so that the session cannot be blocked using traffic analysis tools. It needs to be disguised as "regular" traffic, such as data exchange with an online store, online games, etc.

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

How it works

The key idea is to use many websites to create a huge number of proxies with a short lifetime of no more than a few minutes.

To do this, a network of small sites owned by volunteers is being created - like the home pages of users who live outside the region with Internet blocking. These sites have nothing to do with the resources that the user wants to access.

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

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

This is what the badge looks like:

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

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

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

A typical session using this scheme looks like this:

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

The peculiarity of this architecture is that the client never knows in advance where exactly he will need to connect. In fact, the transport plugin only accepts a fake destination address so as not to violate the requirements of the 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. Flash proxies have been replaced by new blocking bypass tools. One of them is the Snowflake project, built on similar principles.

Source: habr.com