blocking.html 100 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511512513514515516517518519520521522523524525526527528529530531532533534535536537538539540541542543544545546547548549550551552553554555556557558559560561562563564565566567568569570571572573574575576577578579580581582583584585586587588589590591592593594595596597598599600601602603604605606607608609610611612613614615616617618619620621622623624625626627628629630631632633634635636637638639640641642643644645646647648649650651652653654655656657658659660661662663664665666667668669670671672673674675676677678679680681682683684685686687688689690691692693694695696697698699700701702703704705706707708709710711712713714715716717718719720721722723724725726727728729730731732733734735736737738739740741742743744745746747748749750751752753754755756757758759760761762763764765766767768769770771772773774775776777778779780781782783784785786787788789790791792793794795796797798799800801802803804805806807808809810811812813814815816817818819820821822823824825826827828829830831832833834835836837838839840841842843844845846847848849850851852853854855856857858859860861862863864865866867868869870871872873874875876877878879880881882883884885886887888889890891892893894895896897898899900901902903904905906907908909910911912913914915916917918919920921922923924925926927928929930931932933934935936937938939940941942943944945946947948949950951952953954955956957958959960961962963964965966967968969970971972973974975976977978979980981982983984985986987988989990991992993994995996997998999100010011002100310041005100610071008100910101011101210131014101510161017101810191020102110221023102410251026102710281029103010311032103310341035103610371038103910401041104210431044104510461047104810491050105110521053105410551056105710581059106010611062106310641065106610671068106910701071107210731074107510761077107810791080108110821083108410851086108710881089109010911092109310941095109610971098109911001101110211031104110511061107110811091110111111121113111411151116111711181119112011211122112311241125112611271128112911301131113211331134113511361137113811391140114111421143114411451146114711481149115011511152115311541155115611571158115911601161116211631164116511661167116811691170117111721173117411751176117711781179118011811182118311841185118611871188118911901191119211931194119511961197119811991200120112021203120412051206120712081209121012111212121312141215121612171218121912201221122212231224122512261227122812291230123112321233123412351236123712381239124012411242124312441245124612471248124912501251125212531254125512561257125812591260126112621263126412651266126712681269127012711272127312741275127612771278127912801281128212831284128512861287128812891290129112921293129412951296129712981299130013011302130313041305130613071308130913101311131213131314131513161317131813191320132113221323132413251326132713281329133013311332133313341335133613371338133913401341134213431344134513461347134813491350135113521353135413551356135713581359136013611362136313641365136613671368136913701371137213731374137513761377137813791380138113821383138413851386138713881389139013911392139313941395139613971398139914001401140214031404140514061407140814091410141114121413141414151416141714181419142014211422142314241425142614271428142914301431143214331434143514361437143814391440144114421443144414451446144714481449145014511452145314541455145614571458145914601461146214631464146514661467146814691470147114721473147414751476147714781479148014811482148314841485148614871488148914901491149214931494149514961497149814991500150115021503150415051506150715081509151015111512151315141515151615171518151915201521152215231524152515261527152815291530153115321533153415351536153715381539154015411542154315441545154615471548154915501551155215531554155515561557155815591560156115621563156415651566156715681569157015711572157315741575157615771578157915801581158215831584158515861587158815891590159115921593159415951596159715981599160016011602160316041605160616071608160916101611161216131614161516161617161816191620162116221623162416251626162716281629163016311632163316341635163616371638163916401641164216431644164516461647164816491650165116521653165416551656165716581659166016611662166316641665166616671668166916701671167216731674167516761677167816791680168116821683168416851686168716881689169016911692169316941695169616971698169917001701170217031704170517061707170817091710171117121713171417151716171717181719172017211722172317241725172617271728172917301731173217331734173517361737173817391740174117421743174417451746174717481749175017511752175317541755175617571758175917601761176217631764176517661767176817691770177117721773177417751776177717781779178017811782178317841785178617871788178917901791179217931794179517961797179817991800180118021803180418051806180718081809181018111812181318141815181618171818181918201821182218231824182518261827182818291830183118321833183418351836183718381839184018411842184318441845184618471848184918501851185218531854185518561857185818591860186118621863186418651866186718681869187018711872187318741875187618771878187918801881188218831884188518861887188818891890189118921893189418951896189718981899190019011902190319041905190619071908190919101911191219131914191519161917191819191920192119221923192419251926192719281929193019311932193319341935193619371938193919401941194219431944194519461947194819491950195119521953195419551956195719581959196019611962196319641965196619671968196919701971197219731974197519761977197819791980198119821983198419851986198719881989199019911992199319941995199619971998199920002001200220032004200520062007200820092010201120122013201420152016201720182019202020212022202320242025202620272028202920302031203220332034203520362037203820392040204120422043204420452046204720482049205020512052205320542055205620572058205920602061206220632064206520662067206820692070207120722073207420752076207720782079208020812082208320842085208620872088208920902091209220932094209520962097209820992100210121022103210421052106210721082109211021112112
  1. <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
  2. "DTD/xhtml1-transitional.dtd">
  3. <html>
  4. <meta name="GENERATOR" content="TtH 3.77">
  5. <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
  6. <style type="text/css"> div.p { margin-top: 7pt;}</style>
  7. <style type="text/css"><!--
  8. td div.comp { margin-top: -0.6ex; margin-bottom: -1ex;}
  9. td div.comb { margin-top: -0.6ex; margin-bottom: -.6ex;}
  10. td div.hrcomp { line-height: 0.9; margin-top: -0.8ex; margin-bottom: -1ex;}
  11. td div.norm {line-height:normal;}
  12. span.roman {font-family: serif; font-style: normal; font-weight: normal;}
  13. span.overacc2 {position: relative; left: .8em; top: -1.2ex;}
  14. span.overacc1 {position: relative; left: .6em; top: -1.2ex;} --></style>
  15. <title> Design of a blocking-resistant anonymity system\DRAFT</title>
  16. <h1 align="center">Design of a blocking-resistant anonymity system<br />DRAFT </h1>
  17. <div class="p"><!----></div>
  18. <h3 align="center">Roger Dingledine, Nick Mathewson </h3>
  19. <div class="p"><!----></div>
  20. <h2> Abstract</h2>
  21. Internet censorship is on the rise as websites around the world are
  22. increasingly blocked by government-level firewalls. Although popular
  23. anonymizing networks like Tor were originally designed to keep attackers from
  24. tracing people's activities, many people are also using them to evade local
  25. censorship. But if the censor simply denies access to the Tor network
  26. itself, blocked users can no longer benefit from the security Tor offers.
  27. <div class="p"><!----></div>
  28. Here we describe a design that builds upon the current Tor network
  29. to provide an anonymizing network that resists blocking
  30. by government-level attackers.
  31. <div class="p"><!----></div>
  32. <h2><a name="tth_sEc1">
  33. 1</a>&nbsp;&nbsp;Introduction and Goals</h2>
  34. <div class="p"><!----></div>
  35. Anonymizing networks like Tor&nbsp;[<a href="#tor-design" name="CITEtor-design">11</a>] bounce traffic around a
  36. network of encrypting relays. Unlike encryption, which hides only <i>what</i>
  37. is said, these networks also aim to hide who is communicating with whom, which
  38. users are using which websites, and similar relations. These systems have a
  39. broad range of users, including ordinary citizens who want to avoid being
  40. profiled for targeted advertisements, corporations who don't want to reveal
  41. information to their competitors, and law enforcement and government
  42. intelligence agencies who need to do operations on the Internet without being
  43. noticed.
  44. <div class="p"><!----></div>
  45. Historical anonymity research has focused on an
  46. attacker who monitors the user (call her Alice) and tries to discover her
  47. activities, yet lets her reach any piece of the network. In more modern
  48. threat models such as Tor's, the adversary is allowed to perform active
  49. attacks such as modifying communications to trick Alice
  50. into revealing her destination, or intercepting some connections
  51. to run a man-in-the-middle attack. But these systems still assume that
  52. Alice can eventually reach the anonymizing network.
  53. <div class="p"><!----></div>
  54. An increasing number of users are using the Tor software
  55. less for its anonymity properties than for its censorship
  56. resistance properties &mdash; if they use Tor to access Internet sites like
  57. Wikipedia
  58. and Blogspot, they are no longer affected by local censorship
  59. and firewall rules. In fact, an informal user study
  60. showed China as the third largest user base
  61. for Tor clients, with perhaps ten thousand people accessing the Tor
  62. network from China each day.
  63. <div class="p"><!----></div>
  64. The current Tor design is easy to block if the attacker controls Alice's
  65. connection to the Tor network &mdash; by blocking the directory authorities,
  66. by blocking all the server IP addresses in the directory, or by filtering
  67. based on the fingerprint of the Tor TLS handshake. Here we describe an
  68. extended design that builds upon the current Tor network to provide an
  69. anonymizing
  70. network that resists censorship as well as anonymity-breaking attacks.
  71. In section&nbsp;<a href="#sec:adversary">2</a> we discuss our threat model &mdash; that is,
  72. the assumptions we make about our adversary. Section&nbsp;<a href="#sec:current-tor">3</a>
  73. describes the components of the current Tor design and how they can be
  74. leveraged for a new blocking-resistant design. Section&nbsp;<a href="#sec:related">4</a>
  75. explains the features and drawbacks of the currently deployed solutions.
  76. In sections&nbsp;<a href="#sec:bridges">5</a> through&nbsp;<a href="#sec:discovery">7</a>, we explore the
  77. components of our designs in detail. Section&nbsp;<a href="#sec:security">8</a> considers
  78. security implications and Section&nbsp;<a href="#sec:reachability">9</a> presents other
  79. issues with maintaining connectivity and sustainability for the design.
  80. Section&nbsp;<a href="#sec:future">10</a> speculates about future more complex designs,
  81. and finally Section&nbsp;<a href="#sec:conclusion">11</a> summarizes our next steps and
  82. recommendations.
  83. <div class="p"><!----></div>
  84. <div class="p"><!----></div>
  85. <div class="p"><!----></div>
  86. <div class="p"><!----></div>
  87. <h2><a name="tth_sEc2">
  88. <a name="sec:adversary">
  89. 2</a>&nbsp;&nbsp;Adversary assumptions</h2>
  90. </a>
  91. <div class="p"><!----></div>
  92. To design an effective anti-censorship tool, we need a good model for the
  93. goals and resources of the censors we are evading. Otherwise, we risk
  94. spending our effort on keeping the adversaries from doing things they have no
  95. interest in doing, and thwarting techniques they do not use.
  96. The history of blocking-resistance designs is littered with conflicting
  97. assumptions about what adversaries to expect and what problems are
  98. in the critical path to a solution. Here we describe our best
  99. understanding of the current situation around the world.
  100. <div class="p"><!----></div>
  101. In the traditional security style, we aim to defeat a strong
  102. attacker &mdash; if we can defend against this attacker, we inherit protection
  103. against weaker attackers as well. After all, we want a general design
  104. that will work for citizens of China, Thailand, and other censored
  105. countries; for
  106. whistleblowers in firewalled corporate networks; and for people in
  107. unanticipated oppressive situations. In fact, by designing with
  108. a variety of adversaries in mind, we can take advantage of the fact that
  109. adversaries will be in different stages of the arms race at each location,
  110. so a server blocked in one locale can still be useful in others.
  111. <div class="p"><!----></div>
  112. We assume that the attackers' goals are somewhat complex.
  113. <dl compact="compact">
  114. <dt><b></b></dt>
  115. <dd><li>The attacker would like to restrict the flow of certain kinds of
  116. information, particularly when this information is seen as embarrassing to
  117. those in power (such as information about rights violations or corruption),
  118. or when it enables or encourages others to oppose them effectively (such as
  119. information about opposition movements or sites that are used to organize
  120. protests).</dd>
  121. <dt><b></b></dt>
  122. <dd><li>As a second-order effect, censors aim to chill citizens' behavior by
  123. creating an impression that their online activities are monitored.</dd>
  124. <dt><b></b></dt>
  125. <dd><li>In some cases, censors make a token attempt to block a few sites for
  126. obscenity, blasphemy, and so on, but their efforts here are mainly for
  127. show. In other cases, they really do try hard to block such content.</dd>
  128. <dt><b></b></dt>
  129. <dd><li>Complete blocking (where nobody at all can ever download censored
  130. content) is not a
  131. goal. Attackers typically recognize that perfect censorship is not only
  132. impossible, but unnecessary: if "undesirable" information is known only
  133. to a small few, further censoring efforts can be focused elsewhere.</dd>
  134. <dt><b></b></dt>
  135. <dd><li>Similarly, the censors are not attempting to shut down or block <i>
  136. every</i> anti-censorship tool &mdash; merely the tools that are popular and
  137. effective (because these tools impede the censors' information restriction
  138. goals) and those tools that are highly visible (thus making the censors
  139. look ineffectual to their citizens and their bosses).</dd>
  140. <dt><b></b></dt>
  141. <dd><li>Reprisal against <i>most</i> passive consumers of <i>most</i> kinds of
  142. blocked information is also not a goal, given the broadness of most
  143. censorship regimes. This seems borne out by fact.<a href="#tthFtNtAAB" name="tthFrefAAB"><sup>1</sup></a></dd>
  144. <dt><b></b></dt>
  145. <dd><li>Producers and distributors of targeted information are in much
  146. greater danger than consumers; the attacker would like to not only block
  147. their work, but identify them for reprisal.</dd>
  148. <dt><b></b></dt>
  149. <dd><li>The censors (or their governments) would like to have a working, useful
  150. Internet. There are economic, political, and social factors that prevent
  151. them from "censoring" the Internet by outlawing it entirely, or by
  152. blocking access to all but a tiny list of sites.
  153. Nevertheless, the censors <i>are</i> willing to block innocuous content
  154. (like the bulk of a newspaper's reporting) in order to censor other content
  155. distributed through the same channels (like that newspaper's coverage of
  156. the censored country).
  157. </dd>
  158. </dl>
  159. <div class="p"><!----></div>
  160. We assume there are three main technical network attacks in use by censors
  161. currently&nbsp;[<a href="#clayton:pet2006" name="CITEclayton:pet2006">7</a>]:
  162. <div class="p"><!----></div>
  163. <dl compact="compact">
  164. <dt><b></b></dt>
  165. <dd><li>Block a destination or type of traffic by automatically searching for
  166. certain strings or patterns in TCP packets. Offending packets can be
  167. dropped, or can trigger a response like closing the
  168. connection.</dd>
  169. <dt><b></b></dt>
  170. <dd><li>Block a destination by listing its IP address at a
  171. firewall or other routing control point.</dd>
  172. <dt><b></b></dt>
  173. <dd><li>Intercept DNS requests and give bogus responses for certain
  174. destination hostnames.
  175. </dd>
  176. </dl>
  177. <div class="p"><!----></div>
  178. We assume the network firewall has limited CPU and memory per
  179. connection&nbsp;[<a href="#clayton:pet2006" name="CITEclayton:pet2006">7</a>]. Against an adversary who could carefully
  180. examine the contents of every packet and correlate the packets in every
  181. stream on the network, we would need some stronger mechanism such as
  182. steganography, which introduces its own
  183. problems&nbsp;[<a href="#active-wardens" name="CITEactive-wardens">15</a>,<a href="#tcpstego" name="CITEtcpstego">26</a>]. But we make a "weak
  184. steganography" assumption here: to remain unblocked, it is necessary to
  185. remain unobservable only by computational resources on par with a modern
  186. router, firewall, proxy, or IDS.
  187. <div class="p"><!----></div>
  188. We assume that while various different regimes can coordinate and share
  189. notes, there will be a time lag between one attacker learning how to overcome
  190. a facet of our design and other attackers picking it up. (The most common
  191. vector of transmission seems to be commercial providers of censorship tools:
  192. once a provider adds a feature to meet one country's needs or requests, the
  193. feature is available to all of the provider's customers.) Conversely, we
  194. assume that insider attacks become a higher risk only after the early stages
  195. of network development, once the system has reached a certain level of
  196. success and visibility.
  197. <div class="p"><!----></div>
  198. We do not assume that government-level attackers are always uniform
  199. across the country. For example, users of different ISPs in China
  200. experience different censorship policies and mechanisms.
  201. <div class="p"><!----></div>
  202. We assume that the attacker may be able to use political and economic
  203. resources to secure the cooperation of extraterritorial or multinational
  204. corporations and entities in investigating information sources.
  205. For example, the censors can threaten the service providers of
  206. troublesome blogs with economic reprisals if they do not reveal the
  207. authors' identities.
  208. <div class="p"><!----></div>
  209. We assume that our users have control over their hardware and
  210. software &mdash; they don't have any spyware installed, there are no
  211. cameras watching their screens, etc. Unfortunately, in many situations
  212. these threats are real&nbsp;[<a href="#zuckerman-threatmodels" name="CITEzuckerman-threatmodels">28</a>]; yet
  213. software-based security systems like ours are poorly equipped to handle
  214. a user who is entirely observed and controlled by the adversary. See
  215. Section&nbsp;<a href="#subsec:cafes-and-livecds">8.4</a> for more discussion of what little
  216. we can do about this issue.
  217. <div class="p"><!----></div>
  218. Similarly, we assume that the user will be able to fetch a genuine
  219. version of Tor, rather than one supplied by the adversary; see
  220. Section&nbsp;<a href="#subsec:trust-chain">8.5</a> for discussion on helping the user
  221. confirm that he has a genuine version and that he can connect to the
  222. real Tor network.
  223. <div class="p"><!----></div>
  224. <h2><a name="tth_sEc3">
  225. <a name="sec:current-tor">
  226. 3</a>&nbsp;&nbsp;Adapting the current Tor design to anti-censorship</h2>
  227. </a>
  228. <div class="p"><!----></div>
  229. Tor is popular and sees a lot of use &mdash; it's the largest anonymity
  230. network of its kind, and has
  231. attracted more than 800 volunteer-operated routers from around the
  232. world. Tor protects each user by routing their traffic through a multiply
  233. encrypted "circuit" built of a few randomly selected servers, each of which
  234. can remove only a single layer of encryption. Each server sees only the step
  235. before it and the step after it in the circuit, and so no single server can
  236. learn the connection between a user and her chosen communication partners.
  237. In this section, we examine some of the reasons why Tor has become popular,
  238. with particular emphasis to how we can take advantage of these properties
  239. for a blocking-resistance design.
  240. <div class="p"><!----></div>
  241. Tor aims to provide three security properties:
  242. <dl compact="compact">
  243. <dt><b></b></dt>
  244. <dd>1. A local network attacker can't learn, or influence, your
  245. destination.</dd>
  246. <dt><b></b></dt>
  247. <dd>2. No single router in the Tor network can link you to your
  248. destination.</dd>
  249. <dt><b></b></dt>
  250. <dd>3. The destination, or somebody watching the destination,
  251. can't learn your location.
  252. </dd>
  253. </dl>
  254. <div class="p"><!----></div>
  255. For blocking-resistance, we care most clearly about the first
  256. property. But as the arms race progresses, the second property
  257. will become important &mdash; for example, to discourage an adversary
  258. from volunteering a relay in order to learn that Alice is reading
  259. or posting to certain websites. The third property helps keep users safe from
  260. collaborating websites: consider websites and other Internet services
  261. that have been pressured
  262. recently into revealing the identity of bloggers
  263. or treating clients differently depending on their network
  264. location&nbsp;[<a href="#goodell-syverson06" name="CITEgoodell-syverson06">17</a>].
  265. <div class="p"><!----></div>
  266. The Tor design provides other features as well that are not typically
  267. present in manual or ad hoc circumvention techniques.
  268. <div class="p"><!----></div>
  269. First, Tor has a well-analyzed and well-understood way to distribute
  270. information about servers.
  271. Tor directory authorities automatically aggregate, test,
  272. and publish signed summaries of the available Tor routers. Tor clients
  273. can fetch these summaries to learn which routers are available and
  274. which routers are suitable for their needs. Directory information is cached
  275. throughout the Tor network, so once clients have bootstrapped they never
  276. need to interact with the authorities directly. (To tolerate a minority
  277. of compromised directory authorities, we use a threshold trust scheme &mdash;
  278. see Section&nbsp;<a href="#subsec:trust-chain">8.5</a> for details.)
  279. <div class="p"><!----></div>
  280. Second, the list of directory authorities is not hard-wired.
  281. Clients use the default authorities if no others are specified,
  282. but it's easy to start a separate (or even overlapping) Tor network just
  283. by running a different set of authorities and convincing users to prefer
  284. a modified client. For example, we could launch a distinct Tor network
  285. inside China; some users could even use an aggregate network made up of
  286. both the main network and the China network. (But we should not be too
  287. quick to create other Tor networks &mdash; part of Tor's anonymity comes from
  288. users behaving like other users, and there are many unsolved anonymity
  289. questions if different users know about different pieces of the network.)
  290. <div class="p"><!----></div>
  291. Third, in addition to automatically learning from the chosen directories
  292. which Tor routers are available and working, Tor takes care of building
  293. paths through the network and rebuilding them as needed. So the user
  294. never has to know how paths are chosen, never has to manually pick
  295. working proxies, and so on. More generally, at its core the Tor protocol
  296. is simply a tool that can build paths given a set of routers. Tor is
  297. quite flexible about how it learns about the routers and how it chooses
  298. the paths. Harvard's Blossom project&nbsp;[<a href="#blossom-thesis" name="CITEblossom-thesis">16</a>] makes this
  299. flexibility more concrete: Blossom makes use of Tor not for its security
  300. properties but for its reachability properties. It runs a separate set
  301. of directory authorities, its own set of Tor routers (called the Blossom
  302. network), and uses Tor's flexible path-building to let users view Internet
  303. resources from any point in the Blossom network.
  304. <div class="p"><!----></div>
  305. Fourth, Tor separates the role of <em>internal relay</em> from the
  306. role of <em>exit relay</em>. That is, some volunteers choose just to relay
  307. traffic between Tor users and Tor routers, and others choose to also allow
  308. connections to external Internet resources. Because we don't force all
  309. volunteers to play both roles, we end up with more relays. This increased
  310. diversity in turn is what gives Tor its security: the more options the
  311. user has for her first hop, and the more options she has for her last hop,
  312. the less likely it is that a given attacker will be watching both ends
  313. of her circuit&nbsp;[<a href="#tor-design" name="CITEtor-design">11</a>]. As a bonus, because our design attracts
  314. more internal relays that want to help out but don't want to deal with
  315. being an exit relay, we end up providing more options for the first
  316. hop &mdash; the one most critical to being able to reach the Tor network.
  317. <div class="p"><!----></div>
  318. Fifth, Tor is sustainable. Zero-Knowledge Systems offered the commercial
  319. but now defunct Freedom Network&nbsp;[<a href="#freedom21-security" name="CITEfreedom21-security">2</a>], a design with
  320. security comparable to Tor's, but its funding model relied on collecting
  321. money from users to pay relay operators. Modern commercial proxy systems
  322. similarly
  323. need to keep collecting money to support their infrastructure. On the
  324. other hand, Tor has built a self-sustaining community of volunteers who
  325. donate their time and resources. This community trust is rooted in Tor's
  326. open design: we tell the world exactly how Tor works, and we provide all
  327. the source code. Users can decide for themselves, or pay any security
  328. expert to decide, whether it is safe to use. Further, Tor's modularity
  329. as described above, along with its open license, mean that its impact
  330. will continue to grow.
  331. <div class="p"><!----></div>
  332. Sixth, Tor has an established user base of hundreds of
  333. thousands of people from around the world. This diversity of
  334. users contributes to sustainability as above: Tor is used by
  335. ordinary citizens, activists, corporations, law enforcement, and
  336. even government and military users,
  337. and they can
  338. only achieve their security goals by blending together in the same
  339. network&nbsp;[<a href="#econymics" name="CITEeconymics">1</a>,<a href="#usability:weis2006" name="CITEusability:weis2006">9</a>]. This user base also provides
  340. something else: hundreds of thousands of different and often-changing
  341. addresses that we can leverage for our blocking-resistance design.
  342. <div class="p"><!----></div>
  343. Finally and perhaps most importantly, Tor provides anonymity and prevents any
  344. single server from linking users to their communication partners. Despite
  345. initial appearances, <i>distributed-trust anonymity is critical for
  346. anti-censorship efforts</i>. If any single server can expose dissident bloggers
  347. or compile a list of users' behavior, the censors can profitably compromise
  348. that server's operator, perhaps by applying economic pressure to their
  349. employers,
  350. breaking into their computer, pressuring their family (if they have relatives
  351. in the censored area), or so on. Furthermore, in designs where any relay can
  352. expose its users, the censors can spread suspicion that they are running some
  353. of the relays and use this belief to chill use of the network.
  354. <div class="p"><!----></div>
  355. We discuss and adapt these components further in
  356. Section&nbsp;<a href="#sec:bridges">5</a>. But first we examine the strengths and
  357. weaknesses of other blocking-resistance approaches, so we can expand
  358. our repertoire of building blocks and ideas.
  359. <div class="p"><!----></div>
  360. <h2><a name="tth_sEc4">
  361. <a name="sec:related">
  362. 4</a>&nbsp;&nbsp;Current proxy solutions</h2>
  363. </a>
  364. <div class="p"><!----></div>
  365. Relay-based blocking-resistance schemes generally have two main
  366. components: a relay component and a discovery component. The relay part
  367. encompasses the process of establishing a connection, sending traffic
  368. back and forth, and so on &mdash; everything that's done once the user knows
  369. where she's going to connect. Discovery is the step before that: the
  370. process of finding one or more usable relays.
  371. <div class="p"><!----></div>
  372. For example, we can divide the pieces of Tor in the previous section
  373. into the process of building paths and sending
  374. traffic over them (relay) and the process of learning from the directory
  375. servers about what routers are available (discovery). With this distinction
  376. in mind, we now examine several categories of relay-based schemes.
  377. <div class="p"><!----></div>
  378. <h3><a name="tth_sEc4.1">
  379. 4.1</a>&nbsp;&nbsp;Centrally-controlled shared proxies</h3>
  380. <div class="p"><!----></div>
  381. Existing commercial anonymity solutions (like Anonymizer.com) are based
  382. on a set of single-hop proxies. In these systems, each user connects to
  383. a single proxy, which then relays traffic between the user and her
  384. destination. These public proxy
  385. systems are typically characterized by two features: they control and
  386. operate the proxies centrally, and many different users get assigned
  387. to each proxy.
  388. <div class="p"><!----></div>
  389. In terms of the relay component, single proxies provide weak security
  390. compared to systems that distribute trust over multiple relays, since a
  391. compromised proxy can trivially observe all of its users' actions, and
  392. an eavesdropper only needs to watch a single proxy to perform timing
  393. correlation attacks against all its users' traffic and thus learn where
  394. everyone is connecting. Worse, all users
  395. need to trust the proxy company to have good security itself as well as
  396. to not reveal user activities.
  397. <div class="p"><!----></div>
  398. On the other hand, single-hop proxies are easier to deploy, and they
  399. can provide better performance than distributed-trust designs like Tor,
  400. since traffic only goes through one relay. They're also more convenient
  401. from the user's perspective &mdash; since users entirely trust the proxy,
  402. they can just use their web browser directly.
  403. <div class="p"><!----></div>
  404. Whether public proxy schemes are more or less scalable than Tor is
  405. still up for debate: commercial anonymity systems can use some of their
  406. revenue to provision more bandwidth as they grow, whereas volunteer-based
  407. anonymity systems can attract thousands of fast relays to spread the load.
  408. <div class="p"><!----></div>
  409. The discovery piece can take several forms. Most commercial anonymous
  410. proxies have one or a handful of commonly known websites, and their users
  411. log in to those websites and relay their traffic through them. When
  412. these websites get blocked (generally soon after the company becomes
  413. popular), if the company cares about users in the blocked areas, they
  414. start renting lots of disparate IP addresses and rotating through them
  415. as they get blocked. They notify their users of new addresses (by email,
  416. for example). It's an arms race, since attackers can sign up to receive the
  417. email too, but operators have one nice trick available to them: because they
  418. have a list of paying subscribers, they can notify certain subscribers
  419. about updates earlier than others.
  420. <div class="p"><!----></div>
  421. Access control systems on the proxy let them provide service only to
  422. users with certain characteristics, such as paying customers or people
  423. from certain IP address ranges.
  424. <div class="p"><!----></div>
  425. Discovery in the face of a government-level firewall is a complex and
  426. unsolved
  427. topic, and we're stuck in this same arms race ourselves; we explore it
  428. in more detail in Section&nbsp;<a href="#sec:discovery">7</a>. But first we examine the
  429. other end of the spectrum &mdash; getting volunteers to run the proxies,
  430. and telling only a few people about each proxy.
  431. <div class="p"><!----></div>
  432. <h3><a name="tth_sEc4.2">
  433. 4.2</a>&nbsp;&nbsp;Independent personal proxies</h3>
  434. <div class="p"><!----></div>
  435. Personal proxies such as Circumventor&nbsp;[<a href="#circumventor" name="CITEcircumventor">18</a>] and
  436. CGIProxy&nbsp;[<a href="#cgiproxy" name="CITEcgiproxy">23</a>] use the same technology as the public ones as
  437. far as the relay component goes, but they use a different strategy for
  438. discovery. Rather than managing a few centralized proxies and constantly
  439. getting new addresses for them as the old addresses are blocked, they
  440. aim to have a large number of entirely independent proxies, each managing
  441. its own (much smaller) set of users.
  442. <div class="p"><!----></div>
  443. As the Circumventor site explains, "You don't
  444. actually install the Circumventor <em>on</em> the computer that is blocked
  445. from accessing Web sites. You, or a friend of yours, has to install the
  446. Circumventor on some <em>other</em> machine which is not censored."
  447. <div class="p"><!----></div>
  448. This tactic has great advantages in terms of blocking-resistance &mdash; recall
  449. our assumption in Section&nbsp;<a href="#sec:adversary">2</a> that the attention
  450. a system attracts from the attacker is proportional to its number of
  451. users and level of publicity. If each proxy only has a few users, and
  452. there is no central list of proxies, most of them will never get noticed by
  453. the censors.
  454. <div class="p"><!----></div>
  455. On the other hand, there's a huge scalability question that so far has
  456. prevented these schemes from being widely useful: how does the fellow
  457. in China find a person in Ohio who will run a Circumventor for him? In
  458. some cases he may know and trust some people on the outside, but in many
  459. cases he's just out of luck. Just as hard, how does a new volunteer in
  460. Ohio find a person in China who needs it?
  461. <div class="p"><!----></div>
  462. <div class="p"><!----></div>
  463. This challenge leads to a hybrid design-centrally &mdash; distributed
  464. personal proxies &mdash; which we will investigate in more detail in
  465. Section&nbsp;<a href="#sec:discovery">7</a>.
  466. <div class="p"><!----></div>
  467. <h3><a name="tth_sEc4.3">
  468. 4.3</a>&nbsp;&nbsp;Open proxies</h3>
  469. <div class="p"><!----></div>
  470. Yet another currently used approach to bypassing firewalls is to locate
  471. open and misconfigured proxies on the Internet. A quick Google search
  472. for "open proxy list" yields a wide variety of freely available lists
  473. of HTTP, HTTPS, and SOCKS proxies. Many small companies have sprung up
  474. providing more refined lists to paying customers.
  475. <div class="p"><!----></div>
  476. There are some downsides to using these open proxies though. First,
  477. the proxies are of widely varying quality in terms of bandwidth and
  478. stability, and many of them are entirely unreachable. Second, unlike
  479. networks of volunteers like Tor, the legality of routing traffic through
  480. these proxies is questionable: it's widely believed that most of them
  481. don't realize what they're offering, and probably wouldn't allow it if
  482. they realized. Third, in many cases the connection to the proxy is
  483. unencrypted, so firewalls that filter based on keywords in IP packets
  484. will not be hindered. Fourth, in many countries (including China), the
  485. firewall authorities hunt for open proxies as well, to preemptively
  486. block them. And last, many users are suspicious that some
  487. open proxies are a little <em>too</em> convenient: are they run by the
  488. adversary, in which case they get to monitor all the user's requests
  489. just as single-hop proxies can?
  490. <div class="p"><!----></div>
  491. A distributed-trust design like Tor resolves each of these issues for
  492. the relay component, but a constantly changing set of thousands of open
  493. relays is clearly a useful idea for a discovery component. For example,
  494. users might be able to make use of these proxies to bootstrap their
  495. first introduction into the Tor network.
  496. <div class="p"><!----></div>
  497. <h3><a name="tth_sEc4.4">
  498. 4.4</a>&nbsp;&nbsp;Blocking resistance and JAP</h3>
  499. <div class="p"><!----></div>
  500. K&#246;psell and Hilling's Blocking Resistance
  501. design&nbsp;[<a href="#koepsell:wpes2004" name="CITEkoepsell:wpes2004">20</a>] is probably
  502. the closest related work, and is the starting point for the design in this
  503. paper. In this design, the JAP anonymity system&nbsp;[<a href="#web-mix" name="CITEweb-mix">3</a>] is used
  504. as a base instead of Tor. Volunteers operate a large number of access
  505. points that relay traffic to the core JAP
  506. network, which in turn anonymizes users' traffic. The software to run these
  507. relays is, as in our design, included in the JAP client software and enabled
  508. only when the user decides to enable it. Discovery is handled with a
  509. CAPTCHA-based mechanism; users prove that they aren't an automated process,
  510. and are given the address of an access point. (The problem of a determined
  511. attacker with enough manpower to launch many requests and enumerate all the
  512. access points is not considered in depth.) There is also some suggestion
  513. that information about access points could spread through existing social
  514. networks.
  515. <div class="p"><!----></div>
  516. <h3><a name="tth_sEc4.5">
  517. 4.5</a>&nbsp;&nbsp;Infranet</h3>
  518. <div class="p"><!----></div>
  519. The Infranet design&nbsp;[<a href="#infranet" name="CITEinfranet">14</a>] uses one-hop relays to deliver web
  520. content, but disguises its communications as ordinary HTTP traffic. Requests
  521. are split into multiple requests for URLs on the relay, which then encodes
  522. its responses in the content it returns. The relay needs to be an actual
  523. website with plausible content and a number of URLs which the user might want
  524. to access &mdash; if the Infranet software produced its own cover content, it would
  525. be far easier for censors to identify. To keep the censors from noticing
  526. that cover content changes depending on what data is embedded, Infranet needs
  527. the cover content to have an innocuous reason for changing frequently: the
  528. paper recommends watermarked images and webcams.
  529. <div class="p"><!----></div>
  530. The attacker and relay operators in Infranet's threat model are significantly
  531. different than in ours. Unlike our attacker, Infranet's censor can't be
  532. bypassed with encrypted traffic (presumably because the censor blocks
  533. encrypted traffic, or at least considers it suspicious), and has more
  534. computational resources to devote to each connection than ours (so it can
  535. notice subtle patterns over time). Unlike our bridge operators, Infranet's
  536. operators (and users) have more bandwidth to spare; the overhead in typical
  537. steganography schemes is far higher than Tor's.
  538. <div class="p"><!----></div>
  539. The Infranet design does not include a discovery element. Discovery,
  540. however, is a critical point: if whatever mechanism allows users to learn
  541. about relays also allows the censor to do so, he can trivially discover and
  542. block their addresses, even if the steganography would prevent mere traffic
  543. observation from revealing the relays' addresses.
  544. <div class="p"><!----></div>
  545. <h3><a name="tth_sEc4.6">
  546. 4.6</a>&nbsp;&nbsp;RST-evasion and other packet-level tricks</h3>
  547. <div class="p"><!----></div>
  548. In their analysis of China's firewall's content-based blocking, Clayton,
  549. Murdoch and Watson discovered that rather than blocking all packets in a TCP
  550. streams once a forbidden word was noticed, the firewall was simply forging
  551. RST packets to make the communicating parties believe that the connection was
  552. closed&nbsp;[<a href="#clayton:pet2006" name="CITEclayton:pet2006">7</a>]. They proposed altering operating systems
  553. to ignore forged RST packets. This approach might work in some cases, but
  554. in practice it appears that many firewalls start filtering by IP address
  555. once a sufficient number of RST packets have been sent.
  556. <div class="p"><!----></div>
  557. Other packet-level responses to filtering include splitting
  558. sensitive words across multiple TCP packets, so that the censors'
  559. firewalls can't notice them without performing expensive stream
  560. reconstruction&nbsp;[<a href="#ptacek98insertion" name="CITEptacek98insertion">27</a>]. This technique relies on the
  561. same insight as our weak steganography assumption.
  562. <div class="p"><!----></div>
  563. <h3><a name="tth_sEc4.7">
  564. 4.7</a>&nbsp;&nbsp;Internal caching networks</h3>
  565. <div class="p"><!----></div>
  566. Freenet&nbsp;[<a href="#freenet-pets00" name="CITEfreenet-pets00">6</a>] is an anonymous peer-to-peer data store.
  567. Analyzing Freenet's security can be difficult, as its design is in flux as
  568. new discovery and routing mechanisms are proposed, and no complete
  569. specification has (to our knowledge) been written. Freenet servers relay
  570. requests for specific content (indexed by a digest of the content)
  571. "toward" the server that hosts it, and then cache the content as it
  572. follows the same path back to
  573. the requesting user. If Freenet's routing mechanism is successful in
  574. allowing nodes to learn about each other and route correctly even as some
  575. node-to-node links are blocked by firewalls, then users inside censored areas
  576. can ask a local Freenet server for a piece of content, and get an answer
  577. without having to connect out of the country at all. Of course, operators of
  578. servers inside the censored area can still be targeted, and the addresses of
  579. external servers can still be blocked.
  580. <div class="p"><!----></div>
  581. <h3><a name="tth_sEc4.8">
  582. 4.8</a>&nbsp;&nbsp;Skype</h3>
  583. <div class="p"><!----></div>
  584. The popular Skype voice-over-IP software uses multiple techniques to tolerate
  585. restrictive networks, some of which allow it to continue operating in the
  586. presence of censorship. By switching ports and using encryption, Skype
  587. attempts to resist trivial blocking and content filtering. Even if no
  588. encryption were used, it would still be expensive to scan all voice
  589. traffic for sensitive words. Also, most current keyloggers are unable to
  590. store voice traffic. Nevertheless, Skype can still be blocked, especially at
  591. its central login server.
  592. <div class="p"><!----></div>
  593. <h3><a name="tth_sEc4.9">
  594. 4.9</a>&nbsp;&nbsp;Tor itself</h3>
  595. <div class="p"><!----></div>
  596. And last, we include Tor itself in the list of current solutions
  597. to firewalls. Tens of thousands of people use Tor from countries that
  598. routinely filter their Internet. Tor's website has been blocked in most
  599. of them. But why hasn't the Tor network been blocked yet?
  600. <div class="p"><!----></div>
  601. We have several theories. The first is the most straightforward: tens of
  602. thousands of people are simply too few to matter. It may help that Tor is
  603. perceived to be for experts only, and thus not worth attention yet. The
  604. more subtle variant on this theory is that we've positioned Tor in the
  605. public eye as a tool for retaining civil liberties in more free countries,
  606. so perhaps blocking authorities don't view it as a threat. (We revisit
  607. this idea when we consider whether and how to publicize a Tor variant
  608. that improves blocking-resistance &mdash; see Section&nbsp;<a href="#subsec:publicity">9.5</a>
  609. for more discussion.)
  610. <div class="p"><!----></div>
  611. The broader explanation is that the maintenance of most government-level
  612. filters is aimed at stopping widespread information flow and appearing to be
  613. in control, not by the impossible goal of blocking all possible ways to bypass
  614. censorship. Censors realize that there will always
  615. be ways for a few people to get around the firewall, and as long as Tor
  616. has not publically threatened their control, they see no urgent need to
  617. block it yet.
  618. <div class="p"><!----></div>
  619. We should recognize that we're <em>already</em> in the arms race. These
  620. constraints can give us insight into the priorities and capabilities of
  621. our various attackers.
  622. <div class="p"><!----></div>
  623. <h2><a name="tth_sEc5">
  624. <a name="sec:bridges">
  625. 5</a>&nbsp;&nbsp;The relay component of our blocking-resistant design</h2>
  626. </a>
  627. <div class="p"><!----></div>
  628. Section&nbsp;<a href="#sec:current-tor">3</a> describes many reasons why Tor is
  629. well-suited as a building block in our context, but several changes will
  630. allow the design to resist blocking better. The most critical changes are
  631. to get more relay addresses, and to distribute them to users differently.
  632. <div class="p"><!----></div>
  633. <div class="p"><!----></div>
  634. <div class="p"><!----></div>
  635. <h3><a name="tth_sEc5.1">
  636. 5.1</a>&nbsp;&nbsp;Bridge relays</h3>
  637. <div class="p"><!----></div>
  638. Today, Tor servers operate on less than a thousand distinct IP addresses;
  639. an adversary
  640. could enumerate and block them all with little trouble. To provide a
  641. means of ingress to the network, we need a larger set of entry points, most
  642. of which an adversary won't be able to enumerate easily. Fortunately, we
  643. have such a set: the Tor users.
  644. <div class="p"><!----></div>
  645. Hundreds of thousands of people around the world use Tor. We can leverage
  646. our already self-selected user base to produce a list of thousands of
  647. frequently-changing IP addresses. Specifically, we can give them a little
  648. button in the GUI that says "Tor for Freedom", and users who click
  649. the button will turn into <em>bridge relays</em> (or just <em>bridges</em>
  650. for short). They can rate limit relayed connections to 10 KB/s (almost
  651. nothing for a broadband user in a free country, but plenty for a user
  652. who otherwise has no access at all), and since they are just relaying
  653. bytes back and forth between blocked users and the main Tor network, they
  654. won't need to make any external connections to Internet sites. Because
  655. of this separation of roles, and because we're making use of software
  656. that the volunteers have already installed for their own use, we expect
  657. our scheme to attract and maintain more volunteers than previous schemes.
  658. <div class="p"><!----></div>
  659. As usual, there are new anonymity and security implications from running a
  660. bridge relay, particularly from letting people relay traffic through your
  661. Tor client; but we leave this discussion for Section&nbsp;<a href="#sec:security">8</a>.
  662. <div class="p"><!----></div>
  663. <div class="p"><!----></div>
  664. <h3><a name="tth_sEc5.2">
  665. 5.2</a>&nbsp;&nbsp;The bridge directory authority</h3>
  666. <div class="p"><!----></div>
  667. How do the bridge relays advertise their existence to the world? We
  668. introduce a second new component of the design: a specialized directory
  669. authority that aggregates and tracks bridges. Bridge relays periodically
  670. publish server descriptors (summaries of their keys, locations, etc,
  671. signed by their long-term identity key), just like the relays in the
  672. "main" Tor network, but in this case they publish them only to the
  673. bridge directory authorities.
  674. <div class="p"><!----></div>
  675. The main difference between bridge authorities and the directory
  676. authorities for the main Tor network is that the main authorities provide
  677. a list of every known relay, but the bridge authorities only give
  678. out a server descriptor if you already know its identity key. That is,
  679. you can keep up-to-date on a bridge's location and other information
  680. once you know about it, but you can't just grab a list of all the bridges.
  681. <div class="p"><!----></div>
  682. The identity key, IP address, and directory port for each bridge
  683. authority ship by default with the Tor software, so the bridge relays
  684. can be confident they're publishing to the right location, and the
  685. blocked users can establish an encrypted authenticated channel. See
  686. Section&nbsp;<a href="#subsec:trust-chain">8.5</a> for more discussion of the public key
  687. infrastructure and trust chain.
  688. <div class="p"><!----></div>
  689. Bridges use Tor to publish their descriptors privately and securely,
  690. so even an attacker monitoring the bridge directory authority's network
  691. can't make a list of all the addresses contacting the authority.
  692. Bridges may publish to only a subset of the
  693. authorities, to limit the potential impact of an authority compromise.
  694. <div class="p"><!----></div>
  695. <div class="p"><!----></div>
  696. <h3><a name="tth_sEc5.3">
  697. <a name="subsec:relay-together">
  698. 5.3</a>&nbsp;&nbsp;Putting them together</h3>
  699. </a>
  700. <div class="p"><!----></div>
  701. If a blocked user knows the identity keys of a set of bridge relays, and
  702. he has correct address information for at least one of them, he can use
  703. that one to make a secure connection to the bridge authority and update
  704. his knowledge about the other bridge relays. He can also use it to make
  705. secure connections to the main Tor network and directory servers, so he
  706. can build circuits and connect to the rest of the Internet. All of these
  707. updates happen in the background: from the blocked user's perspective,
  708. he just accesses the Internet via his Tor client like always.
  709. <div class="p"><!----></div>
  710. So now we've reduced the problem from how to circumvent the firewall
  711. for all transactions (and how to know that the pages you get have not
  712. been modified by the local attacker) to how to learn about a working
  713. bridge relay.
  714. <div class="p"><!----></div>
  715. There's another catch though. We need to make sure that the network
  716. traffic we generate by simply connecting to a bridge relay doesn't stand
  717. out too much.
  718. <div class="p"><!----></div>
  719. <div class="p"><!----></div>
  720. <div class="p"><!----></div>
  721. <h2><a name="tth_sEc6">
  722. <a name="sec:network-fingerprint">
  723. <a name="subsec:enclave-dirs">
  724. 6</a>&nbsp;&nbsp;Hiding Tor's network fingerprint</h2>
  725. </a>
  726. </a>
  727. <div class="p"><!----></div>
  728. Currently, Tor uses two protocols for its network communications. The
  729. main protocol uses TLS for encrypted and authenticated communication
  730. between Tor instances. The second protocol is standard HTTP, used for
  731. fetching directory information. All Tor servers listen on their "ORPort"
  732. for TLS connections, and some of them opt to listen on their "DirPort"
  733. as well, to serve directory information. Tor servers choose whatever port
  734. numbers they like; the server descriptor they publish to the directory
  735. tells users where to connect.
  736. <div class="p"><!----></div>
  737. One format for communicating address information about a bridge relay is
  738. its IP address and DirPort. From there, the user can ask the bridge's
  739. directory cache for an up-to-date copy of its server descriptor, and
  740. learn its current circuit keys, its ORPort, and so on.
  741. <div class="p"><!----></div>
  742. However, connecting directly to the directory cache involves a plaintext
  743. HTTP request. A censor could create a network fingerprint (known as a
  744. <em>signature</em> in the intrusion detection field) for the request
  745. and/or its response, thus preventing these connections. To resolve this
  746. vulnerability, we've modified the Tor protocol so that users can connect
  747. to the directory cache via the main Tor port &mdash; they establish a TLS
  748. connection with the bridge as normal, and then send a special "begindir"
  749. relay command to establish an internal connection to its directory cache.
  750. <div class="p"><!----></div>
  751. Therefore a better way to summarize a bridge's address is by its IP
  752. address and ORPort, so all communications between the client and the
  753. bridge will use ordinary TLS. But there are other details that need
  754. more investigation.
  755. <div class="p"><!----></div>
  756. What port should bridges pick for their ORPort? We currently recommend
  757. that they listen on port 443 (the default HTTPS port) if they want to
  758. be most useful, because clients behind standard firewalls will have
  759. the best chance to reach them. Is this the best choice in all cases,
  760. or should we encourage some fraction of them pick random ports, or other
  761. ports commonly permitted through firewalls like 53 (DNS) or 110
  762. (POP)? Or perhaps we should use other ports where TLS traffic is
  763. expected, like 993 (IMAPS) or 995 (POP3S). We need more research on our
  764. potential users, and their current and anticipated firewall restrictions.
  765. <div class="p"><!----></div>
  766. Furthermore, we need to look at the specifics of Tor's TLS handshake.
  767. Right now Tor uses some predictable strings in its TLS handshakes. For
  768. example, it sets the X.509 organizationName field to "Tor", and it puts
  769. the Tor server's nickname in the certificate's commonName field. We
  770. should tweak the handshake protocol so it doesn't rely on any unusual details
  771. in the certificate, yet it remains secure; the certificate itself
  772. should be made to resemble an ordinary HTTPS certificate. We should also try
  773. to make our advertised cipher-suites closer to what an ordinary web server
  774. would support.
  775. <div class="p"><!----></div>
  776. Tor's TLS handshake uses two-certificate chains: one certificate
  777. contains the self-signed identity key for
  778. the router, and the second contains a current TLS key, signed by the
  779. identity key. We use these to authenticate that we're talking to the right
  780. router, and to limit the impact of TLS-key exposure. Most (though far from
  781. all) consumer-oriented HTTPS services provide only a single certificate.
  782. These extra certificates may help identify Tor's TLS handshake; instead,
  783. bridges should consider using only a single TLS key certificate signed by
  784. their identity key, and providing the full value of the identity key in an
  785. early handshake cell. More significantly, Tor currently has all clients
  786. present certificates, so that clients are harder to distinguish from servers.
  787. But in a blocking-resistance environment, clients should not present
  788. certificates at all.
  789. <div class="p"><!----></div>
  790. Last, what if the adversary starts observing the network traffic even
  791. more closely? Even if our TLS handshake looks innocent, our traffic timing
  792. and volume still look different than a user making a secure web connection
  793. to his bank. The same techniques used in the growing trend to build tools
  794. to recognize encrypted Bittorrent traffic
  795. could be used to identify Tor communication and recognize bridge
  796. relays. Rather than trying to look like encrypted web traffic, we may be
  797. better off trying to blend with some other encrypted network protocol. The
  798. first step is to compare typical network behavior for a Tor client to
  799. typical network behavior for various other protocols. This statistical
  800. cat-and-mouse game is made more complex by the fact that Tor transports a
  801. variety of protocols, and we'll want to automatically handle web browsing
  802. differently from, say, instant messaging.
  803. <div class="p"><!----></div>
  804. <div class="p"><!----></div>
  805. <h3><a name="tth_sEc6.1">
  806. <a name="subsec:id-address">
  807. 6.1</a>&nbsp;&nbsp;Identity keys as part of addressing information</h3>
  808. </a>
  809. <div class="p"><!----></div>
  810. We have described a way for the blocked user to bootstrap into the
  811. network once he knows the IP address and ORPort of a bridge. What about
  812. local spoofing attacks? That is, since we never learned an identity
  813. key fingerprint for the bridge, a local attacker could intercept our
  814. connection and pretend to be the bridge we had in mind. It turns out
  815. that giving false information isn't that bad &mdash; since the Tor client
  816. ships with trusted keys for the bridge directory authority and the Tor
  817. network directory authorities, the user can learn whether he's being
  818. given a real connection to the bridge authorities or not. (After all,
  819. if the adversary intercepts every connection the user makes and gives
  820. him a bad connection each time, there's nothing we can do.)
  821. <div class="p"><!----></div>
  822. What about anonymity-breaking attacks from observing traffic, if the
  823. blocked user doesn't start out knowing the identity key of his intended
  824. bridge? The vulnerabilities aren't so bad in this case either &mdash; the
  825. adversary could do similar attacks just by monitoring the network
  826. traffic.
  827. <div class="p"><!----></div>
  828. Once the Tor client has fetched the bridge's server descriptor, it should
  829. remember the identity key fingerprint for that bridge relay. Thus if
  830. the bridge relay moves to a new IP address, the client can query the
  831. bridge directory authority to look up a fresh server descriptor using
  832. this fingerprint.
  833. <div class="p"><!----></div>
  834. So we've shown that it's <em>possible</em> to bootstrap into the network
  835. just by learning the IP address and ORPort of a bridge, but are there
  836. situations where it's more convenient or more secure to learn the bridge's
  837. identity fingerprint as well as instead, while bootstrapping? We keep
  838. that question in mind as we next investigate bootstrapping and discovery.
  839. <div class="p"><!----></div>
  840. <h2><a name="tth_sEc7">
  841. <a name="sec:discovery">
  842. 7</a>&nbsp;&nbsp;Discovering working bridge relays</h2>
  843. </a>
  844. <div class="p"><!----></div>
  845. Tor's modular design means that we can develop a better relay component
  846. independently of developing the discovery component. This modularity's
  847. great promise is that we can pick any discovery approach we like; but the
  848. unfortunate fact is that we have no magic bullet for discovery. We're
  849. in the same arms race as all the other designs we described in
  850. Section&nbsp;<a href="#sec:related">4</a>.
  851. <div class="p"><!----></div>
  852. In this section we describe a variety of approaches to adding discovery
  853. components for our design.
  854. <div class="p"><!----></div>
  855. <h3><a name="tth_sEc7.1">
  856. <a name="subsec:first-bridge">
  857. 7.1</a>&nbsp;&nbsp;Bootstrapping: finding your first bridge.</h3>
  858. </a>
  859. <div class="p"><!----></div>
  860. In Section&nbsp;<a href="#subsec:relay-together">5.3</a>, we showed that a user who knows
  861. a working bridge address can use it to reach the bridge authority and
  862. to stay connected to the Tor network. But how do new users reach the
  863. bridge authority in the first place? After all, the bridge authority
  864. will be one of the first addresses that a censor blocks.
  865. <div class="p"><!----></div>
  866. First, we should recognize that most government firewalls are not
  867. perfect. That is, they may allow connections to Google cache or some
  868. open proxy servers, or they let file-sharing traffic, Skype, instant
  869. messaging, or World-of-Warcraft connections through. Different users will
  870. have different mechanisms for bypassing the firewall initially. Second,
  871. we should remember that most people don't operate in a vacuum; users will
  872. hopefully know other people who are in other situations or have other
  873. resources available. In the rest of this section we develop a toolkit
  874. of different options and mechanisms, so that we can enable users in a
  875. diverse set of contexts to bootstrap into the system.
  876. <div class="p"><!----></div>
  877. (For users who can't use any of these techniques, hopefully they know
  878. a friend who can &mdash; for example, perhaps the friend already knows some
  879. bridge relay addresses. If they can't get around it at all, then we
  880. can't help them &mdash; they should go meet more people or learn more about
  881. the technology running the firewall in their area.)
  882. <div class="p"><!----></div>
  883. By deploying all the schemes in the toolkit at once, we let bridges and
  884. blocked users employ the discovery approach that is most appropriate
  885. for their situation.
  886. <div class="p"><!----></div>
  887. <h3><a name="tth_sEc7.2">
  888. 7.2</a>&nbsp;&nbsp;Independent bridges, no central discovery</h3>
  889. <div class="p"><!----></div>
  890. The first design is simply to have no centralized discovery component at
  891. all. Volunteers run bridges, and we assume they have some blocked users
  892. in mind and communicate their address information to them out-of-band
  893. (for example, through Gmail). This design allows for small personal
  894. bridges that have only one or a handful of users in mind, but it can
  895. also support an entire community of users. For example, Citizen Lab's
  896. upcoming Psiphon single-hop proxy tool&nbsp;[<a href="#psiphon" name="CITEpsiphon">13</a>] plans to use this
  897. <em>social network</em> approach as its discovery component.
  898. <div class="p"><!----></div>
  899. There are several ways to do bootstrapping in this design. In the simple
  900. case, the operator of the bridge informs each chosen user about his
  901. bridge's address information and/or keys. A different approach involves
  902. blocked users introducing new blocked users to the bridges they know.
  903. That is, somebody in the blocked area can pass along a bridge's address to
  904. somebody else they trust. This scheme brings in appealing but complex game
  905. theoretic properties: the blocked user making the decision has an incentive
  906. only to delegate to trustworthy people, since an adversary who learns
  907. the bridge's address and filters it makes it unavailable for both of them.
  908. Also, delegating known bridges to members of your social network can be
  909. dangerous: an the adversary who can learn who knows which bridges may
  910. be able to reconstruct the social network.
  911. <div class="p"><!----></div>
  912. Note that a central set of bridge directory authorities can still be
  913. compatible with a decentralized discovery process. That is, how users
  914. first learn about bridges is entirely up to the bridges, but the process
  915. of fetching up-to-date descriptors for them can still proceed as described
  916. in Section&nbsp;<a href="#sec:bridges">5</a>. Of course, creating a central place that
  917. knows about all the bridges may not be smart, especially if every other
  918. piece of the system is decentralized. Further, if a user only knows
  919. about one bridge and he loses track of it, it may be quite a hassle to
  920. reach the bridge authority. We address these concerns next.
  921. <div class="p"><!----></div>
  922. <h3><a name="tth_sEc7.3">
  923. 7.3</a>&nbsp;&nbsp;Families of bridges, no central discovery</h3>
  924. <div class="p"><!----></div>
  925. Because the blocked users are running our software too, we have many
  926. opportunities to improve usability or robustness. Our second design builds
  927. on the first by encouraging volunteers to run several bridges at once
  928. (or coordinate with other bridge volunteers), such that some
  929. of the bridges are likely to be available at any given time.
  930. <div class="p"><!----></div>
  931. The blocked user's Tor client would periodically fetch an updated set of
  932. recommended bridges from any of the working bridges. Now the client can
  933. learn new additions to the bridge pool, and can expire abandoned bridges
  934. or bridges that the adversary has blocked, without the user ever needing
  935. to care. To simplify maintenance of the community's bridge pool, each
  936. community could run its own bridge directory authority &mdash; reachable via
  937. the available bridges, and also mirrored at each bridge.
  938. <div class="p"><!----></div>
  939. <h3><a name="tth_sEc7.4">
  940. 7.4</a>&nbsp;&nbsp;Public bridges with central discovery</h3>
  941. <div class="p"><!----></div>
  942. What about people who want to volunteer as bridges but don't know any
  943. suitable blocked users? What about people who are blocked but don't
  944. know anybody on the outside? Here we describe how to make use of these
  945. <em>public bridges</em> in a way that still makes it hard for the attacker
  946. to learn all of them.
  947. <div class="p"><!----></div>
  948. The basic idea is to divide public bridges into a set of pools based on
  949. identity key. Each pool corresponds to a <em>distribution strategy</em>:
  950. an approach to distributing its bridge addresses to users. Each strategy
  951. is designed to exercise a different scarce resource or property of
  952. the user.
  953. <div class="p"><!----></div>
  954. How do we divide bridges between these strategy pools such that they're
  955. evenly distributed and the allocation is hard to influence or predict,
  956. but also in a way that's amenable to creating more strategies later
  957. on without reshuffling all the pools? We assign a given bridge
  958. to a strategy pool by hashing the bridge's identity key along with a
  959. secret that only the bridge authority knows: the first n bits of this
  960. hash dictate the strategy pool number, where n is a parameter that
  961. describes how many strategy pools we want at this point. We choose n=3
  962. to start, so we divide bridges between 8 pools; but as we later invent
  963. new distribution strategies, we can increment n to split the 8 into
  964. 16. Since a bridge can't predict the next bit in its hash, it can't
  965. anticipate which identity key will correspond to a certain new pool
  966. when the pools are split. Further, since the bridge authority doesn't
  967. provide any feedback to the bridge about which strategy pool it's in,
  968. an adversary who signs up bridges with the goal of filling a certain
  969. pool&nbsp;[<a href="#casc-rep" name="CITEcasc-rep">12</a>] will be hindered.
  970. <div class="p"><!----></div>
  971. <div class="p"><!----></div>
  972. The first distribution strategy (used for the first pool) publishes bridge
  973. addresses in a time-release fashion. The bridge authority divides the
  974. available bridges into partitions, and each partition is deterministically
  975. available only in certain time windows. That is, over the course of a
  976. given time slot (say, an hour), each requester is given a random bridge
  977. from within that partition. When the next time slot arrives, a new set
  978. of bridges from the pool are available for discovery. Thus some bridge
  979. address is always available when a new
  980. user arrives, but to learn about all bridges the attacker needs to fetch
  981. all new addresses at every new time slot. By varying the length of the
  982. time slots, we can make it harder for the attacker to guess when to check
  983. back. We expect these bridges will be the first to be blocked, but they'll
  984. help the system bootstrap until they <em>do</em> get blocked. Further,
  985. remember that we're dealing with different blocking regimes around the
  986. world that will progress at different rates &mdash; so this pool will still
  987. be useful to some users even as the arms races progress.
  988. <div class="p"><!----></div>
  989. The second distribution strategy publishes bridge addresses based on the IP
  990. address of the requesting user. Specifically, the bridge authority will
  991. divide the available bridges in the pool into a bunch of partitions
  992. (as in the first distribution scheme), hash the requester's IP address
  993. with a secret of its own (as in the above allocation scheme for creating
  994. pools), and give the requester a random bridge from the appropriate
  995. partition. To raise the bar, we should discard the last octet of the
  996. IP address before inputting it to the hash function, so an attacker
  997. who only controls a single "/24" network only counts as one user. A
  998. large attacker like China will still be able to control many addresses,
  999. but the hassle of establishing connections from each network (or spoofing
  1000. TCP connections) may still slow them down. Similarly, as a special case,
  1001. we should treat IP addresses that are Tor exit nodes as all being on
  1002. the same network.
  1003. <div class="p"><!----></div>
  1004. The third strategy combines the time-based and location-based
  1005. strategies to further constrain and rate-limit the available bridge
  1006. addresses. Specifically, the bridge address provided in a given time
  1007. slot to a given network location is deterministic within the partition,
  1008. rather than chosen randomly each time from the partition. Thus, repeated
  1009. requests during that time slot from a given network are given the same
  1010. bridge address as the first request.
  1011. <div class="p"><!----></div>
  1012. The fourth strategy is based on Circumventor's discovery strategy.
  1013. The Circumventor project, realizing that its adoption will remain limited
  1014. if it has no central coordination mechanism, has started a mailing list to
  1015. distribute new proxy addresses every few days. From experimentation it
  1016. seems they have concluded that sending updates every three or four days
  1017. is sufficient to stay ahead of the current attackers.
  1018. <div class="p"><!----></div>
  1019. The fifth strategy provides an alternative approach to a mailing list:
  1020. users provide an email address and receive an automated response
  1021. listing an available bridge address. We could limit one response per
  1022. email address. To further rate limit queries, we could require a CAPTCHA
  1023. solution
  1024. in each case too. In fact, we wouldn't need to
  1025. implement the CAPTCHA on our side: if we only deliver bridge addresses
  1026. to Yahoo or GMail addresses, we can leverage the rate-limiting schemes
  1027. that other parties already impose for account creation.
  1028. <div class="p"><!----></div>
  1029. The sixth strategy ties in the social network design with public
  1030. bridges and a reputation system. We pick some seeds &mdash; trusted people in
  1031. blocked areas &mdash; and give them each a few dozen bridge addresses and a few
  1032. <em>delegation tokens</em>. We run a website next to the bridge authority,
  1033. where users can log in (they connect via Tor, and they don't need to
  1034. provide actual identities, just persistent pseudonyms). Users can delegate
  1035. trust to other people they know by giving them a token, which can be
  1036. exchanged for a new account on the website. Accounts in "good standing"
  1037. then accrue new bridge addresses and new tokens. As usual, reputation
  1038. schemes bring in a host of new complexities&nbsp;[<a href="#rep-anon" name="CITErep-anon">10</a>]: how do we
  1039. decide that an account is in good standing? We could tie reputation
  1040. to whether the bridges they're told about have been blocked &mdash; see
  1041. Section&nbsp;<a href="#subsec:geoip">7.7</a> below for initial thoughts on how to discover
  1042. whether bridges have been blocked. We could track reputation between
  1043. accounts (if you delegate to somebody who screws up, it impacts you too),
  1044. or we could use blinded delegation tokens&nbsp;[<a href="#chaum-blind" name="CITEchaum-blind">5</a>] to prevent
  1045. the website from mapping the seeds' social network. We put off deeper
  1046. discussion of the social network reputation strategy for future work.
  1047. <div class="p"><!----></div>
  1048. Pools seven and eight are held in reserve, in case our currently deployed
  1049. tricks all fail at once and the adversary blocks all those bridges &mdash; so
  1050. we can adapt and move to new approaches quickly, and have some bridges
  1051. immediately available for the new schemes. New strategies might be based
  1052. on some other scarce resource, such as relaying traffic for others or
  1053. other proof of energy spent. (We might also worry about the incentives
  1054. for bridges that sign up and get allocated to the reserve pools: will they
  1055. be unhappy that they're not being used? But this is a transient problem:
  1056. if Tor users are bridges by default, nobody will mind not being used yet.
  1057. See also Section&nbsp;<a href="#subsec:incentives">9.4</a>.)
  1058. <div class="p"><!----></div>
  1059. <div class="p"><!----></div>
  1060. <h3><a name="tth_sEc7.5">
  1061. 7.5</a>&nbsp;&nbsp;Public bridges with coordinated discovery</h3>
  1062. <div class="p"><!----></div>
  1063. We presented the above discovery strategies in the context of a single
  1064. bridge directory authority, but in practice we will want to distribute the
  1065. operations over several bridge authorities &mdash; a single point of failure
  1066. or attack is a bad move. The first answer is to run several independent
  1067. bridge directory authorities, and bridges gravitate to one based on
  1068. their identity key. The better answer would be some federation of bridge
  1069. authorities that work together to provide redundancy but don't introduce
  1070. new security issues. We could even imagine designs where the bridge
  1071. authorities have encrypted versions of the bridge's server descriptors,
  1072. and the users learn a decryption key that they keep private when they
  1073. first hear about the bridge &mdash; this way the bridge authorities would not
  1074. be able to learn the IP address of the bridges.
  1075. <div class="p"><!----></div>
  1076. We leave this design question for future work.
  1077. <div class="p"><!----></div>
  1078. <h3><a name="tth_sEc7.6">
  1079. 7.6</a>&nbsp;&nbsp;Assessing whether bridges are useful</h3>
  1080. <div class="p"><!----></div>
  1081. Learning whether a bridge is useful is important in the bridge authority's
  1082. decision to include it in responses to blocked users. For example, if
  1083. we end up with a list of thousands of bridges and only a few dozen of
  1084. them are reachable right now, most blocked users will not end up knowing
  1085. about working bridges.
  1086. <div class="p"><!----></div>
  1087. There are three components for assessing how useful a bridge is. First,
  1088. is it reachable from the public Internet? Second, what proportion of
  1089. the time is it available? Third, is it blocked in certain jurisdictions?
  1090. <div class="p"><!----></div>
  1091. The first component can be tested just as we test reachability of
  1092. ordinary Tor servers. Specifically, the bridges do a self-test &mdash; connect
  1093. to themselves via the Tor network &mdash; before they are willing to
  1094. publish their descriptor, to make sure they're not obviously broken or
  1095. misconfigured. Once the bridges publish, the bridge authority also tests
  1096. reachability to make sure they're not confused or outright lying.
  1097. <div class="p"><!----></div>
  1098. The second component can be measured and tracked by the bridge authority.
  1099. By doing periodic reachability tests, we can get a sense of how often the
  1100. bridge is available. More complex tests will involve bandwidth-intensive
  1101. checks to force the bridge to commit resources in order to be counted as
  1102. available. We need to evaluate how the relationship of uptime percentage
  1103. should weigh into our choice of which bridges to advertise. We leave
  1104. this to future work.
  1105. <div class="p"><!----></div>
  1106. The third component is perhaps the trickiest: with many different
  1107. adversaries out there, how do we keep track of which adversaries have
  1108. blocked which bridges, and how do we learn about new blocks as they
  1109. occur? We examine this problem next.
  1110. <div class="p"><!----></div>
  1111. <h3><a name="tth_sEc7.7">
  1112. <a name="subsec:geoip">
  1113. 7.7</a>&nbsp;&nbsp;How do we know if a bridge relay has been blocked?</h3>
  1114. </a>
  1115. <div class="p"><!----></div>
  1116. There are two main mechanisms for testing whether bridges are reachable
  1117. from inside each blocked area: active testing via users, and passive
  1118. testing via bridges.
  1119. <div class="p"><!----></div>
  1120. In the case of active testing, certain users inside each area
  1121. sign up as testing relays. The bridge authorities can then use a
  1122. Blossom-like&nbsp;[<a href="#blossom-thesis" name="CITEblossom-thesis">16</a>] system to build circuits through them
  1123. to each bridge and see if it can establish the connection. But how do
  1124. we pick the users? If we ask random users to do the testing (or if we
  1125. solicit volunteers from the users), the adversary should sign up so he
  1126. can enumerate the bridges we test. Indeed, even if we hand-select our
  1127. testers, the adversary might still discover their location and monitor
  1128. their network activity to learn bridge addresses.
  1129. <div class="p"><!----></div>
  1130. Another answer is not to measure directly, but rather let the bridges
  1131. report whether they're being used.
  1132. Specifically, bridges should install a GeoIP database such as the public
  1133. IP-To-Country list&nbsp;[<a href="#ip-to-country" name="CITEip-to-country">19</a>], and then periodically report to the
  1134. bridge authorities which countries they're seeing use from. This data
  1135. would help us track which countries are making use of the bridge design,
  1136. and can also let us learn about new steps the adversary has taken in
  1137. the arms race. (The compressed GeoIP database is only several hundred
  1138. kilobytes, and we could even automate the update process by serving it
  1139. from the bridge authorities.)
  1140. More analysis of this passive reachability
  1141. testing design is needed to resolve its many edge cases: for example,
  1142. if a bridge stops seeing use from a certain area, does that mean the
  1143. bridge is blocked or does that mean those users are asleep?
  1144. <div class="p"><!----></div>
  1145. There are many more problems with the general concept of detecting whether
  1146. bridges are blocked. First, different zones of the Internet are blocked
  1147. in different ways, and the actual firewall jurisdictions do not match
  1148. country borders. Our bridge scheme could help us map out the topology
  1149. of the censored Internet, but this is a huge task. More generally,
  1150. if a bridge relay isn't reachable, is that because of a network block
  1151. somewhere, because of a problem at the bridge relay, or just a temporary
  1152. outage somewhere in between? And last, an attacker could poison our
  1153. bridge database by signing up already-blocked bridges. In this case,
  1154. if we're stingy giving out bridge addresses, users in that country won't
  1155. learn working bridges.
  1156. <div class="p"><!----></div>
  1157. All of these issues are made more complex when we try to integrate this
  1158. testing into our social network reputation system above.
  1159. Since in that case we punish or reward users based on whether bridges
  1160. get blocked, the adversary has new attacks to trick or bog down the
  1161. reputation tracking. Indeed, the bridge authority doesn't even know
  1162. what zone the blocked user is in, so do we blame him for any possible
  1163. censored zone, or what?
  1164. <div class="p"><!----></div>
  1165. Clearly more analysis is required. The eventual solution will probably
  1166. involve a combination of passive measurement via GeoIP and active
  1167. measurement from trusted testers. More generally, we can use the passive
  1168. feedback mechanism to track usage of the bridge network as a whole &mdash; which
  1169. would let us respond to attacks and adapt the design, and it would also
  1170. let the general public track the progress of the project.
  1171. <div class="p"><!----></div>
  1172. <div class="p"><!----></div>
  1173. <h3><a name="tth_sEc7.8">
  1174. 7.8</a>&nbsp;&nbsp;Advantages of deploying all solutions at once</h3>
  1175. <div class="p"><!----></div>
  1176. For once, we're not in the position of the defender: we don't have to
  1177. defend against every possible filtering scheme; we just have to defend
  1178. against at least one. On the flip side, the attacker is forced to guess
  1179. how to allocate his resources to defend against each of these discovery
  1180. strategies. So by deploying all of our strategies at once, we not only
  1181. increase our chances of finding one that the adversary has difficulty
  1182. blocking, but we actually make <em>all</em> of the strategies more robust
  1183. in the face of an adversary with limited resources.
  1184. <div class="p"><!----></div>
  1185. <div class="p"><!----></div>
  1186. <div class="p"><!----></div>
  1187. <div class="p"><!----></div>
  1188. <div class="p"><!----></div>
  1189. <div class="p"><!----></div>
  1190. <div class="p"><!----></div>
  1191. <div class="p"><!----></div>
  1192. <div class="p"><!----></div>
  1193. <div class="p"><!----></div>
  1194. <div class="p"><!----></div>
  1195. <div class="p"><!----></div>
  1196. <div class="p"><!----></div>
  1197. <div class="p"><!----></div>
  1198. <h2><a name="tth_sEc8">
  1199. <a name="sec:security">
  1200. 8</a>&nbsp;&nbsp;Security considerations</h2>
  1201. </a>
  1202. <div class="p"><!----></div>
  1203. <h3><a name="tth_sEc8.1">
  1204. 8.1</a>&nbsp;&nbsp;Possession of Tor in oppressed areas</h3>
  1205. <div class="p"><!----></div>
  1206. Many people speculate that installing and using a Tor client in areas with
  1207. particularly extreme firewalls is a high risk &mdash; and the risk increases
  1208. as the firewall gets more restrictive. This notion certain has merit, but
  1209. there's
  1210. a counter pressure as well: as the firewall gets more restrictive, more
  1211. ordinary people behind it end up using Tor for more mainstream activities,
  1212. such as learning
  1213. about Wall Street prices or looking at pictures of women's ankles. So
  1214. as the restrictive firewall pushes up the number of Tor users, the
  1215. "typical" Tor user becomes more mainstream, and therefore mere
  1216. use or possession of the Tor software is not so surprising.
  1217. <div class="p"><!----></div>
  1218. It's hard to say which of these pressures will ultimately win out,
  1219. but we should keep both sides of the issue in mind.
  1220. <div class="p"><!----></div>
  1221. <div class="p"><!----></div>
  1222. <div class="p"><!----></div>
  1223. <h3><a name="tth_sEc8.2">
  1224. <a name="subsec:upload-padding">
  1225. 8.2</a>&nbsp;&nbsp;Observers can tell who is publishing and who is reading</h3>
  1226. </a>
  1227. <div class="p"><!----></div>
  1228. Tor encrypts traffic on the local network, and it obscures the eventual
  1229. destination of the communication, but it doesn't do much to obscure the
  1230. traffic volume. In particular, a user publishing a home video will have a
  1231. different network fingerprint than a user reading an online news article.
  1232. Based on our assumption in Section&nbsp;<a href="#sec:adversary">2</a> that users who
  1233. publish material are in more danger, should we work to improve Tor's
  1234. security in this situation?
  1235. <div class="p"><!----></div>
  1236. In the general case this is an extremely challenging task:
  1237. effective <em>end-to-end traffic confirmation attacks</em>
  1238. are known where the adversary observes the origin and the
  1239. destination of traffic and confirms that they are part of the
  1240. same communication&nbsp;[<a href="#danezis:pet2004" name="CITEdanezis:pet2004">8</a>,<a href="#e2e-traffic" name="CITEe2e-traffic">24</a>]. Related are
  1241. <em>website fingerprinting attacks</em>, where the adversary downloads
  1242. a few hundred popular websites, makes a set of "fingerprints" for each
  1243. site, and then observes the target Tor client's traffic to look for
  1244. a match&nbsp;[<a href="#pet05-bissias" name="CITEpet05-bissias">4</a>,<a href="#defensive-dropping" name="CITEdefensive-dropping">21</a>]. But can we do better
  1245. against a limited adversary who just does coarse-grained sweeps looking
  1246. for unusually prolific publishers?
  1247. <div class="p"><!----></div>
  1248. One answer is for bridge users to automatically send bursts of padding
  1249. traffic periodically. (This traffic can be implemented in terms of
  1250. long-range drop cells, which are already part of the Tor specification.)
  1251. Of course, convincingly simulating an actual human publishing interesting
  1252. content is a difficult arms race, but it may be worthwhile to at least
  1253. start the race. More research remains.
  1254. <div class="p"><!----></div>
  1255. <h3><a name="tth_sEc8.3">
  1256. 8.3</a>&nbsp;&nbsp;Anonymity effects from acting as a bridge relay</h3>
  1257. <div class="p"><!----></div>
  1258. Against some attacks, relaying traffic for others can improve
  1259. anonymity. The simplest example is an attacker who owns a small number
  1260. of Tor servers. He will see a connection from the bridge, but he won't
  1261. be able to know whether the connection originated there or was relayed
  1262. from somebody else. More generally, the mere uncertainty of whether the
  1263. traffic originated from that user may be helpful.
  1264. <div class="p"><!----></div>
  1265. There are some cases where it doesn't seem to help: if an attacker can
  1266. watch all of the bridge's incoming and outgoing traffic, then it's easy
  1267. to learn which connections were relayed and which started there. (In this
  1268. case he still doesn't know the final destinations unless he is watching
  1269. them too, but in this case bridges are no better off than if they were
  1270. an ordinary client.)
  1271. <div class="p"><!----></div>
  1272. There are also some potential downsides to running a bridge. First, while
  1273. we try to make it hard to enumerate all bridges, it's still possible to
  1274. learn about some of them, and for some people just the fact that they're
  1275. running one might signal to an attacker that they place a higher value
  1276. on their anonymity. Second, there are some more esoteric attacks on Tor
  1277. relays that are not as well-understood or well-tested &mdash; for example, an
  1278. attacker may be able to "observe" whether the bridge is sending traffic
  1279. even if he can't actually watch its network, by relaying traffic through
  1280. it and noticing changes in traffic timing&nbsp;[<a href="#attack-tor-oak05" name="CITEattack-tor-oak05">25</a>]. On
  1281. the other hand, it may be that limiting the bandwidth the bridge is
  1282. willing to relay will allow this sort of attacker to determine if it's
  1283. being used as a bridge but not easily learn whether it is adding traffic
  1284. of its own.
  1285. <div class="p"><!----></div>
  1286. We also need to examine how entry guards fit in. Entry guards
  1287. (a small set of nodes that are always used for the first
  1288. step in a circuit) help protect against certain attacks
  1289. where the attacker runs a few Tor servers and waits for
  1290. the user to choose these servers as the beginning and end of her
  1291. circuit<a href="#tthFtNtAAC" name="tthFrefAAC"><sup>2</sup></a>.
  1292. If the blocked user doesn't use the bridge's entry guards, then the bridge
  1293. doesn't gain as much cover benefit. On the other hand, what design changes
  1294. are needed for the blocked user to use the bridge's entry guards without
  1295. learning what they are (this seems hard), and even if we solve that,
  1296. do they then need to use the guards' guards and so on down the line?
  1297. <div class="p"><!----></div>
  1298. It is an open research question whether the benefits of running a bridge
  1299. outweigh the risks. A lot of the decision rests on which attacks the
  1300. users are most worried about. For most users, we don't think running a
  1301. bridge relay will be that damaging, and it could help quite a bit.
  1302. <div class="p"><!----></div>
  1303. <h3><a name="tth_sEc8.4">
  1304. <a name="subsec:cafes-and-livecds">
  1305. 8.4</a>&nbsp;&nbsp;Trusting local hardware: Internet cafes and LiveCDs</h3>
  1306. </a>
  1307. <div class="p"><!----></div>
  1308. Assuming that users have their own trusted hardware is not
  1309. always reasonable.
  1310. <div class="p"><!----></div>
  1311. For Internet cafe Windows computers that let you attach your own USB key,
  1312. a USB-based Tor image would be smart. There's Torpark, and hopefully
  1313. there will be more thoroughly analyzed and trustworthy options down the
  1314. road. Worries remain about hardware or software keyloggers and other
  1315. spyware, as well as and physical surveillance.
  1316. <div class="p"><!----></div>
  1317. If the system lets you boot from a CD or from a USB key, you can gain
  1318. a bit more security by bringing a privacy LiveCD with you. (This
  1319. approach isn't foolproof either of course, since hardware
  1320. keyloggers and physical surveillance are still a worry).
  1321. <div class="p"><!----></div>
  1322. In fact, LiveCDs are also useful if it's your own hardware, since it's
  1323. easier to avoid leaving private data and logs scattered around the
  1324. system.
  1325. <div class="p"><!----></div>
  1326. <div class="p"><!----></div>
  1327. <h3><a name="tth_sEc8.5">
  1328. <a name="subsec:trust-chain">
  1329. 8.5</a>&nbsp;&nbsp;The trust chain</h3>
  1330. </a>
  1331. <div class="p"><!----></div>
  1332. Tor's "public key infrastructure" provides a chain of trust to
  1333. let users verify that they're actually talking to the right servers.
  1334. There are four pieces to this trust chain.
  1335. <div class="p"><!----></div>
  1336. First, when Tor clients are establishing circuits, at each step
  1337. they demand that the next Tor server in the path prove knowledge of
  1338. its private key&nbsp;[<a href="#tor-design" name="CITEtor-design">11</a>]. This step prevents the first node
  1339. in the path from just spoofing the rest of the path. Second, the
  1340. Tor directory authorities provide a signed list of servers along with
  1341. their public keys &mdash; so unless the adversary can control a threshold
  1342. of directory authorities, he can't trick the Tor client into using other
  1343. Tor servers. Third, the location and keys of the directory authorities,
  1344. in turn, is hard-coded in the Tor source code &mdash; so as long as the user
  1345. got a genuine version of Tor, he can know that he is using the genuine
  1346. Tor network. And last, the source code and other packages are signed
  1347. with the GPG keys of the Tor developers, so users can confirm that they
  1348. did in fact download a genuine version of Tor.
  1349. <div class="p"><!----></div>
  1350. In the case of blocked users contacting bridges and bridge directory
  1351. authorities, the same logic applies in parallel: the blocked users fetch
  1352. information from both the bridge authorities and the directory authorities
  1353. for the `main' Tor network, and they combine this information locally.
  1354. <div class="p"><!----></div>
  1355. How can a user in an oppressed country know that he has the correct
  1356. key fingerprints for the developers? As with other security systems, it
  1357. ultimately comes down to human interaction. The keys are signed by dozens
  1358. of people around the world, and we have to hope that our users have met
  1359. enough people in the PGP web of trust
  1360. that they can learn
  1361. the correct keys. For users that aren't connected to the global security
  1362. community, though, this question remains a critical weakness.
  1363. <div class="p"><!----></div>
  1364. <div class="p"><!----></div>
  1365. <div class="p"><!----></div>
  1366. <div class="p"><!----></div>
  1367. <h2><a name="tth_sEc9">
  1368. <a name="sec:reachability">
  1369. 9</a>&nbsp;&nbsp;Maintaining reachability</h2>
  1370. </a>
  1371. <div class="p"><!----></div>
  1372. <h3><a name="tth_sEc9.1">
  1373. 9.1</a>&nbsp;&nbsp;How many bridge relays should you know about?</h3>
  1374. <div class="p"><!----></div>
  1375. The strategies described in Section&nbsp;<a href="#sec:discovery">7</a> talked about
  1376. learning one bridge address at a time. But if most bridges are ordinary
  1377. Tor users on cable modem or DSL connection, many of them will disappear
  1378. and/or move periodically. How many bridge relays should a blocked user
  1379. know about so that she is likely to have at least one reachable at any
  1380. given point? This is already a challenging problem if we only consider
  1381. natural churn: the best approach is to see what bridges we attract in
  1382. reality and measure their churn. We may also need to factor in a parameter
  1383. for how quickly bridges get discovered and blocked by the attacker;
  1384. we leave this for future work after we have more deployment experience.
  1385. <div class="p"><!----></div>
  1386. A related question is: if the bridge relays change IP addresses
  1387. periodically, how often does the blocked user need to fetch updates in
  1388. order to keep from being cut out of the loop?
  1389. <div class="p"><!----></div>
  1390. Once we have more experience and intuition, we should explore technical
  1391. solutions to this problem too. For example, if the discovery strategies
  1392. give out k bridge addresses rather than a single bridge address, perhaps
  1393. we can improve robustness from the user perspective without significantly
  1394. aiding the adversary. Rather than giving out a new random subset of k
  1395. addresses at each point, we could bind them together into <em>bridge
  1396. families</em>, so all users that learn about one member of the bridge family
  1397. are told about the rest as well.
  1398. <div class="p"><!----></div>
  1399. This scheme may also help defend against attacks to map the set of
  1400. bridges. That is, if all blocked users learn a random subset of bridges,
  1401. the attacker should learn about a few bridges, monitor the country-level
  1402. firewall for connections to them, then watch those users to see what
  1403. other bridges they use, and repeat. By segmenting the bridge address
  1404. space, we can limit the exposure of other users.
  1405. <div class="p"><!----></div>
  1406. <h3><a name="tth_sEc9.2">
  1407. <a name="subsec:block-cable">
  1408. 9.2</a>&nbsp;&nbsp;Cablemodem users don't usually provide important websites</h3>
  1409. </a>
  1410. <div class="p"><!----></div>
  1411. Another attacker we might be concerned about is that the attacker could
  1412. just block all DSL and cablemodem network addresses, on the theory that
  1413. they don't run any important services anyway. If most of our bridges
  1414. are on these networks, this attack could really hurt.
  1415. <div class="p"><!----></div>
  1416. The first answer is to aim to get volunteers both from traditionally
  1417. "consumer" networks and also from traditionally "producer" networks.
  1418. Since bridges don't need to be Tor exit nodes, as we improve our usability
  1419. it seems quite feasible to get a lot of websites helping out.
  1420. <div class="p"><!----></div>
  1421. The second answer (not as practical) would be to encourage more use of
  1422. consumer networks for popular and useful Internet services.
  1423. <div class="p"><!----></div>
  1424. A related attack we might worry about is based on large countries putting
  1425. economic pressure on companies that want to expand their business. For
  1426. example, what happens if Verizon wants to sell services in China, and
  1427. China pressures Verizon to discourage its users in the free world from
  1428. running bridges?
  1429. <div class="p"><!----></div>
  1430. <h3><a name="tth_sEc9.3">
  1431. 9.3</a>&nbsp;&nbsp;Scanning resistance: making bridges more subtle</h3>
  1432. <div class="p"><!----></div>
  1433. If it's trivial to verify that a given address is operating as a bridge,
  1434. and most bridges run on a predictable port, then it's conceivable our
  1435. attacker could scan the whole Internet looking for bridges. (In fact,
  1436. he can just concentrate on scanning likely networks like cablemodem
  1437. and DSL services &mdash; see Section&nbsp;<a href="#subsec:block-cable">9.2</a>
  1438. above for
  1439. related attacks.) It would be nice to slow down this attack. It would
  1440. be even nicer to make it hard to learn whether we're a bridge without
  1441. first knowing some secret. We call this general property <em>scanning
  1442. resistance</em>, and it goes along with normalizing Tor's TLS handshake and
  1443. network fingerprint.
  1444. <div class="p"><!----></div>
  1445. We could provide a password to the blocked user, and she (or her Tor
  1446. client) provides a nonced hash of this password when she connects. We'd
  1447. need to give her an ID key for the bridge too (in addition to the IP
  1448. address and port &mdash; see Section&nbsp;<a href="#subsec:id-address">6.1</a>), and wait to
  1449. present the password until we've finished the TLS handshake, else it
  1450. would look unusual. If Alice can authenticate the bridge before she
  1451. tries to send her password, we can resist an adversary who pretends
  1452. to be the bridge and launches a man-in-the-middle attack to learn the
  1453. password. But even if she can't, we still resist against widespread
  1454. scanning.
  1455. <div class="p"><!----></div>
  1456. How should the bridge behave if accessed without the correct
  1457. authorization? Perhaps it should act like an unconfigured HTTPS server
  1458. ("welcome to the default Apache page"), or maybe it should mirror
  1459. and act like common websites, or websites randomly chosen from Google.
  1460. <div class="p"><!----></div>
  1461. We might assume that the attacker can recognize HTTPS connections that
  1462. use self-signed certificates. (This process would be resource-intensive
  1463. but not out of the realm of possibility.) But even in this case, many
  1464. popular websites around the Internet use self-signed or just plain broken
  1465. SSL certificates.
  1466. <div class="p"><!----></div>
  1467. <div class="p"><!----></div>
  1468. <div class="p"><!----></div>
  1469. <div class="p"><!----></div>
  1470. <h3><a name="tth_sEc9.4">
  1471. <a name="subsec:incentives">
  1472. 9.4</a>&nbsp;&nbsp;How to motivate people to run bridge relays</h3>
  1473. </a>
  1474. <div class="p"><!----></div>
  1475. One of the traditional ways to get people to run software that benefits
  1476. others is to give them motivation to install it themselves. An often
  1477. suggested approach is to install it as a stunning screensaver so everybody
  1478. will be pleased to run it. We take a similar approach here, by leveraging
  1479. the fact that these users are already interested in protecting their
  1480. own Internet traffic, so they will install and run the software.
  1481. <div class="p"><!----></div>
  1482. Eventually, we may be able to make all Tor users become bridges if they
  1483. pass their self-reachability tests &mdash; the software and installers need
  1484. more work on usability first, but we're making progress.
  1485. <div class="p"><!----></div>
  1486. In the mean time, we can make a snazzy network graph with
  1487. Vidalia<a href="#tthFtNtAAD" name="tthFrefAAD"><sup>3</sup></a> that
  1488. emphasizes the connections the bridge user is currently relaying.
  1489. <div class="p"><!----></div>
  1490. <div class="p"><!----></div>
  1491. <div class="p"><!----></div>
  1492. <div class="p"><!----></div>
  1493. <div class="p"><!----></div>
  1494. <div class="p"><!----></div>
  1495. <div class="p"><!----></div>
  1496. <div class="p"><!----></div>
  1497. <h3><a name="tth_sEc9.5">
  1498. <a name="subsec:publicity">
  1499. 9.5</a>&nbsp;&nbsp;Publicity attracts attention</h3>
  1500. </a>
  1501. <div class="p"><!----></div>
  1502. Many people working on this field want to publicize the existence
  1503. and extent of censorship concurrently with the deployment of their
  1504. circumvention software. The easy reason for this two-pronged push is
  1505. to attract volunteers for running proxies in their systems; but in many
  1506. cases their main goal is not to focus on actually allowing individuals
  1507. to circumvent the firewall, but rather to educate the world about the
  1508. censorship. The media also tries to do its part by broadcasting the
  1509. existence of each new circumvention system.
  1510. <div class="p"><!----></div>
  1511. But at the same time, this publicity attracts the attention of the
  1512. censors. We can slow down the arms race by not attracting as much
  1513. attention, and just spreading by word of mouth. If our goal is to
  1514. establish a solid social network of bridges and bridge users before
  1515. the adversary gets involved, does this extra attention work to our
  1516. disadvantage?
  1517. <div class="p"><!----></div>
  1518. <h3><a name="tth_sEc9.6">
  1519. 9.6</a>&nbsp;&nbsp;The Tor website: how to get the software</h3>
  1520. <div class="p"><!----></div>
  1521. One of the first censoring attacks against a system like ours is to
  1522. block the website and make the software itself hard to find. Our system
  1523. should work well once the user is running an authentic
  1524. copy of Tor and has found a working bridge, but to get to that point
  1525. we rely on their individual skills and ingenuity.
  1526. <div class="p"><!----></div>
  1527. Right now, most countries that block access to Tor block only the main
  1528. website and leave mirrors and the network itself untouched.
  1529. Falling back on word-of-mouth is always a good last resort, but we should
  1530. also take steps to make sure it's relatively easy for users to get a copy,
  1531. such as publicizing the mirrors more and making copies available through
  1532. other media. We might also mirror the latest version of the software on
  1533. each bridge, so users who hear about an honest bridge can get a good
  1534. copy.
  1535. See Section&nbsp;<a href="#subsec:first-bridge">7.1</a> for more discussion.
  1536. <div class="p"><!----></div>
  1537. <div class="p"><!----></div>
  1538. <h2><a name="tth_sEc10">
  1539. <a name="sec:future">
  1540. 10</a>&nbsp;&nbsp;Future designs</h2>
  1541. </a>
  1542. <div class="p"><!----></div>
  1543. <h3><a name="tth_sEc10.1">
  1544. 10.1</a>&nbsp;&nbsp;Bridges inside the blocked network too</h3>
  1545. <div class="p"><!----></div>
  1546. Assuming actually crossing the firewall is the risky part of the
  1547. operation, can we have some bridge relays inside the blocked area too,
  1548. and more established users can use them as relays so they don't need to
  1549. communicate over the firewall directly at all? A simple example here is
  1550. to make new blocked users into internal bridges also &mdash; so they sign up
  1551. on the bridge authority as part of doing their query, and we give out
  1552. their addresses
  1553. rather than (or along with) the external bridge addresses. This design
  1554. is a lot trickier because it brings in the complexity of whether the
  1555. internal bridges will remain available, can maintain reachability with
  1556. the outside world, etc.
  1557. <div class="p"><!----></div>
  1558. More complex future designs involve operating a separate Tor network
  1559. inside the blocked area, and using <em>hidden service bridges</em> &mdash; bridges
  1560. that can be accessed by users of the internal Tor network but whose
  1561. addresses are not published or findable, even by these users &mdash; to get
  1562. from inside the firewall to the rest of the Internet. But this design
  1563. requires directory authorities to run inside the blocked area too,
  1564. and they would be a fine target to take down the network.
  1565. <div class="p"><!----></div>
  1566. <div class="p"><!----></div>
  1567. <h2><a name="tth_sEc11">
  1568. <a name="sec:conclusion">
  1569. 11</a>&nbsp;&nbsp;Next Steps</h2>
  1570. </a>
  1571. <div class="p"><!----></div>
  1572. Technical solutions won't solve the whole censorship problem. After all,
  1573. the firewalls in places like China are <em>socially</em> very
  1574. successful, even if technologies and tricks exist to get around them.
  1575. However, having a strong technical solution is still necessary as one
  1576. important piece of the puzzle.
  1577. <div class="p"><!----></div>
  1578. In this paper, we have shown that Tor provides a great set of building
  1579. blocks to start from. The next steps are to deploy prototype bridges and
  1580. bridge authorities, implement some of the proposed discovery strategies,
  1581. and then observe the system in operation and get more intuition about
  1582. the actual requirements and adversaries we're up against.
  1583. <div class="p"><!----></div>
  1584. <h2>References</h2>
  1585. <dl compact="compact">
  1586. <dt><a href="#CITEeconymics" name="econymics">[1]</a></dt><dd>
  1587. Alessandro Acquisti, Roger Dingledine, and Paul Syverson.
  1588. On the economics of anonymity.
  1589. In Rebecca&nbsp;N. Wright, editor, <em>Financial Cryptography</em>.
  1590. Springer-Verlag, LNCS 2742, 2003.
  1591. <div class="p"><!----></div>
  1592. </dd>
  1593. <dt><a href="#CITEfreedom21-security" name="freedom21-security">[2]</a></dt><dd>
  1594. Adam Back, Ian Goldberg, and Adam Shostack.
  1595. Freedom systems 2.1 security issues and analysis.
  1596. White paper, Zero Knowledge Systems, Inc., May 2001.
  1597. <div class="p"><!----></div>
  1598. </dd>
  1599. <dt><a href="#CITEweb-mix" name="web-mix">[3]</a></dt><dd>
  1600. Oliver Berthold, Hannes Federrath, and Stefan K&#246;psell.
  1601. Web MIXes: A system for anonymous and unobservable Internet
  1602. access.
  1603. In H.&nbsp;Federrath, editor, <em>Designing Privacy Enhancing
  1604. Technologies: Workshop on Design Issue in Anonymity and Unobservability</em>.
  1605. Springer-Verlag, LNCS 2009, 2000.
  1606. <div class="p"><!----></div>
  1607. </dd>
  1608. <dt><a href="#CITEpet05-bissias" name="pet05-bissias">[4]</a></dt><dd>
  1609. George&nbsp;Dean Bissias, Marc Liberatore, and Brian&nbsp;Neil Levine.
  1610. Privacy vulnerabilities in encrypted http streams.
  1611. In <em>Proceedings of Privacy Enhancing Technologies workshop (PET
  1612. 2005)</em>, May 2005.
  1613. <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>.
  1614. <div class="p"><!----></div>
  1615. </dd>
  1616. <dt><a href="#CITEchaum-blind" name="chaum-blind">[5]</a></dt><dd>
  1617. David Chaum.
  1618. Blind signatures for untraceable payments.
  1619. In D.&nbsp;Chaum, R.L. Rivest, and A.T. Sherman, editors, <em>Advances in
  1620. Cryptology: Proceedings of Crypto 82</em>, pages 199-203. Plenum Press, 1983.
  1621. <div class="p"><!----></div>
  1622. </dd>
  1623. <dt><a href="#CITEfreenet-pets00" name="freenet-pets00">[6]</a></dt><dd>
  1624. Ian Clarke, Oskar Sandberg, Brandon Wiley, and Theodore&nbsp;W. Hong.
  1625. Freenet: A distributed anonymous information storage and retrieval
  1626. system.
  1627. In H.&nbsp;Federrath, editor, <em>Designing Privacy Enhancing
  1628. Technologies: Workshop on Design Issue in Anonymity and Unobservability</em>,
  1629. pages 46-66. Springer-Verlag, LNCS 2009, July 2000.
  1630. <div class="p"><!----></div>
  1631. </dd>
  1632. <dt><a href="#CITEclayton:pet2006" name="clayton:pet2006">[7]</a></dt><dd>
  1633. Richard Clayton, Steven&nbsp;J. Murdoch, and Robert N.&nbsp;M. Watson.
  1634. Ignoring the great firewall of china.
  1635. In <em>Proceedings of the Sixth Workshop on Privacy Enhancing
  1636. Technologies (PET 2006)</em>, Cambridge, UK, June 2006. Springer.
  1637. <a href="http://www.cl.cam.ac.uk/~rnc1/ignoring.pdf"><tt>http://www.cl.cam.ac.uk/~rnc1/ignoring.pdf</tt></a>.
  1638. <div class="p"><!----></div>
  1639. </dd>
  1640. <dt><a href="#CITEdanezis:pet2004" name="danezis:pet2004">[8]</a></dt><dd>
  1641. George Danezis.
  1642. The traffic analysis of continuous-time mixes.
  1643. In David Martin and Andrei Serjantov, editors, <em>Privacy Enhancing
  1644. Technologies (PET 2004)</em>, LNCS, May 2004.
  1645. <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>.
  1646. <div class="p"><!----></div>
  1647. </dd>
  1648. <dt><a href="#CITEusability:weis2006" name="usability:weis2006">[9]</a></dt><dd>
  1649. Roger Dingledine and Nick Mathewson.
  1650. Anonymity loves company: Usability and the network effect.
  1651. In <em>Proceedings of the Fifth Workshop on the Economics of
  1652. Information Security (WEIS 2006)</em>, Cambridge, UK, June 2006.
  1653. <a href="http://freehaven.net/doc/wupss04/usability.pdf"><tt>http://freehaven.net/doc/wupss04/usability.pdf</tt></a>.
  1654. <div class="p"><!----></div>
  1655. </dd>
  1656. <dt><a href="#CITErep-anon" name="rep-anon">[10]</a></dt><dd>
  1657. Roger Dingledine, Nick Mathewson, and Paul Syverson.
  1658. Reputation in P2P Anonymity Systems.
  1659. In <em>Proceedings of Workshop on Economics of Peer-to-Peer
  1660. Systems</em>, June 2003.
  1661. <a href="http://freehaven.net/doc/econp2p03/econp2p03.pdf"><tt>http://freehaven.net/doc/econp2p03/econp2p03.pdf</tt></a>.
  1662. <div class="p"><!----></div>
  1663. </dd>
  1664. <dt><a href="#CITEtor-design" name="tor-design">[11]</a></dt><dd>
  1665. Roger Dingledine, Nick Mathewson, and Paul Syverson.
  1666. Tor: The second-generation onion router.
  1667. In <em>Proceedings of the 13th USENIX Security Symposium</em>, August
  1668. 2004.
  1669. <a href="http://tor.eff.org/tor-design.pdf"><tt>http://tor.eff.org/tor-design.pdf</tt></a>.
  1670. <div class="p"><!----></div>
  1671. </dd>
  1672. <dt><a href="#CITEcasc-rep" name="casc-rep">[12]</a></dt><dd>
  1673. Roger Dingledine and Paul Syverson.
  1674. Reliable MIX Cascade Networks through Reputation.
  1675. In Matt Blaze, editor, <em>Financial Cryptography</em>. Springer-Verlag,
  1676. LNCS 2357, 2002.
  1677. <div class="p"><!----></div>
  1678. </dd>
  1679. <dt><a href="#CITEpsiphon" name="psiphon">[13]</a></dt><dd>
  1680. Ronald&nbsp;Deibert et&nbsp;al.
  1681. Psiphon.
  1682. <a href="http://psiphon.civisec.org/"><tt>http://psiphon.civisec.org/</tt></a>.
  1683. <div class="p"><!----></div>
  1684. </dd>
  1685. <dt><a href="#CITEinfranet" name="infranet">[14]</a></dt><dd>
  1686. Nick Feamster, Magdalena Balazinska, Greg Harfst, Hari Balakrishnan, and David
  1687. Karger.
  1688. Infranet: Circumventing web censorship and surveillance.
  1689. In <em>Proceedings of the 11th USENIX Security Symposium</em>, August
  1690. 2002.
  1691. <a href="http://nms.lcs.mit.edu/~feamster/papers/usenixsec2002.pdf"><tt>http://nms.lcs.mit.edu/~feamster/papers/usenixsec2002.pdf</tt></a>.
  1692. <div class="p"><!----></div>
  1693. </dd>
  1694. <dt><a href="#CITEactive-wardens" name="active-wardens">[15]</a></dt><dd>
  1695. Gina Fisk, Mike Fisk, Christos Papadopoulos, and Joshua Neil.
  1696. Eliminating steganography in internet traffic with active wardens.
  1697. In Fabien Petitcolas, editor, <em>Information Hiding Workshop (IH
  1698. 2002)</em>. Springer-Verlag, LNCS 2578, October 2002.
  1699. <div class="p"><!----></div>
  1700. </dd>
  1701. <dt><a href="#CITEblossom-thesis" name="blossom-thesis">[16]</a></dt><dd>
  1702. Geoffrey Goodell.
  1703. <em>Perspective Access Networks</em>.
  1704. PhD thesis, Harvard University, July 2006.
  1705. <a href="http://afs.eecs.harvard.edu/~goodell/thesis.pdf"><tt>http://afs.eecs.harvard.edu/~goodell/thesis.pdf</tt></a>.
  1706. <div class="p"><!----></div>
  1707. </dd>
  1708. <dt><a href="#CITEgoodell-syverson06" name="goodell-syverson06">[17]</a></dt><dd>
  1709. Geoffrey Goodell and Paul Syverson.
  1710. The right place at the right time: The use of network location in
  1711. authentication and abuse prevention, 2006.
  1712. Submitted.
  1713. <div class="p"><!----></div>
  1714. </dd>
  1715. <dt><a href="#CITEcircumventor" name="circumventor">[18]</a></dt><dd>
  1716. Bennett Haselton.
  1717. How to install the Circumventor program.
  1718. <a href="http://www.peacefire.org/circumventor/simple-circumventor-instructions.html"><tt>http://www.peacefire.org/circumventor/simple-circumventor-instructions.html</tt></a>.
  1719. <div class="p"><!----></div>
  1720. </dd>
  1721. <dt><a href="#CITEip-to-country" name="ip-to-country">[19]</a></dt><dd>
  1722. Ip-to-country database.
  1723. <a href="http://ip-to-country.webhosting.info/"><tt>http://ip-to-country.webhosting.info/</tt></a>.
  1724. <div class="p"><!----></div>
  1725. </dd>
  1726. <dt><a href="#CITEkoepsell:wpes2004" name="koepsell:wpes2004">[20]</a></dt><dd>
  1727. Stefan K&#246;psell and Ulf Hilling.
  1728. How to achieve blocking resistance for existing systems enabling
  1729. anonymous web surfing.
  1730. In <em>Proceedings of the Workshop on Privacy in the Electronic
  1731. Society (WPES 2004)</em>, Washington, DC, USA, October 2004.
  1732. <a href="http://freehaven.net/anonbib/papers/p103-koepsell.pdf"><tt>http://freehaven.net/anonbib/papers/p103-koepsell.pdf</tt></a>.
  1733. <div class="p"><!----></div>
  1734. </dd>
  1735. <dt><a href="#CITEdefensive-dropping" name="defensive-dropping">[21]</a></dt><dd>
  1736. Brian&nbsp;N. Levine, Michael&nbsp;K. Reiter, Chenxi Wang, and Matthew Wright.
  1737. Timing analysis in low-latency mix-based systems.
  1738. In Ari Juels, editor, <em>Financial Cryptography</em>. Springer-Verlag,
  1739. LNCS (forthcoming), 2004.
  1740. <div class="p"><!----></div>
  1741. </dd>
  1742. <dt><a href="#CITEmackinnon-personal" name="mackinnon-personal">[22]</a></dt><dd>
  1743. Rebecca MacKinnon.
  1744. Private communication, 2006.
  1745. <div class="p"><!----></div>
  1746. </dd>
  1747. <dt><a href="#CITEcgiproxy" name="cgiproxy">[23]</a></dt><dd>
  1748. James Marshall.
  1749. CGIProxy: HTTP/FTP Proxy in a CGI Script.
  1750. <a href="http://www.jmarshall.com/tools/cgiproxy/"><tt>http://www.jmarshall.com/tools/cgiproxy/</tt></a>.
  1751. <div class="p"><!----></div>
  1752. </dd>
  1753. <dt><a href="#CITEe2e-traffic" name="e2e-traffic">[24]</a></dt><dd>
  1754. Nick Mathewson and Roger Dingledine.
  1755. Practical traffic analysis: Extending and resisting statistical
  1756. disclosure.
  1757. In David Martin and Andrei Serjantov, editors, <em>Privacy Enhancing
  1758. Technologies (PET 2004)</em>, LNCS, May 2004.
  1759. <a href="http://freehaven.net/doc/e2e-traffic/e2e-traffic.pdf"><tt>http://freehaven.net/doc/e2e-traffic/e2e-traffic.pdf</tt></a>.
  1760. <div class="p"><!----></div>
  1761. </dd>
  1762. <dt><a href="#CITEattack-tor-oak05" name="attack-tor-oak05">[25]</a></dt><dd>
  1763. Steven&nbsp;J. Murdoch and George Danezis.
  1764. Low-cost traffic analysis of tor.
  1765. In <em>IEEE Symposium on Security and Privacy</em>. IEEE CS, May 2005.
  1766. <div class="p"><!----></div>
  1767. </dd>
  1768. <dt><a href="#CITEtcpstego" name="tcpstego">[26]</a></dt><dd>
  1769. Steven&nbsp;J. Murdoch and Stephen Lewis.
  1770. Embedding covert channels into TCP/IP.
  1771. In Mauro Barni, Jordi Herrera-Joancomart&#237;, Stefan Katzenbeisser,
  1772. and Fernando P&#233;rez-Gonz&#225;lez, editors, <em>Information Hiding: 7th
  1773. International Workshop</em>, volume 3727 of <em>LNCS</em>, pages 247-261,
  1774. Barcelona, Catalonia (Spain), June 2005. Springer-Verlag.
  1775. <div class="p"><!----></div>
  1776. </dd>
  1777. <dt><a href="#CITEptacek98insertion" name="ptacek98insertion">[27]</a></dt><dd>
  1778. Thomas&nbsp;H. Ptacek and Timothy&nbsp;N. Newsham.
  1779. Insertion, evasion, and denial of service: Eluding network intrusion
  1780. detection.
  1781. Technical report, Secure Networks, Inc., Suite 330, 1201 5th Street
  1782. S.W, Calgary, Alberta, Canada, T2R-0Y6, 1998.
  1783. <div class="p"><!----></div>
  1784. </dd>
  1785. <dt><a href="#CITEzuckerman-threatmodels" name="zuckerman-threatmodels">[28]</a></dt><dd>
  1786. Ethan Zuckerman.
  1787. We've got to adjust some of our threat models.
  1788. <a href="http://www.ethanzuckerman.com/blog/?p=1019"><tt>http://www.ethanzuckerman.com/blog/?p=1019</tt></a>.</dd>
  1789. </dl>
  1790. <div class="p"><!----></div>
  1791. <div class="p"><!----></div>
  1792. <div class="p"><!----></div>
  1793. <hr /><h3>Footnotes:</h3>
  1794. <div class="p"><!----></div>
  1795. <a name="tthFtNtAAB"></a><a href="#tthFrefAAB"><sup>1</sup></a>So far in places
  1796. like China, the authorities mainly go after people who publish materials
  1797. and coordinate organized movements&nbsp;[<a href="#mackinnon-personal" name="CITEmackinnon-personal">22</a>].
  1798. If they find that a
  1799. user happens to be reading a site that should be blocked, the typical
  1800. response is simply to block the site. Of course, even with an encrypted
  1801. connection, the adversary may be able to distinguish readers from
  1802. publishers by observing whether Alice is mostly downloading bytes or mostly
  1803. uploading them &mdash; we discuss this issue more in
  1804. Section&nbsp;<a href="#subsec:upload-padding">8.2</a>.
  1805. <div class="p"><!----></div>
  1806. <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>
  1807. <div class="p"><!----></div>
  1808. <a name="tthFtNtAAD"></a><a href="#tthFrefAAD"><sup>3</sup></a><a href="http://vidalia-project.net/"><tt>http://vidalia-project.net/</tt></a>
  1809. <br /><br /><hr /><small>File translated from
  1810. T<sub><font size="-1">E</font></sub>X
  1811. by <a href="http://hutchinson.belmont.ma.us/tth/">
  1812. T<sub><font size="-1">T</font></sub>H</a>,
  1813. version 3.77.<br />On 11 May 2007, 21:49.</small>
  1814. </html>