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
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
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
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-
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://
•Free Haven’s selected papers in
anonymity, an online bibliography
on anonymity and filtering cir-
cumvention ; http://freehaven.net/
• The Open Net Initiative and
the Internet Censorship report;
• The 2011 Usenix workshop on Free
and Open Communications on the
• For a sample of recent research on
this topic see https://telex.cc
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
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
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.