When a filtered client wants to visit a blocked site it first registers with the facilitator using a robust rendezvous protocol. Registration amounts to sending the client’s IP address to the facilitator. I discuss a few options for rendezvous in the next section. Now, when a random user visits the volunteer website, the badge running in the visitor’s browser obtains the address of a filtered client from the facilitator. The badge then contacts that client and relays traffic for it.

There are many technical and policy challenges in making this architecture work. A detailed paper analyzing the components and performance of this system, including a detailed security analysis, will be available on the Flash Proxies project website ( crypto.stan-ford.edu/flashproxy). Here I briefly discuss a few issues.

First, since the proxies are short-lived, the client must somehow hop from proxy to proxy during a single You Tube video. To do so, the client runs local “connector” software that acts as a local proxy and presents a persistent connection to the client’s computer. The connector keeps a list of five active proxies at any given time and jumps from one to the next when the current proxy vanishes. Another technical complication is that the visitor’s browser initiates the connection to the filtered client, but since the client is likely to be behind a NAT (Network Address Translation) we must use NAT punching tools, such as those built into the Adobe Flash Player. This is the primary reason for implementing the badge in Adobe Flash rather than Javascript.

Furthermore, there are policy and possibly legal questions in deploying this system. First, the Web visitor may not want his browser to connect to sites that the filtered client chooses to browse. Fortunately, this is completely under the control of the volunteer site that deploys the badge. The site can choose to program the badge to only relay to whitelisted sites like Facebook and YouTube or it can program the badge to only relay into Tor entry nodes. This ensures that visitors to the site do not end up connecting to questionable websites. Blocked sites like You Tube may choose to deploy the badge so that it only relays to You Tube.

This way, YouTube users help other YouTube users reach the site. Either way, all traffic is encrypted, either via HT TPS or via Tor encryption.

Another issue is that users visiting the volunteer site may not want to participate in this system. Again, the volunteer website can choose how to deploy the badge. It can deploy the badge as an opt-out mechanism where visitors click on the badge to disable it. Or it can deploy the badge as an opt-in system where visitors need to express consent (e.g., on a user profile page) to activate the badge. Either way, the volunteer site has complete control as to how the badge is deployed. We also note that the badge disables itself when loaded on a mobile browser so as not drain the battery or exhaust the user’s data plan.

SAMPLE RENDEZVOUS PRO TOCOL
STRATEGIES

I conclude with a few methods for implementing a robust rendezvous protocol. These methods can be used simultaneously so that all would need to be defeated for rendezvous to fail.

Gmail. The Tor project uses Gmail as one approach to distributing bridge addresses. Clients sign up for a Gmail account and send an email to Tor from that account. Tor responds to that email account with a bridge address. The hope is that Gmail is too central to block entirely and that Google does a good job of preventing Sybil attacks.

Skype. Vimalkumar Jeyakumar built a rendezvous mechanism on top of the Skype datagram service AP2AP. Since all Skype traffic is encrypted, the filter would need to block all of Skype to stop this approach. Blocking Skype is non-trivial by design and also causes significant collateral damage. The rate achieved through AP2AP is a few kilo-bytes per second, more than enough for rendezvous, but not enough for watching a You Tube video.

Cloud storage. Emily Stark and Sid-dhi Soman built a rendezvous protocol that uses cloud storage providers such as Amazon S3, Google Docs and Windows Azure. The client uploads data to the service and the circumvention system reads the data. Traffic is over HTTPS and is indistinguishable from normal traffic to the cloud service.

The hope is that blocking Amazon S3, Google Docs and Windows Azure disables too many acceptable services.

CONCLUSION AND FUR THER
READING

Filtering circumvention is a fascinat-
ing topic with many real-world rami-
fications. We mention that President
Obama, in his Middle East address on
May 19th this year, said:
“We will support open access to the
Internet, and the right of journalists to
be heard—whether it’s a big news orga-
nization or a lone blogger.”
How often is a technical computer
science question mentioned in a presi-
dential address?

For readers interested in learning
more about this topic, there is a wealth
of published papers and blog posts. A
few online resources include:
• The Tor project and blog; https://
blog.torproject.org
•Free Haven’s selected papers in
anonymity, an online bibliography
on anonymity and filtering cir-
cumvention ; http://freehaven.net/
anonbib
• The Open Net Initiative and
the Internet Censorship report;
http://opennet.net
• The 2011 Usenix workshop on Free
and Open Communications on the
Internet;
http://www.usenix.org/event/foci11

• For a sample of recent research on this topic see https://telex.cc

Acknowledgments The students in cs294s did a super job on their research projects. I am grateful to all of them of their hard work that lead to the results described here. I am also grateful for many conversations on this topic with Dre w Dean, Roger Dingledine, Pat Lincoln, Phil Porras, Ian Schuler and Vinod Yegneswaran. The author is supported by the Defense Advanced Research Project Agency (DARPA) and Space and Naval Warfare Systems Center Pacific under Contract No. N66001-11-C-4022. Any opinions, findings and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the Defense Advanced Research Project Agency and Space and Naval Warfare Systems Center Pacific.

Biography

Dan Boneh heads the applied cryptography group in the Computer Science Department at Stanford University. His research focuses on applications of cryptography to computer security. Boneh’s work includes cryptosystems with novel properties, security for handheld devices, Web security, digital copyright protection, and cryptanalysis. He is a recipient of the Packard Award, the Alfred P. Sloan A ward and the Terman Award.