| blob | 556be3295165986e5a5be0a765c65f32330d3585 |
3 <html>
29 Internet censorship is on the rise as websites around the world are
30 increasingly blocked by government-level firewalls. Although popular
31 anonymizing networks like Tor were originally designed to keep attackers from
32 tracing people's activities, many people are also using them to evade local
33 censorship. But if the censor simply denies access to the Tor network
34 itself, blocked users can no longer benefit from the security Tor offers.
37 Here we describe a design that builds upon the current Tor network
38 to provide an anonymizing network that resists blocking
39 by government-level attackers.
47 Anonymizing networks like Tor [<a href="#tor-design" name="CITEtor-design">11</a>] bounce traffic around a
49 is said, these networks also aim to hide who is communicating with whom, which
50 users are using which websites, and similar relations. These systems have a
51 broad range of users, including ordinary citizens who want to avoid being
52 profiled for targeted advertisements, corporations who don't want to reveal
53 information to their competitors, and law enforcement and government
54 intelligence agencies who need to do operations on the Internet without being
55 noticed.
58 Historical anonymity research has focused on an
59 attacker who monitors the user (call her Alice) and tries to discover her
60 activities, yet lets her reach any piece of the network. In more modern
61 threat models such as Tor's, the adversary is allowed to perform active
62 attacks such as modifying communications to trick Alice
63 into revealing her destination, or intercepting some connections
64 to run a man-in-the-middle attack. But these systems still assume that
65 Alice can eventually reach the anonymizing network.
68 An increasing number of users are using the Tor software
69 less for its anonymity properties than for its censorship
70 resistance properties — if they use Tor to access Internet sites like
71 Wikipedia
72 and Blogspot, they are no longer affected by local censorship
73 and firewall rules. In fact, an informal user study
74 showed China as the third largest user base
75 for Tor clients, with perhaps ten thousand people accessing the Tor
76 network from China each day.
79 The current Tor design is easy to block if the attacker controls Alice's
80 connection to the Tor network — by blocking the directory authorities,
81 by blocking all the server IP addresses in the directory, or by filtering
82 based on the fingerprint of the Tor TLS handshake. Here we describe an
83 extended design that builds upon the current Tor network to provide an
84 anonymizing
85 network that resists censorship as well as anonymity-breaking attacks.
88 describes the components of the current Tor design and how they can be
90 explains the features and drawbacks of the currently deployed solutions.
91 In sections <a href="#sec:bridges">5</a> through <a href="#sec:discovery">7</a>, we explore the
94 issues with maintaining connectivity and sustainability for the design.
97 recommendations.
109 </a>
112 To design an effective anti-censorship tool, we need a good model for the
113 goals and resources of the censors we are evading. Otherwise, we risk
114 spending our effort on keeping the adversaries from doing things they have no
115 interest in doing, and thwarting techniques they do not use.
116 The history of blocking-resistance designs is littered with conflicting
117 assumptions about what adversaries to expect and what problems are
118 in the critical path to a solution. Here we describe our best
119 understanding of the current situation around the world.
122 In the traditional security style, we aim to defeat a strong
123 attacker — if we can defend against this attacker, we inherit protection
124 against weaker attackers as well. After all, we want a general design
125 that will work for citizens of China, Thailand, and other censored
126 countries; for
127 whistleblowers in firewalled corporate networks; and for people in
128 unanticipated oppressive situations. In fact, by designing with
129 a variety of adversaries in mind, we can take advantage of the fact that
130 adversaries will be in different stages of the arms race at each location,
131 so a server blocked in one locale can still be useful in others.
134 We assume that the attackers' goals are somewhat complex.
138 <dt><b></b></dt>
139 <dd><li>The attacker would like to restrict the flow of certain kinds of
140 information, particularly when this information is seen as embarrassing to
141 those in power (such as information about rights violations or corruption),
142 or when it enables or encourages others to oppose them effectively (such as
143 information about opposition movements or sites that are used to organize
144 protests).</dd>
145 <dt><b></b></dt>
146 <dd><li>As a second-order effect, censors aim to chill citizens' behavior by
147 creating an impression that their online activities are monitored.</dd>
148 <dt><b></b></dt>
149 <dd><li>In some cases, censors make a token attempt to block a few sites for
150 obscenity, blasphemy, and so on, but their efforts here are mainly for
151 show. In other cases, they really do try hard to block such content.</dd>
152 <dt><b></b></dt>
153 <dd><li>Complete blocking (where nobody at all can ever download censored
154 content) is not a
155 goal. Attackers typically recognize that perfect censorship is not only
156 impossible, but unnecessary: if "undesirable" information is known only
157 to a small few, further censoring efforts can be focused elsewhere.</dd>
158 <dt><b></b></dt>
161 effective (because these tools impede the censors' information restriction
162 goals) and those tools that are highly visible (thus making the censors
163 look ineffectual to their citizens and their bosses).</dd>
164 <dt><b></b></dt>
166 blocked information is also not a goal, given the broadness of most
167 censorship regimes. This seems borne out by fact.<a href="#tthFtNtAAB" name="tthFrefAAB"><sup>1</sup></a></dd>
168 <dt><b></b></dt>
169 <dd><li>Producers and distributors of targeted information are in much
170 greater danger than consumers; the attacker would like to not only block
171 their work, but identify them for reprisal.</dd>
172 <dt><b></b></dt>
173 <dd><li>The censors (or their governments) would like to have a working, useful
174 Internet. There are economic, political, and social factors that prevent
175 them from "censoring" the Internet by outlawing it entirely, or by
176 blocking access to all but a tiny list of sites.
178 (like the bulk of a newspaper's reporting) in order to censor other content
179 distributed through the same channels (like that newspaper's coverage of
180 the censored country).
181 </dd>
182 </dl>
185 We assume there are three main technical network attacks in use by censors
192 <dt><b></b></dt>
193 <dd><li>Block a destination or type of traffic by automatically searching for
194 certain strings or patterns in TCP packets. Offending packets can be
195 dropped, or can trigger a response like closing the
196 connection.</dd>
197 <dt><b></b></dt>
198 <dd><li>Block a destination by listing its IP address at a
199 firewall or other routing control point.</dd>
200 <dt><b></b></dt>
201 <dd><li>Intercept DNS requests and give bogus responses for certain
202 destination hostnames.
203 </dd>
204 </dl>
207 We assume the network firewall has limited CPU and memory per
208 connection [<a href="#clayton:pet2006" name="CITEclayton:pet2006">7</a>]. Against an adversary who could carefully
209 examine the contents of every packet and correlate the packets in every
210 stream on the network, we would need some stronger mechanism such as
211 steganography, which introduces its own
212 problems [<a href="#active-wardens" name="CITEactive-wardens">15</a>,<a href="#tcpstego" name="CITEtcpstego">26</a>]. But we make a "weak
213 steganography" assumption here: to remain unblocked, it is necessary to
214 remain unobservable only by computational resources on par with a modern
215 router, firewall, proxy, or IDS.
218 We assume that while various different regimes can coordinate and share
219 notes, there will be a time lag between one attacker learning how to overcome
220 a facet of our design and other attackers picking it up. (The most common
221 vector of transmission seems to be commercial providers of censorship tools:
222 once a provider adds a feature to meet one country's needs or requests, the
223 feature is available to all of the provider's customers.) Conversely, we
224 assume that insider attacks become a higher risk only after the early stages
225 of network development, once the system has reached a certain level of
226 success and visibility.
229 We do not assume that government-level attackers are always uniform
230 across the country. For example, users of different ISPs in China
231 experience different censorship policies and mechanisms.
234 We assume that the attacker may be able to use political and economic
235 resources to secure the cooperation of extraterritorial or multinational
236 corporations and entities in investigating information sources.
237 For example, the censors can threaten the service providers of
238 troublesome blogs with economic reprisals if they do not reveal the
239 authors' identities.
242 We assume that our users have control over their hardware and
243 software — they don't have any spyware installed, there are no
244 cameras watching their screens, etc. Unfortunately, in many situations
245 these threats are real [<a href="#zuckerman-threatmodels" name="CITEzuckerman-threatmodels">28</a>]; yet
246 software-based security systems like ours are poorly equipped to handle
247 a user who is entirely observed and controlled by the adversary. See
249 we can do about this issue.
252 Similarly, we assume that the user will be able to fetch a genuine
253 version of Tor, rather than one supplied by the adversary; see
255 confirm that he has a genuine version and that he can connect to the
256 real Tor network.
262 </a>
265 Tor is popular and sees a lot of use — it's the largest anonymity
266 network of its kind, and has
267 attracted more than 800 volunteer-operated routers from around the
268 world. Tor protects each user by routing their traffic through a multiply
269 encrypted "circuit" built of a few randomly selected servers, each of which
270 can remove only a single layer of encryption. Each server sees only the step
271 before it and the step after it in the circuit, and so no single server can
272 learn the connection between a user and her chosen communication partners.
273 In this section, we examine some of the reasons why Tor has become popular,
274 with particular emphasis to how we can take advantage of these properties
275 for a blocking-resistance design.
278 Tor aims to provide three security properties:
282 <dt><b></b></dt>
284 destination.</dd>
285 <dt><b></b></dt>
287 destination.</dd>
288 <dt><b></b></dt>
290 can't learn your location.
291 </dd>
292 </dl>
295 For blocking-resistance, we care most clearly about the first
296 property. But as the arms race progresses, the second property
297 will become important — for example, to discourage an adversary
298 from volunteering a relay in order to learn that Alice is reading
299 or posting to certain websites. The third property helps keep users safe from
300 collaborating websites: consider websites and other Internet services
301 that have been pressured
302 recently into revealing the identity of bloggers
303 or treating clients differently depending on their network
307 The Tor design provides other features as well that are not typically
308 present in manual or ad hoc circumvention techniques.
311 First, Tor has a well-analyzed and well-understood way to distribute
312 information about servers.
313 Tor directory authorities automatically aggregate, test,
314 and publish signed summaries of the available Tor routers. Tor clients
315 can fetch these summaries to learn which routers are available and
316 which routers are suitable for their needs. Directory information is cached
317 throughout the Tor network, so once clients have bootstrapped they never
318 need to interact with the authorities directly. (To tolerate a minority
319 of compromised directory authorities, we use a threshold trust scheme —
323 Second, the list of directory authorities is not hard-wired.
324 Clients use the default authorities if no others are specified,
325 but it's easy to start a separate (or even overlapping) Tor network just
326 by running a different set of authorities and convincing users to prefer
327 a modified client. For example, we could launch a distinct Tor network
328 inside China; some users could even use an aggregate network made up of
329 both the main network and the China network. (But we should not be too
330 quick to create other Tor networks — part of Tor's anonymity comes from
331 users behaving like other users, and there are many unsolved anonymity
332 questions if different users know about different pieces of the network.)
335 Third, in addition to automatically learning from the chosen directories
336 which Tor routers are available and working, Tor takes care of building
337 paths through the network and rebuilding them as needed. So the user
338 never has to know how paths are chosen, never has to manually pick
339 working proxies, and so on. More generally, at its core the Tor protocol
340 is simply a tool that can build paths given a set of routers. Tor is
341 quite flexible about how it learns about the routers and how it chooses
342 the paths. Harvard's Blossom project [<a href="#blossom-thesis" name="CITEblossom-thesis">16</a>] makes this
343 flexibility more concrete: Blossom makes use of Tor not for its security
344 properties but for its reachability properties. It runs a separate set
345 of directory authorities, its own set of Tor routers (called the Blossom
346 network), and uses Tor's flexible path-building to let users view Internet
347 resources from any point in the Blossom network.
352 traffic between Tor users and Tor routers, and others choose to also allow
353 connections to external Internet resources. Because we don't force all
354 volunteers to play both roles, we end up with more relays. This increased
355 diversity in turn is what gives Tor its security: the more options the
356 user has for her first hop, and the more options she has for her last hop,
357 the less likely it is that a given attacker will be watching both ends
358 of her circuit [<a href="#tor-design" name="CITEtor-design">11</a>]. As a bonus, because our design attracts
359 more internal relays that want to help out but don't want to deal with
360 being an exit relay, we end up providing more options for the first
361 hop — the one most critical to being able to reach the Tor network.
364 Fifth, Tor is sustainable. Zero-Knowledge Systems offered the commercial
365 but now defunct Freedom Network [<a href="#freedom21-security" name="CITEfreedom21-security">2</a>], a design with
366 security comparable to Tor's, but its funding model relied on collecting
367 money from users to pay relay operators. Modern commercial proxy systems
368 similarly
369 need to keep collecting money to support their infrastructure. On the
370 other hand, Tor has built a self-sustaining community of volunteers who
371 donate their time and resources. This community trust is rooted in Tor's
372 open design: we tell the world exactly how Tor works, and we provide all
373 the source code. Users can decide for themselves, or pay any security
374 expert to decide, whether it is safe to use. Further, Tor's modularity
375 as described above, along with its open license, mean that its impact
376 will continue to grow.
379 Sixth, Tor has an established user base of hundreds of
380 thousands of people from around the world. This diversity of
381 users contributes to sustainability as above: Tor is used by
382 ordinary citizens, activists, corporations, law enforcement, and
383 even government and military users,
384 and they can
385 only achieve their security goals by blending together in the same
386 network [<a href="#econymics" name="CITEeconymics">1</a>,<a href="#usability:weis2006" name="CITEusability:weis2006">9</a>]. This user base also provides
387 something else: hundreds of thousands of different and often-changing
388 addresses that we can leverage for our blocking-resistance design.
391 Finally and perhaps most importantly, Tor provides anonymity and prevents any
392 single server from linking users to their communication partners. Despite
393 initial appearances, <i>distributed-trust anonymity is critical for
394 anti-censorship efforts</i>. If any single server can expose dissident bloggers
395 or compile a list of users' behavior, the censors can profitably compromise
396 that server's operator, perhaps by applying economic pressure to their
397 employers,
398 breaking into their computer, pressuring their family (if they have relatives
399 in the censored area), or so on. Furthermore, in designs where any relay can
400 expose its users, the censors can spread suspicion that they are running some
401 of the relays and use this belief to chill use of the network.
404 We discuss and adapt these components further in
406 weaknesses of other blocking-resistance approaches, so we can expand
407 our repertoire of building blocks and ideas.
413 </a>
416 Relay-based blocking-resistance schemes generally have two main
417 components: a relay component and a discovery component. The relay part
418 encompasses the process of establishing a connection, sending traffic
419 back and forth, and so on — everything that's done once the user knows
420 where she's going to connect. Discovery is the step before that: the
421 process of finding one or more usable relays.
424 For example, we can divide the pieces of Tor in the previous section
425 into the process of building paths and sending
426 traffic over them (relay) and the process of learning from the directory
427 servers about what routers are available (discovery). With this distinction
428 in mind, we now examine several categories of relay-based schemes.
435 Existing commercial anonymity solutions (like Anonymizer.com) are based
436 on a set of single-hop proxies. In these systems, each user connects to
437 a single proxy, which then relays traffic between the user and her
438 destination. These public proxy
439 systems are typically characterized by two features: they control and
440 operate the proxies centrally, and many different users get assigned
441 to each proxy.
444 In terms of the relay component, single proxies provide weak security
445 compared to systems that distribute trust over multiple relays, since a
446 compromised proxy can trivially observe all of its users' actions, and
447 an eavesdropper only needs to watch a single proxy to perform timing
448 correlation attacks against all its users' traffic and thus learn where
449 everyone is connecting. Worse, all users
450 need to trust the proxy company to have good security itself as well as
451 to not reveal user activities.
454 On the other hand, single-hop proxies are easier to deploy, and they
455 can provide better performance than distributed-trust designs like Tor,
456 since traffic only goes through one relay. They're also more convenient
457 from the user's perspective — since users entirely trust the proxy,
458 they can just use their web browser directly.
461 Whether public proxy schemes are more or less scalable than Tor is
462 still up for debate: commercial anonymity systems can use some of their
463 revenue to provision more bandwidth as they grow, whereas volunteer-based
464 anonymity systems can attract thousands of fast relays to spread the load.
467 The discovery piece can take several forms. Most commercial anonymous
468 proxies have one or a handful of commonly known websites, and their users
469 log in to those websites and relay their traffic through them. When
470 these websites get blocked (generally soon after the company becomes
471 popular), if the company cares about users in the blocked areas, they
472 start renting lots of disparate IP addresses and rotating through them
473 as they get blocked. They notify their users of new addresses (by email,
474 for example). It's an arms race, since attackers can sign up to receive the
475 email too, but operators have one nice trick available to them: because they
476 have a list of paying subscribers, they can notify certain subscribers
477 about updates earlier than others.
480 Access control systems on the proxy let them provide service only to
481 users with certain characteristics, such as paying customers or people
482 from certain IP address ranges.
485 Discovery in the face of a government-level firewall is a complex and
486 unsolved
487 topic, and we're stuck in this same arms race ourselves; we explore it
489 other end of the spectrum — getting volunteers to run the proxies,
490 and telling only a few people about each proxy.
497 Personal proxies such as Circumventor [<a href="#circumventor" name="CITEcircumventor">18</a>] and
498 CGIProxy [<a href="#cgiproxy" name="CITEcgiproxy">23</a>] use the same technology as the public ones as
499 far as the relay component goes, but they use a different strategy for
500 discovery. Rather than managing a few centralized proxies and constantly
501 getting new addresses for them as the old addresses are blocked, they
502 aim to have a large number of entirely independent proxies, each managing
503 its own (much smaller) set of users.
506 As the Circumventor site explains, "You don't
507 actually install the Circumventor <em>on</em> the computer that is blocked
508 from accessing Web sites. You, or a friend of yours, has to install the
509 Circumventor on some <em>other</em> machine which is not censored."
512 This tactic has great advantages in terms of blocking-resistance — recall
514 a system attracts from the attacker is proportional to its number of
515 users and level of publicity. If each proxy only has a few users, and
516 there is no central list of proxies, most of them will never get noticed by
517 the censors.
520 On the other hand, there's a huge scalability question that so far has
521 prevented these schemes from being widely useful: how does the fellow
522 in China find a person in Ohio who will run a Circumventor for him? In
523 some cases he may know and trust some people on the outside, but in many
524 cases he's just out of luck. Just as hard, how does a new volunteer in
525 Ohio find a person in China who needs it?
530 This challenge leads to a hybrid design-centrally — distributed
531 personal proxies — which we will investigate in more detail in
539 Yet another currently used approach to bypassing firewalls is to locate
540 open and misconfigured proxies on the Internet. A quick Google search
541 for "open proxy list" yields a wide variety of freely available lists
542 of HTTP, HTTPS, and SOCKS proxies. Many small companies have sprung up
543 providing more refined lists to paying customers.
546 There are some downsides to using these open proxies though. First,
547 the proxies are of widely varying quality in terms of bandwidth and
548 stability, and many of them are entirely unreachable. Second, unlike
549 networks of volunteers like Tor, the legality of routing traffic through
550 these proxies is questionable: it's widely believed that most of them
551 don't realize what they're offering, and probably wouldn't allow it if
552 they realized. Third, in many cases the connection to the proxy is
553 unencrypted, so firewalls that filter based on keywords in IP packets
554 will not be hindered. Fourth, in many countries (including China), the
555 firewall authorities hunt for open proxies as well, to preemptively
556 block them. And last, many users are suspicious that some
558 adversary, in which case they get to monitor all the user's requests
559 just as single-hop proxies can?
562 A distributed-trust design like Tor resolves each of these issues for
563 the relay component, but a constantly changing set of thousands of open
564 relays is clearly a useful idea for a discovery component. For example,
565 users might be able to make use of these proxies to bootstrap their
566 first introduction into the Tor network.
573 Köpsell and Hilling's Blocking Resistance
575 the closest related work, and is the starting point for the design in this
576 paper. In this design, the JAP anonymity system [<a href="#web-mix" name="CITEweb-mix">3</a>] is used
577 as a base instead of Tor. Volunteers operate a large number of access
578 points that relay traffic to the core JAP
579 network, which in turn anonymizes users' traffic. The software to run these
580 relays is, as in our design, included in the JAP client software and enabled
581 only when the user decides to enable it. Discovery is handled with a
582 CAPTCHA-based mechanism; users prove that they aren't an automated process,
583 and are given the address of an access point. (The problem of a determined
584 attacker with enough manpower to launch many requests and enumerate all the
585 access points is not considered in depth.) There is also some suggestion
586 that information about access points could spread through existing social
587 networks.
594 The Infranet design [<a href="#infranet" name="CITEinfranet">14</a>] uses one-hop relays to deliver web
595 content, but disguises its communications as ordinary HTTP traffic. Requests
596 are split into multiple requests for URLs on the relay, which then encodes
597 its responses in the content it returns. The relay needs to be an actual
598 website with plausible content and a number of URLs which the user might want
599 to access — if the Infranet software produced its own cover content, it would
600 be far easier for censors to identify. To keep the censors from noticing
601 that cover content changes depending on what data is embedded, Infranet needs
602 the cover content to have an innocuous reason for changing frequently: the
603 paper recommends watermarked images and webcams.
606 The attacker and relay operators in Infranet's threat model are significantly
607 different than in ours. Unlike our attacker, Infranet's censor can't be
608 bypassed with encrypted traffic (presumably because the censor blocks
609 encrypted traffic, or at least considers it suspicious), and has more
610 computational resources to devote to each connection than ours (so it can
611 notice subtle patterns over time). Unlike our bridge operators, Infranet's
612 operators (and users) have more bandwidth to spare; the overhead in typical
613 steganography schemes is far higher than Tor's.
616 The Infranet design does not include a discovery element. Discovery,
617 however, is a critical point: if whatever mechanism allows users to learn
618 about relays also allows the censor to do so, he can trivially discover and
619 block their addresses, even if the steganography would prevent mere traffic
620 observation from revealing the relays' addresses.
627 In their analysis of China's firewall's content-based blocking, Clayton,
628 Murdoch and Watson discovered that rather than blocking all packets in a TCP
629 streams once a forbidden word was noticed, the firewall was simply forging
630 RST packets to make the communicating parties believe that the connection was
631 closed [<a href="#clayton:pet2006" name="CITEclayton:pet2006">7</a>]. They proposed altering operating systems
632 to ignore forged RST packets. This approach might work in some cases, but
633 in practice it appears that many firewalls start filtering by IP address
634 once a sufficient number of RST packets have been sent.
637 Other packet-level responses to filtering include splitting
638 sensitive words across multiple TCP packets, so that the censors'
639 firewalls can't notice them without performing expensive stream
640 reconstruction [<a href="#ptacek98insertion" name="CITEptacek98insertion">27</a>]. This technique relies on the
641 same insight as our weak steganography assumption.
648 Freenet [<a href="#freenet-pets00" name="CITEfreenet-pets00">6</a>] is an anonymous peer-to-peer data store.
649 Analyzing Freenet's security can be difficult, as its design is in flux as
650 new discovery and routing mechanisms are proposed, and no complete
651 specification has (to our knowledge) been written. Freenet servers relay
652 requests for specific content (indexed by a digest of the content)
653 "toward" the server that hosts it, and then cache the content as it
654 follows the same path back to
655 the requesting user. If Freenet's routing mechanism is successful in
656 allowing nodes to learn about each other and route correctly even as some
657 node-to-node links are blocked by firewalls, then users inside censored areas
658 can ask a local Freenet server for a piece of content, and get an answer
659 without having to connect out of the country at all. Of course, operators of
660 servers inside the censored area can still be targeted, and the addresses of
661 external servers can still be blocked.
668 The popular Skype voice-over-IP software uses multiple techniques to tolerate
669 restrictive networks, some of which allow it to continue operating in the
670 presence of censorship. By switching ports and using encryption, Skype
671 attempts to resist trivial blocking and content filtering. Even if no
672 encryption were used, it would still be expensive to scan all voice
673 traffic for sensitive words. Also, most current keyloggers are unable to
674 store voice traffic. Nevertheless, Skype can still be blocked, especially at
675 its central login server.
682 And last, we include Tor itself in the list of current solutions
683 to firewalls. Tens of thousands of people use Tor from countries that
684 routinely filter their Internet. Tor's website has been blocked in most
685 of them. But why hasn't the Tor network been blocked yet?
688 We have several theories. The first is the most straightforward: tens of
689 thousands of people are simply too few to matter. It may help that Tor is
690 perceived to be for experts only, and thus not worth attention yet. The
691 more subtle variant on this theory is that we've positioned Tor in the
692 public eye as a tool for retaining civil liberties in more free countries,
693 so perhaps blocking authorities don't view it as a threat. (We revisit
694 this idea when we consider whether and how to publicize a Tor variant
696 for more discussion.)
699 The broader explanation is that the maintenance of most government-level
700 filters is aimed at stopping widespread information flow and appearing to be
701 in control, not by the impossible goal of blocking all possible ways to bypass
702 censorship. Censors realize that there will always
703 be ways for a few people to get around the firewall, and as long as Tor
704 has not publically threatened their control, they see no urgent need to
705 block it yet.
709 constraints can give us insight into the priorities and capabilities of
710 our various attackers.
716 </a>
720 well-suited as a building block in our context, but several changes will
721 allow the design to resist blocking better. The most critical changes are
722 to get more relay addresses, and to distribute them to users differently.
733 Today, Tor servers operate on less than a thousand distinct IP addresses;
734 an adversary
735 could enumerate and block them all with little trouble. To provide a
736 means of ingress to the network, we need a larger set of entry points, most
737 of which an adversary won't be able to enumerate easily. Fortunately, we
738 have such a set: the Tor users.
741 Hundreds of thousands of people around the world use Tor. We can leverage
742 our already self-selected user base to produce a list of thousands of
743 frequently-changing IP addresses. Specifically, we can give them a little
744 button in the GUI that says "Tor for Freedom", and users who click
746 for short). They can rate limit relayed connections to 10 KB/s (almost
747 nothing for a broadband user in a free country, but plenty for a user
748 who otherwise has no access at all), and since they are just relaying
749 bytes back and forth between blocked users and the main Tor network, they
750 won't need to make any external connections to Internet sites. Because
751 of this separation of roles, and because we're making use of software
752 that the volunteers have already installed for their own use, we expect
753 our scheme to attract and maintain more volunteers than previous schemes.
756 As usual, there are new anonymity and security implications from running a
757 bridge relay, particularly from letting people relay traffic through your
767 How do the bridge relays advertise their existence to the world? We
768 introduce a second new component of the design: a specialized directory
769 authority that aggregates and tracks bridges. Bridge relays periodically
770 publish server descriptors (summaries of their keys, locations, etc,
771 signed by their long-term identity key), just like the relays in the
772 "main" Tor network, but in this case they publish them only to the
773 bridge directory authorities.
776 The main difference between bridge authorities and the directory
777 authorities for the main Tor network is that the main authorities provide
778 a list of every known relay, but the bridge authorities only give
779 out a server descriptor if you already know its identity key. That is,
780 you can keep up-to-date on a bridge's location and other information
781 once you know about it, but you can't just grab a list of all the bridges.
784 The identity key, IP address, and directory port for each bridge
785 authority ship by default with the Tor software, so the bridge relays
786 can be confident they're publishing to the right location, and the
787 blocked users can establish an encrypted authenticated channel. See
789 infrastructure and trust chain.
792 Bridges use Tor to publish their descriptors privately and securely,
793 so even an attacker monitoring the bridge directory authority's network
794 can't make a list of all the addresses contacting the authority.
795 Bridges may publish to only a subset of the
796 authorities, to limit the potential impact of an authority compromise.
804 </a>
807 If a blocked user knows the identity keys of a set of bridge relays, and
808 he has correct address information for at least one of them, he can use
809 that one to make a secure connection to the bridge authority and update
810 his knowledge about the other bridge relays. He can also use it to make
811 secure connections to the main Tor network and directory servers, so he
812 can build circuits and connect to the rest of the Internet. All of these
813 updates happen in the background: from the blocked user's perspective,
814 he just accesses the Internet via his Tor client like always.
817 So now we've reduced the problem from how to circumvent the firewall
818 for all transactions (and how to know that the pages you get have not
819 been modified by the local attacker) to how to learn about a working
820 bridge relay.
823 There's another catch though. We need to make sure that the network
824 traffic we generate by simply connecting to a bridge relay doesn't stand
825 out too much.
836 </a>
837 </a>
840 Currently, Tor uses two protocols for its network communications. The
841 main protocol uses TLS for encrypted and authenticated communication
842 between Tor instances. The second protocol is standard HTTP, used for
843 fetching directory information. All Tor servers listen on their "ORPort"
844 for TLS connections, and some of them opt to listen on their "DirPort"
845 as well, to serve directory information. Tor servers choose whatever port
846 numbers they like; the server descriptor they publish to the directory
847 tells users where to connect.
850 One format for communicating address information about a bridge relay is
851 its IP address and DirPort. From there, the user can ask the bridge's
852 directory cache for an up-to-date copy of its server descriptor, and
853 learn its current circuit keys, its ORPort, and so on.
856 However, connecting directly to the directory cache involves a plaintext
857 HTTP request. A censor could create a network fingerprint (known as a
859 and/or its response, thus preventing these connections. To resolve this
860 vulnerability, we've modified the Tor protocol so that users can connect
861 to the directory cache via the main Tor port — they establish a TLS
862 connection with the bridge as normal, and then send a special "begindir"
863 relay command to establish an internal connection to its directory cache.
866 Therefore a better way to summarize a bridge's address is by its IP
867 address and ORPort, so all communications between the client and the
868 bridge will use ordinary TLS. But there are other details that need
869 more investigation.
872 What port should bridges pick for their ORPort? We currently recommend
873 that they listen on port 443 (the default HTTPS port) if they want to
874 be most useful, because clients behind standard firewalls will have
875 the best chance to reach them. Is this the best choice in all cases,
876 or should we encourage some fraction of them pick random ports, or other
878 (POP)? Or perhaps we should use other ports where TLS traffic is
880 potential users, and their current and anticipated firewall restrictions.
883 Furthermore, we need to look at the specifics of Tor's TLS handshake.
884 Right now Tor uses some predictable strings in its TLS handshakes. For
886 the Tor server's nickname in the certificate's commonName field. We
887 should tweak the handshake protocol so it doesn't rely on any unusual details
888 in the certificate, yet it remains secure; the certificate itself
889 should be made to resemble an ordinary HTTPS certificate. We should also try
890 to make our advertised cipher-suites closer to what an ordinary web server
891 would support.
894 Tor's TLS handshake uses two-certificate chains: one certificate
895 contains the self-signed identity key for
896 the router, and the second contains a current TLS key, signed by the
897 identity key. We use these to authenticate that we're talking to the right
898 router, and to limit the impact of TLS-key exposure. Most (though far from
899 all) consumer-oriented HTTPS services provide only a single certificate.
900 These extra certificates may help identify Tor's TLS handshake; instead,
901 bridges should consider using only a single TLS key certificate signed by
902 their identity key, and providing the full value of the identity key in an
903 early handshake cell. More significantly, Tor currently has all clients
904 present certificates, so that clients are harder to distinguish from servers.
905 But in a blocking-resistance environment, clients should not present
906 certificates at all.
909 Last, what if the adversary starts observing the network traffic even
910 more closely? Even if our TLS handshake looks innocent, our traffic timing
911 and volume still look different than a user making a secure web connection
912 to his bank. The same techniques used in the growing trend to build tools
913 to recognize encrypted Bittorrent traffic
914 could be used to identify Tor communication and recognize bridge
915 relays. Rather than trying to look like encrypted web traffic, we may be
916 better off trying to blend with some other encrypted network protocol. The
917 first step is to compare typical network behavior for a Tor client to
918 typical network behavior for various other protocols. This statistical
919 cat-and-mouse game is made more complex by the fact that Tor transports a
920 variety of protocols, and we'll want to automatically handle web browsing
921 differently from, say, instant messaging.
929 </a>
932 We have described a way for the blocked user to bootstrap into the
933 network once he knows the IP address and ORPort of a bridge. What about
934 local spoofing attacks? That is, since we never learned an identity
935 key fingerprint for the bridge, a local attacker could intercept our
936 connection and pretend to be the bridge we had in mind. It turns out
937 that giving false information isn't that bad — since the Tor client
938 ships with trusted keys for the bridge directory authority and the Tor
939 network directory authorities, the user can learn whether he's being
940 given a real connection to the bridge authorities or not. (After all,
941 if the adversary intercepts every connection the user makes and gives
942 him a bad connection each time, there's nothing we can do.)
945 What about anonymity-breaking attacks from observing traffic, if the
946 blocked user doesn't start out knowing the identity key of his intended
947 bridge? The vulnerabilities aren't so bad in this case either — the
948 adversary could do similar attacks just by monitoring the network
949 traffic.
952 Once the Tor client has fetched the bridge's server descriptor, it should
953 remember the identity key fingerprint for that bridge relay. Thus if
954 the bridge relay moves to a new IP address, the client can query the
955 bridge directory authority to look up a fresh server descriptor using
956 this fingerprint.
960 just by learning the IP address and ORPort of a bridge, but are there
961 situations where it's more convenient or more secure to learn the bridge's
962 identity fingerprint as well as instead, while bootstrapping? We keep
963 that question in mind as we next investigate bootstrapping and discovery.
969 </a>
972 Tor's modular design means that we can develop a better relay component
973 independently of developing the discovery component. This modularity's
974 great promise is that we can pick any discovery approach we like; but the
975 unfortunate fact is that we have no magic bullet for discovery. We're
976 in the same arms race as all the other designs we described in
980 In this section we describe a variety of approaches to adding discovery
981 components for our design.
987 </a>
991 a working bridge address can use it to reach the bridge authority and
992 to stay connected to the Tor network. But how do new users reach the
993 bridge authority in the first place? After all, the bridge authority
994 will be one of the first addresses that a censor blocks.
997 First, we should recognize that most government firewalls are not
998 perfect. That is, they may allow connections to Google cache or some
999 open proxy servers, or they let file-sharing traffic, Skype, instant
1000 messaging, or World-of-Warcraft connections through. Different users will
1001 have different mechanisms for bypassing the firewall initially. Second,
1002 we should remember that most people don't operate in a vacuum; users will
1003 hopefully know other people who are in other situations or have other
1004 resources available. In the rest of this section we develop a toolkit
1005 of different options and mechanisms, so that we can enable users in a
1006 diverse set of contexts to bootstrap into the system.
1009 (For users who can't use any of these techniques, hopefully they know
1010 a friend who can — for example, perhaps the friend already knows some
1011 bridge relay addresses. If they can't get around it at all, then we
1012 can't help them — they should go meet more people or learn more about
1013 the technology running the firewall in their area.)
1016 By deploying all the schemes in the toolkit at once, we let bridges and
1017 blocked users employ the discovery approach that is most appropriate
1018 for their situation.
1025 The first design is simply to have no centralized discovery component at
1026 all. Volunteers run bridges, and we assume they have some blocked users
1027 in mind and communicate their address information to them out-of-band
1028 (for example, through Gmail). This design allows for small personal
1029 bridges that have only one or a handful of users in mind, but it can
1030 also support an entire community of users. For example, Citizen Lab's
1031 upcoming Psiphon single-hop proxy tool [<a href="#psiphon" name="CITEpsiphon">13</a>] plans to use this
1035 There are several ways to do bootstrapping in this design. In the simple
1036 case, the operator of the bridge informs each chosen user about his
1037 bridge's address information and/or keys. A different approach involves
1038 blocked users introducing new blocked users to the bridges they know.
1039 That is, somebody in the blocked area can pass along a bridge's address to
1040 somebody else they trust. This scheme brings in appealing but complex game
1041 theoretic properties: the blocked user making the decision has an incentive
1042 only to delegate to trustworthy people, since an adversary who learns
1043 the bridge's address and filters it makes it unavailable for both of them.
1044 Also, delegating known bridges to members of your social network can be
1045 dangerous: an the adversary who can learn who knows which bridges may
1046 be able to reconstruct the social network.
1049 Note that a central set of bridge directory authorities can still be
1050 compatible with a decentralized discovery process. That is, how users
1051 first learn about bridges is entirely up to the bridges, but the process
1052 of fetching up-to-date descriptors for them can still proceed as described
1054 knows about all the bridges may not be smart, especially if every other
1055 piece of the system is decentralized. Further, if a user only knows
1056 about one bridge and he loses track of it, it may be quite a hassle to
1057 reach the bridge authority. We address these concerns next.
1064 Because the blocked users are running our software too, we have many
1065 opportunities to improve usability or robustness. Our second design builds
1066 on the first by encouraging volunteers to run several bridges at once
1067 (or coordinate with other bridge volunteers), such that some
1068 of the bridges are likely to be available at any given time.
1071 The blocked user's Tor client would periodically fetch an updated set of
1072 recommended bridges from any of the working bridges. Now the client can
1073 learn new additions to the bridge pool, and can expire abandoned bridges
1074 or bridges that the adversary has blocked, without the user ever needing
1075 to care. To simplify maintenance of the community's bridge pool, each
1076 community could run its own bridge directory authority — reachable via
1077 the available bridges, and also mirrored at each bridge.
1084 What about people who want to volunteer as bridges but don't know any
1085 suitable blocked users? What about people who are blocked but don't
1086 know anybody on the outside? Here we describe how to make use of these
1088 to learn all of them.
1091 The basic idea is to divide public bridges into a set of pools based on
1093 an approach to distributing its bridge addresses to users. Each strategy
1094 is designed to exercise a different scarce resource or property of
1095 the user.
1098 How do we divide bridges between these strategy pools such that they're
1099 evenly distributed and the allocation is hard to influence or predict,
1100 but also in a way that's amenable to creating more strategies later
1101 on without reshuffling all the pools? We assign a given bridge
1102 to a strategy pool by hashing the bridge's identity key along with a
1103 secret that only the bridge authority knows: the first n bits of this
1104 hash dictate the strategy pool number, where n is a parameter that
1105 describes how many strategy pools we want at this point. We choose n=3
1106 to start, so we divide bridges between 8 pools; but as we later invent
1107 new distribution strategies, we can increment n to split the 8 into
1108 16. Since a bridge can't predict the next bit in its hash, it can't
1109 anticipate which identity key will correspond to a certain new pool
1110 when the pools are split. Further, since the bridge authority doesn't
1111 provide any feedback to the bridge about which strategy pool it's in,
1112 an adversary who signs up bridges with the goal of filling a certain
1118 The first distribution strategy (used for the first pool) publishes bridge
1119 addresses in a time-release fashion. The bridge authority divides the
1120 available bridges into partitions, and each partition is deterministically
1121 available only in certain time windows. That is, over the course of a
1122 given time slot (say, an hour), each requester is given a random bridge
1123 from within that partition. When the next time slot arrives, a new set
1124 of bridges from the pool are available for discovery. Thus some bridge
1125 address is always available when a new
1126 user arrives, but to learn about all bridges the attacker needs to fetch
1127 all new addresses at every new time slot. By varying the length of the
1128 time slots, we can make it harder for the attacker to guess when to check
1129 back. We expect these bridges will be the first to be blocked, but they'll
1131 remember that we're dealing with different blocking regimes around the
1132 world that will progress at different rates — so this pool will still
1133 be useful to some users even as the arms races progress.
1136 The second distribution strategy publishes bridge addresses based on the IP
1137 address of the requesting user. Specifically, the bridge authority will
1138 divide the available bridges in the pool into a bunch of partitions
1139 (as in the first distribution scheme), hash the requester's IP address
1140 with a secret of its own (as in the above allocation scheme for creating
1141 pools), and give the requester a random bridge from the appropriate
1142 partition. To raise the bar, we should discard the last octet of the
1143 IP address before inputting it to the hash function, so an attacker
1144 who only controls a single "/24" network only counts as one user. A
1145 large attacker like China will still be able to control many addresses,
1146 but the hassle of establishing connections from each network (or spoofing
1147 TCP connections) may still slow them down. Similarly, as a special case,
1148 we should treat IP addresses that are Tor exit nodes as all being on
1149 the same network.
1152 The third strategy combines the time-based and location-based
1153 strategies to further constrain and rate-limit the available bridge
1154 addresses. Specifically, the bridge address provided in a given time
1155 slot to a given network location is deterministic within the partition,
1156 rather than chosen randomly each time from the partition. Thus, repeated
1157 requests during that time slot from a given network are given the same
1158 bridge address as the first request.
1161 The fourth strategy is based on Circumventor's discovery strategy.
1162 The Circumventor project, realizing that its adoption will remain limited
1163 if it has no central coordination mechanism, has started a mailing list to
1164 distribute new proxy addresses every few days. From experimentation it
1165 seems they have concluded that sending updates every three or four days
1166 is sufficient to stay ahead of the current attackers.
1169 The fifth strategy provides an alternative approach to a mailing list:
1170 users provide an email address and receive an automated response
1171 listing an available bridge address. We could limit one response per
1172 email address. To further rate limit queries, we could require a CAPTCHA
1173 solution
1174 in each case too. In fact, we wouldn't need to
1175 implement the CAPTCHA on our side: if we only deliver bridge addresses
1176 to Yahoo or GMail addresses, we can leverage the rate-limiting schemes
1177 that other parties already impose for account creation.
1180 The sixth strategy ties in the social network design with public
1181 bridges and a reputation system. We pick some seeds — trusted people in
1182 blocked areas — and give them each a few dozen bridge addresses and a few
1184 where users can log in (they connect via Tor, and they don't need to
1185 provide actual identities, just persistent pseudonyms). Users can delegate
1186 trust to other people they know by giving them a token, which can be
1187 exchanged for a new account on the website. Accounts in "good standing"
1188 then accrue new bridge addresses and new tokens. As usual, reputation
1189 schemes bring in a host of new complexities [<a href="#rep-anon" name="CITErep-anon">10</a>]: how do we
1190 decide that an account is in good standing? We could tie reputation
1191 to whether the bridges they're told about have been blocked — see
1193 whether bridges have been blocked. We could track reputation between
1194 accounts (if you delegate to somebody who screws up, it impacts you too),
1195 or we could use blinded delegation tokens [<a href="#chaum-blind" name="CITEchaum-blind">5</a>] to prevent
1196 the website from mapping the seeds' social network. We put off deeper
1197 discussion of the social network reputation strategy for future work.
1200 Pools seven and eight are held in reserve, in case our currently deployed
1201 tricks all fail at once and the adversary blocks all those bridges — so
1202 we can adapt and move to new approaches quickly, and have some bridges
1203 immediately available for the new schemes. New strategies might be based
1204 on some other scarce resource, such as relaying traffic for others or
1205 other proof of energy spent. (We might also worry about the incentives
1206 for bridges that sign up and get allocated to the reserve pools: will they
1207 be unhappy that they're not being used? But this is a transient problem:
1208 if Tor users are bridges by default, nobody will mind not being used yet.
1218 We presented the above discovery strategies in the context of a single
1219 bridge directory authority, but in practice we will want to distribute the
1220 operations over several bridge authorities — a single point of failure
1221 or attack is a bad move. The first answer is to run several independent
1222 bridge directory authorities, and bridges gravitate to one based on
1223 their identity key. The better answer would be some federation of bridge
1224 authorities that work together to provide redundancy but don't introduce
1225 new security issues. We could even imagine designs where the bridge
1226 authorities have encrypted versions of the bridge's server descriptors,
1227 and the users learn a decryption key that they keep private when they
1228 first hear about the bridge — this way the bridge authorities would not
1229 be able to learn the IP address of the bridges.
1232 We leave this design question for future work.
1239 Learning whether a bridge is useful is important in the bridge authority's
1240 decision to include it in responses to blocked users. For example, if
1241 we end up with a list of thousands of bridges and only a few dozen of
1242 them are reachable right now, most blocked users will not end up knowing
1243 about working bridges.
1246 There are three components for assessing how useful a bridge is. First,
1247 is it reachable from the public Internet? Second, what proportion of
1248 the time is it available? Third, is it blocked in certain jurisdictions?
1251 The first component can be tested just as we test reachability of
1252 ordinary Tor servers. Specifically, the bridges do a self-test — connect
1253 to themselves via the Tor network — before they are willing to
1254 publish their descriptor, to make sure they're not obviously broken or
1255 misconfigured. Once the bridges publish, the bridge authority also tests
1256 reachability to make sure they're not confused or outright lying.
1259 The second component can be measured and tracked by the bridge authority.
1260 By doing periodic reachability tests, we can get a sense of how often the
1261 bridge is available. More complex tests will involve bandwidth-intensive
1262 checks to force the bridge to commit resources in order to be counted as
1263 available. We need to evaluate how the relationship of uptime percentage
1264 should weigh into our choice of which bridges to advertise. We leave
1265 this to future work.
1268 The third component is perhaps the trickiest: with many different
1269 adversaries out there, how do we keep track of which adversaries have
1270 blocked which bridges, and how do we learn about new blocks as they
1271 occur? We examine this problem next.
1277 </a>
1280 There are two main mechanisms for testing whether bridges are reachable
1281 from inside each blocked area: active testing via users, and passive
1282 testing via bridges.
1285 In the case of active testing, certain users inside each area
1286 sign up as testing relays. The bridge authorities can then use a
1287 Blossom-like [<a href="#blossom-thesis" name="CITEblossom-thesis">16</a>] system to build circuits through them
1288 to each bridge and see if it can establish the connection. But how do
1289 we pick the users? If we ask random users to do the testing (or if we
1290 solicit volunteers from the users), the adversary should sign up so he
1291 can enumerate the bridges we test. Indeed, even if we hand-select our
1292 testers, the adversary might still discover their location and monitor
1293 their network activity to learn bridge addresses.
1296 Another answer is not to measure directly, but rather let the bridges
1297 report whether they're being used.
1298 Specifically, bridges should install a GeoIP database such as the public
1299 IP-To-Country list [<a href="#ip-to-country" name="CITEip-to-country">19</a>], and then periodically report to the
1300 bridge authorities which countries they're seeing use from. This data
1301 would help us track which countries are making use of the bridge design,
1302 and can also let us learn about new steps the adversary has taken in
1303 the arms race. (The compressed GeoIP database is only several hundred
1304 kilobytes, and we could even automate the update process by serving it
1305 from the bridge authorities.)
1306 More analysis of this passive reachability
1307 testing design is needed to resolve its many edge cases: for example,
1308 if a bridge stops seeing use from a certain area, does that mean the
1309 bridge is blocked or does that mean those users are asleep?
1312 There are many more problems with the general concept of detecting whether
1313 bridges are blocked. First, different zones of the Internet are blocked
1314 in different ways, and the actual firewall jurisdictions do not match
1315 country borders. Our bridge scheme could help us map out the topology
1316 of the censored Internet, but this is a huge task. More generally,
1317 if a bridge relay isn't reachable, is that because of a network block
1318 somewhere, because of a problem at the bridge relay, or just a temporary
1319 outage somewhere in between? And last, an attacker could poison our
1320 bridge database by signing up already-blocked bridges. In this case,
1321 if we're stingy giving out bridge addresses, users in that country won't
1322 learn working bridges.
1325 All of these issues are made more complex when we try to integrate this
1326 testing into our social network reputation system above.
1327 Since in that case we punish or reward users based on whether bridges
1328 get blocked, the adversary has new attacks to trick or bog down the
1329 reputation tracking. Indeed, the bridge authority doesn't even know
1330 what zone the blocked user is in, so do we blame him for any possible
1331 censored zone, or what?
1334 Clearly more analysis is required. The eventual solution will probably
1335 involve a combination of passive measurement via GeoIP and active
1336 measurement from trusted testers. More generally, we can use the passive
1337 feedback mechanism to track usage of the bridge network as a whole — which
1338 would let us respond to attacks and adapt the design, and it would also
1339 let the general public track the progress of the project.
1348 For once, we're not in the position of the defender: we don't have to
1349 defend against every possible filtering scheme; we just have to defend
1350 against at least one. On the flip side, the attacker is forced to guess
1351 how to allocate his resources to defend against each of these discovery
1352 strategies. So by deploying all of our strategies at once, we not only
1353 increase our chances of finding one that the adversary has difficulty
1355 in the face of an adversary with limited resources.
1387 </a>
1394 Many people speculate that installing and using a Tor client in areas with
1395 particularly extreme firewalls is a high risk — and the risk increases
1396 as the firewall gets more restrictive. This notion certain has merit, but
1397 there's
1398 a counter pressure as well: as the firewall gets more restrictive, more
1399 ordinary people behind it end up using Tor for more mainstream activities,
1400 such as learning
1401 about Wall Street prices or looking at pictures of women's ankles. So
1402 as the restrictive firewall pushes up the number of Tor users, the
1403 "typical" Tor user becomes more mainstream, and therefore mere
1404 use or possession of the Tor software is not so surprising.
1407 It's hard to say which of these pressures will ultimately win out,
1408 but we should keep both sides of the issue in mind.
1418 </a>
1421 Tor encrypts traffic on the local network, and it obscures the eventual
1422 destination of the communication, but it doesn't do much to obscure the
1423 traffic volume. In particular, a user publishing a home video will have a
1424 different network fingerprint than a user reading an online news article.
1426 publish material are in more danger, should we work to improve Tor's
1427 security in this situation?
1430 In the general case this is an extremely challenging task:
1432 are known where the adversary observes the origin and the
1433 destination of traffic and confirms that they are part of the
1434 same communication [<a href="#danezis:pet2004" name="CITEdanezis:pet2004">8</a>,<a href="#e2e-traffic" name="CITEe2e-traffic">24</a>]. Related are
1436 a few hundred popular websites, makes a set of "fingerprints" for each
1437 site, and then observes the target Tor client's traffic to look for
1438 a match [<a href="#pet05-bissias" name="CITEpet05-bissias">4</a>,<a href="#defensive-dropping" name="CITEdefensive-dropping">21</a>]. But can we do better
1439 against a limited adversary who just does coarse-grained sweeps looking
1440 for unusually prolific publishers?
1443 One answer is for bridge users to automatically send bursts of padding
1444 traffic periodically. (This traffic can be implemented in terms of
1445 long-range drop cells, which are already part of the Tor specification.)
1446 Of course, convincingly simulating an actual human publishing interesting
1447 content is a difficult arms race, but it may be worthwhile to at least
1448 start the race. More research remains.
1455 Against some attacks, relaying traffic for others can improve
1456 anonymity. The simplest example is an attacker who owns a small number
1457 of Tor servers. He will see a connection from the bridge, but he won't
1458 be able to know whether the connection originated there or was relayed
1459 from somebody else. More generally, the mere uncertainty of whether the
1460 traffic originated from that user may be helpful.
1463 There are some cases where it doesn't seem to help: if an attacker can
1464 watch all of the bridge's incoming and outgoing traffic, then it's easy
1465 to learn which connections were relayed and which started there. (In this
1466 case he still doesn't know the final destinations unless he is watching
1467 them too, but in this case bridges are no better off than if they were
1468 an ordinary client.)
1471 There are also some potential downsides to running a bridge. First, while
1472 we try to make it hard to enumerate all bridges, it's still possible to
1473 learn about some of them, and for some people just the fact that they're
1474 running one might signal to an attacker that they place a higher value
1475 on their anonymity. Second, there are some more esoteric attacks on Tor
1476 relays that are not as well-understood or well-tested — for example, an
1477 attacker may be able to "observe" whether the bridge is sending traffic
1478 even if he can't actually watch its network, by relaying traffic through
1479 it and noticing changes in traffic timing [<a href="#attack-tor-oak05" name="CITEattack-tor-oak05">25</a>]. On
1480 the other hand, it may be that limiting the bandwidth the bridge is
1481 willing to relay will allow this sort of attacker to determine if it's
1482 being used as a bridge but not easily learn whether it is adding traffic
1483 of its own.
1486 We also need to examine how entry guards fit in. Entry guards
1487 (a small set of nodes that are always used for the first
1488 step in a circuit) help protect against certain attacks
1489 where the attacker runs a few Tor servers and waits for
1490 the user to choose these servers as the beginning and end of her
1492 If the blocked user doesn't use the bridge's entry guards, then the bridge
1493 doesn't gain as much cover benefit. On the other hand, what design changes
1494 are needed for the blocked user to use the bridge's entry guards without
1495 learning what they are (this seems hard), and even if we solve that,
1496 do they then need to use the guards' guards and so on down the line?
1499 It is an open research question whether the benefits of running a bridge
1500 outweigh the risks. A lot of the decision rests on which attacks the
1501 users are most worried about. For most users, we don't think running a
1502 bridge relay will be that damaging, and it could help quite a bit.
1508 </a>
1511 Assuming that users have their own trusted hardware is not
1512 always reasonable.
1515 For Internet cafe Windows computers that let you attach your own USB key,
1516 a USB-based Tor image would be smart. There's Torpark, and hopefully
1517 there will be more thoroughly analyzed and trustworthy options down the
1518 road. Worries remain about hardware or software keyloggers and other
1519 spyware, as well as physical surveillance.
1522 If the system lets you boot from a CD or from a USB key, you can gain
1523 a bit more security by bringing a privacy LiveCD with you. (This
1524 approach isn't foolproof either of course, since hardware
1525 keyloggers and physical surveillance are still a worry).
1528 In fact, LiveCDs are also useful if it's your own hardware, since it's
1529 easier to avoid leaving private data and logs scattered around the
1530 system.
1538 </a>
1541 Tor's "public key infrastructure" provides a chain of trust to
1542 let users verify that they're actually talking to the right servers.
1543 There are four pieces to this trust chain.
1546 First, when Tor clients are establishing circuits, at each step
1547 they demand that the next Tor server in the path prove knowledge of
1548 its private key [<a href="#tor-design" name="CITEtor-design">11</a>]. This step prevents the first node
1549 in the path from just spoofing the rest of the path. Second, the
1550 Tor directory authorities provide a signed list of servers along with
1551 their public keys — so unless the adversary can control a threshold
1552 of directory authorities, he can't trick the Tor client into using other
1553 Tor servers. Third, the location and keys of the directory authorities,
1554 in turn, is hard-coded in the Tor source code — so as long as the user
1555 got a genuine version of Tor, he can know that he is using the genuine
1556 Tor network. And last, the source code and other packages are signed
1557 with the GPG keys of the Tor developers, so users can confirm that they
1558 did in fact download a genuine version of Tor.
1561 In the case of blocked users contacting bridges and bridge directory
1562 authorities, the same logic applies in parallel: the blocked users fetch
1563 information from both the bridge authorities and the directory authorities
1564 for the `main' Tor network, and they combine this information locally.
1567 How can a user in an oppressed country know that he has the correct
1568 key fingerprints for the developers? As with other security systems, it
1569 ultimately comes down to human interaction. The keys are signed by dozens
1570 of people around the world, and we have to hope that our users have met
1571 enough people in the PGP web of trust
1572 that they can learn
1573 the correct keys. For users that aren't connected to the global security
1574 community, though, this question remains a critical weakness.
1586 </a>
1594 learning one bridge address at a time. But if most bridges are ordinary
1595 Tor users on cable modem or DSL connection, many of them will disappear
1596 and/or move periodically. How many bridge relays should a blocked user
1597 know about so that she is likely to have at least one reachable at any
1598 given point? This is already a challenging problem if we only consider
1599 natural churn: the best approach is to see what bridges we attract in
1600 reality and measure their churn. We may also need to factor in a parameter
1601 for how quickly bridges get discovered and blocked by the attacker;
1602 we leave this for future work after we have more deployment experience.
1605 A related question is: if the bridge relays change IP addresses
1606 periodically, how often does the blocked user need to fetch updates in
1607 order to keep from being cut out of the loop?
1610 Once we have more experience and intuition, we should explore technical
1611 solutions to this problem too. For example, if the discovery strategies
1612 give out k bridge addresses rather than a single bridge address, perhaps
1613 we can improve robustness from the user perspective without significantly
1614 aiding the adversary. Rather than giving out a new random subset of k
1615 addresses at each point, we could bind them together into <em>bridge
1616 families</em>, so all users that learn about one member of the bridge family
1617 are told about the rest as well.
1620 This scheme may also help defend against attacks to map the set of
1621 bridges. That is, if all blocked users learn a random subset of bridges,
1622 the attacker should learn about a few bridges, monitor the country-level
1623 firewall for connections to them, then watch those users to see what
1624 other bridges they use, and repeat. By segmenting the bridge address
1625 space, we can limit the exposure of other users.
1631 </a>
1634 Another attacker we might be concerned about is that the attacker could
1635 just block all DSL and cablemodem network addresses, on the theory that
1636 they don't run any important services anyway. If most of our bridges
1637 are on these networks, this attack could really hurt.
1640 The first answer is to aim to get volunteers both from traditionally
1642 Since bridges don't need to be Tor exit nodes, as we improve our usability
1643 it seems quite feasible to get a lot of websites helping out.
1646 The second answer (not as practical) would be to encourage more use of
1647 consumer networks for popular and useful Internet services.
1650 A related attack we might worry about is based on large countries putting
1651 economic pressure on companies that want to expand their business. For
1652 example, what happens if Verizon wants to sell services in China, and
1653 China pressures Verizon to discourage its users in the free world from
1654 running bridges?
1661 If it's trivial to verify that a given address is operating as a bridge,
1662 and most bridges run on a predictable port, then it's conceivable our
1663 attacker could scan the whole Internet looking for bridges. (In fact,
1664 he can just concentrate on scanning likely networks like cablemodem
1666 above for
1667 related attacks.) It would be nice to slow down this attack. It would
1668 be even nicer to make it hard to learn whether we're a bridge without
1669 first knowing some secret. We call this general property <em>scanning
1670 resistance</em>, and it goes along with normalizing Tor's TLS handshake and
1671 network fingerprint.
1674 We could provide a password to the blocked user, and she (or her Tor
1675 client) provides a nonced hash of this password when she connects. We'd
1676 need to give her an ID key for the bridge too (in addition to the IP
1678 present the password until we've finished the TLS handshake, else it
1679 would look unusual. If Alice can authenticate the bridge before she
1680 tries to send her password, we can resist an adversary who pretends
1681 to be the bridge and launches a man-in-the-middle attack to learn the
1682 password. But even if she can't, we still resist against widespread
1683 scanning.
1686 How should the bridge behave if accessed without the correct
1687 authorization? Perhaps it should act like an unconfigured HTTPS server
1688 ("welcome to the default Apache page"), or maybe it should mirror
1689 and act like common websites, or websites randomly chosen from Google.
1692 We might assume that the attacker can recognize HTTPS connections that
1693 use self-signed certificates. (This process would be resource-intensive
1694 but not out of the realm of possibility.) But even in this case, many
1695 popular websites around the Internet use self-signed or just plain broken
1696 SSL certificates.
1708 </a>
1711 One of the traditional ways to get people to run software that benefits
1712 others is to give them motivation to install it themselves. An often
1713 suggested approach is to install it as a stunning screensaver so everybody
1714 will be pleased to run it. We take a similar approach here, by leveraging
1715 the fact that these users are already interested in protecting their
1716 own Internet traffic, so they will install and run the software.
1719 Eventually, we may be able to make all Tor users become bridges if they
1720 pass their self-reachability tests — the software and installers need
1721 more work on usability first, but we're making progress.
1724 In the mean time, we can make a snazzy network graph with
1726 emphasizes the connections the bridge user is currently relaying.
1746 </a>
1749 Many people working on this field want to publicize the existence
1750 and extent of censorship concurrently with the deployment of their
1751 circumvention software. The easy reason for this two-pronged push is
1752 to attract volunteers for running proxies in their systems; but in many
1753 cases their main goal is not to focus on actually allowing individuals
1754 to circumvent the firewall, but rather to educate the world about the
1755 censorship. The media also tries to do its part by broadcasting the
1756 existence of each new circumvention system.
1759 But at the same time, this publicity attracts the attention of the
1760 censors. We can slow down the arms race by not attracting as much
1761 attention, and just spreading by word of mouth. If our goal is to
1762 establish a solid social network of bridges and bridge users before
1763 the adversary gets involved, does this extra attention work to our
1764 disadvantage?
1771 One of the first censoring attacks against a system like ours is to
1772 block the website and make the software itself hard to find. Our system
1773 should work well once the user is running an authentic
1774 copy of Tor and has found a working bridge, but to get to that point
1775 we rely on their individual skills and ingenuity.
1778 Right now, most countries that block access to Tor block only the main
1779 website and leave mirrors and the network itself untouched.
1780 Falling back on word-of-mouth is always a good last resort, but we should
1781 also take steps to make sure it's relatively easy for users to get a copy,
1782 such as publicizing the mirrors more and making copies available through
1783 other media. We might also mirror the latest version of the software on
1784 each bridge, so users who hear about an honest bridge can get a good
1785 copy.
1794 </a>
1801 Assuming actually crossing the firewall is the risky part of the
1802 operation, can we have some bridge relays inside the blocked area too,
1803 and more established users can use them as relays so they don't need to
1804 communicate over the firewall directly at all? A simple example here is
1805 to make new blocked users into internal bridges also — so they sign up
1806 on the bridge authority as part of doing their query, and we give out
1807 their addresses
1808 rather than (or along with) the external bridge addresses. This design
1809 is a lot trickier because it brings in the complexity of whether the
1810 internal bridges will remain available, can maintain reachability with
1811 the outside world, etc.
1814 More complex future designs involve operating a separate Tor network
1816 that can be accessed by users of the internal Tor network but whose
1817 addresses are not published or findable, even by these users — to get
1818 from inside the firewall to the rest of the Internet. But this design
1819 requires directory authorities to run inside the blocked area too,
1820 and they would be a fine target to take down the network.
1828 </a>
1831 Technical solutions won't solve the whole censorship problem. After all,
1833 successful, even if technologies and tricks exist to get around them.
1834 However, having a strong technical solution is still necessary as one
1835 important piece of the puzzle.
1838 In this paper, we have shown that Tor provides a great set of building
1839 blocks to start from. The next steps are to deploy prototype bridges and
1840 bridge authorities, implement some of the proposed discovery strategies,
1841 and then observe the system in operation and get more intuition about
1842 the actual requirements and adversaries we're up against.
1850 Alessandro Acquisti, Roger Dingledine, and Paul Syverson.
1851 On the economics of anonymity.
1856 </dd>
1858 Adam Back, Ian Goldberg, and Adam Shostack.
1859 Freedom systems 2.1 security issues and analysis.
1860 White paper, Zero Knowledge Systems, Inc., May 2001.
1863 </dd>
1865 Oliver Berthold, Hannes Federrath, and Stefan Köpsell.
1866 Web MIXes: A system for anonymous and unobservable Internet
1867 access.
1869 Technologies: Workshop on Design Issue in Anonymity and Unobservability</em>.
1873 </dd>
1876 Privacy vulnerabilities in encrypted http streams.
1877 In <em>Proceedings of Privacy Enhancing Technologies workshop (PET
1880 <a href="http://prisms.cs.umass.edu/brian/pubs/bissias.liberatore.pet.2005.pdf"><tt>http://prisms.cs.umass.edu/brian/pubs/bissias.liberatore.pet.2005.pdf</tt></a>.
1883 </dd>
1885 David Chaum.
1886 Blind signatures for untraceable payments.
1891 </dd>
1893 Ian Clarke, Oskar Sandberg, Brandon Wiley, and Theodore W. Hong.
1894 Freenet: A distributed anonymous information storage and retrieval
1895 system.
1897 Technologies: Workshop on Design Issue in Anonymity and Unobservability</em>,
1901 </dd>
1904 Ignoring the great firewall of china.
1905 In <em>Proceedings of the Sixth Workshop on Privacy Enhancing
1907 <a href="http://www.cl.cam.ac.uk/~rnc1/ignoring.pdf"><tt>http://www.cl.cam.ac.uk/~rnc1/ignoring.pdf</tt></a>.
1910 </dd>
1912 George Danezis.
1913 The traffic analysis of continuous-time mixes.
1914 In David Martin and Andrei Serjantov, editors, <em>Privacy Enhancing
1916 <a href="http://www.cl.cam.ac.uk/users/gd216/cmm2.pdf"><tt>http://www.cl.cam.ac.uk/users/gd216/cmm2.pdf</tt></a>.
1919 </dd>
1921 Roger Dingledine and Nick Mathewson.
1922 Anonymity loves company: Usability and the network effect.
1923 In <em>Proceedings of the Fifth Workshop on the Economics of
1925 <a href="http://freehaven.net/doc/wupss04/usability.pdf"><tt>http://freehaven.net/doc/wupss04/usability.pdf</tt></a>.
1928 </dd>
1930 Roger Dingledine, Nick Mathewson, and Paul Syverson.
1931 Reputation in P2P Anonymity Systems.
1932 In <em>Proceedings of Workshop on Economics of Peer-to-Peer
1934 <a href="http://freehaven.net/doc/econp2p03/econp2p03.pdf"><tt>http://freehaven.net/doc/econp2p03/econp2p03.pdf</tt></a>.
1937 </dd>
1939 Roger Dingledine, Nick Mathewson, and Paul Syverson.
1940 Tor: The second-generation onion router.
1942 2004.
1946 </dd>
1948 Roger Dingledine and Paul Syverson.
1949 Reliable MIX Cascade Networks through Reputation.
1954 </dd>
1957 Psiphon.
1961 </dd>
1963 Nick Feamster, Magdalena Balazinska, Greg Harfst, Hari Balakrishnan, and David
1964 Karger.
1965 Infranet: Circumventing web censorship and surveillance.
1967 2002.
1968 <a href="http://nms.lcs.mit.edu/~feamster/papers/usenixsec2002.pdf"><tt>http://nms.lcs.mit.edu/~feamster/papers/usenixsec2002.pdf</tt></a>.
1971 </dd>
1973 Gina Fisk, Mike Fisk, Christos Papadopoulos, and Joshua Neil.
1974 Eliminating steganography in internet traffic with active wardens.
1975 In Fabien Petitcolas, editor, <em>Information Hiding Workshop (IH
1979 </dd>
1981 Geoffrey Goodell.
1983 PhD thesis, Harvard University, July 2006.
1984 <a href="http://afs.eecs.harvard.edu/~goodell/thesis.pdf"><tt>http://afs.eecs.harvard.edu/~goodell/thesis.pdf</tt></a>.
1987 </dd>
1989 Geoffrey Goodell and Paul Syverson.
1990 The right place at the right time: The use of network location in
1991 authentication and abuse prevention, 2006.
1992 Submitted.
1995 </dd>
1997 Bennett Haselton.
1998 How to install the Circumventor program.
2000 <a href="http://www.peacefire.org/circumventor/simple-circumventor-instructions.html"><tt>http://www.peacefire.org/circumventor/simple-circumventor-instructions.html</tt></a>.
2003 </dd>
2005 Ip-to-country database.
2006 <a href="http://ip-to-country.webhosting.info/"><tt>http://ip-to-country.webhosting.info/</tt></a>.
2009 </dd>
2011 Stefan Köpsell and Ulf Hilling.
2012 How to achieve blocking resistance for existing systems enabling
2013 anonymous web surfing.
2014 In <em>Proceedings of the Workshop on Privacy in the Electronic
2016 <a href="http://freehaven.net/anonbib/papers/p103-koepsell.pdf"><tt>http://freehaven.net/anonbib/papers/p103-koepsell.pdf</tt></a>.
2019 </dd>
2022 Timing analysis in low-latency mix-based systems.
2024 LNCS (forthcoming), 2004.
2027 </dd>
2029 Rebecca MacKinnon.
2030 Private communication, 2006.
2033 </dd>
2035 James Marshall.
2036 CGIProxy: HTTP/FTP Proxy in a CGI Script.
2037 <a href="http://www.jmarshall.com/tools/cgiproxy/"><tt>http://www.jmarshall.com/tools/cgiproxy/</tt></a>.
2040 </dd>
2042 Nick Mathewson and Roger Dingledine.
2043 Practical traffic analysis: Extending and resisting statistical
2044 disclosure.
2045 In David Martin and Andrei Serjantov, editors, <em>Privacy Enhancing
2047 <a href="http://freehaven.net/doc/e2e-traffic/e2e-traffic.pdf"><tt>http://freehaven.net/doc/e2e-traffic/e2e-traffic.pdf</tt></a>.
2050 </dd>
2052 Steven J. Murdoch and George Danezis.
2053 Low-cost traffic analysis of tor.
2057 </dd>
2059 Steven J. Murdoch and Stephen Lewis.
2060 Embedding covert channels into TCP/IP.
2061 In Mauro Barni, Jordi Herrera-Joancomartí, Stefan Katzenbeisser,
2064 Barcelona, Catalonia (Spain), June 2005. Springer-Verlag.
2067 </dd>
2070 Insertion, evasion, and denial of service: Eluding network intrusion
2071 detection.
2076 </dd>
2078 Ethan Zuckerman.
2079 We've got to adjust some of our threat models.
2080 <a href="http://www.ethanzuckerman.com/blog/?p=1019"><tt>http://www.ethanzuckerman.com/blog/?p=1019</tt></a>.</dd>
2081 </dl>
2093 like China, the authorities mainly go after people who publish materials
2094 and coordinate organized movements [<a href="#mackinnon-personal" name="CITEmackinnon-personal">22</a>].
2095 If they find that a
2096 user happens to be reading a site that should be blocked, the typical
2097 response is simply to block the site. Of course, even with an encrypted
2098 connection, the adversary may be able to distinguish readers from
2099 publishers by observing whether Alice is mostly downloading bytes or mostly
2100 uploading them — we discuss this issue more in
2103 <a name="tthFtNtAAC"></a><a href="#tthFrefAAC"><sup>2</sup></a><a href="http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ\#EntryGuards"><tt>http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#EntryGuards</tt></a>
2105 <a name="tthFtNtAAD"></a><a href="#tthFrefAAD"><sup>3</sup></a><a href="http://vidalia-project.net/"><tt>http://vidalia-project.net/</tt></a>
2106 <br /><br /><hr /><small>File translated from
2111 </html>