blocking.tex 88 KB

12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576777879808182838485868788899091929394959697989910010110210310410510610710810911011111211311411511611711811912012112212312412512612712812913013113213313413513613713813914014114214314414514614714814915015115215315415515615715815916016116216316416516616716816917017117217317417517617717817918018118218318418518618718818919019119219319419519619719819920020120220320420520620720820921021121221321421521621721821922022122222322422522622722822923023123223323423523623723823924024124224324424524624724824925025125225325425525625725825926026126226326426526626726826927027127227327427527627727827928028128228328428528628728828929029129229329429529629729829930030130230330430530630730830931031131231331431531631731831932032132232332432532632732832933033133233333433533633733833934034134234334434534634734834935035135235335435535635735835936036136236336436536636736836937037137237337437537637737837938038138238338438538638738838939039139239339439539639739839940040140240340440540640740840941041141241341441541641741841942042142242342442542642742842943043143243343443543643743843944044144244344444544644744844945045145245345445545645745845946046146246346446546646746846947047147247347447547647747847948048148248348448548648748848949049149249349449549649749849950050150250350450550650750850951051151251351451551651751851952052152252352452552652752852953053153253353453553653753853954054154254354454554654754854955055155255355455555655755855956056156256356456556656756856957057157257357457557657757857958058158258358458558658758858959059159259359459559659759859960060160260360460560660760860961061161261361461561661761861962062162262362462562662762862963063163263363463563663763863964064164264364464564664764864965065165265365465565665765865966066166266366466566666766866967067167267367467567667767867968068168268368468568668768868969069169269369469569669769869970070170270370470570670770870971071171271371471571671771871972072172272372472572672772872973073173273373473573673773873974074174274374474574674774874975075175275375475575675775875976076176276376476576676776876977077177277377477577677777877978078178278378478578678778878979079179279379479579679779879980080180280380480580680780880981081181281381481581681781881982082182282382482582682782882983083183283383483583683783883984084184284384484584684784884985085185285385485585685785885986086186286386486586686786886987087187287387487587687787887988088188288388488588688788888989089189289389489589689789889990090190290390490590690790890991091191291391491591691791891992092192292392492592692792892993093193293393493593693793893994094194294394494594694794894995095195295395495595695795895996096196296396496596696796896997097197297397497597697797897998098198298398498598698798898999099199299399499599699799899910001001100210031004100510061007100810091010101110121013101410151016101710181019102010211022102310241025102610271028102910301031103210331034103510361037103810391040104110421043104410451046104710481049105010511052105310541055105610571058105910601061106210631064106510661067106810691070107110721073107410751076107710781079108010811082108310841085108610871088108910901091109210931094109510961097109810991100110111021103110411051106110711081109111011111112111311141115111611171118111911201121112211231124112511261127112811291130113111321133113411351136113711381139114011411142114311441145114611471148114911501151115211531154115511561157115811591160116111621163116411651166116711681169117011711172117311741175117611771178117911801181118211831184118511861187118811891190119111921193119411951196119711981199120012011202120312041205120612071208120912101211121212131214121512161217121812191220122112221223122412251226122712281229123012311232123312341235123612371238123912401241124212431244124512461247124812491250125112521253125412551256125712581259126012611262126312641265126612671268126912701271127212731274127512761277127812791280128112821283128412851286128712881289129012911292129312941295129612971298129913001301130213031304130513061307130813091310131113121313131413151316131713181319132013211322132313241325132613271328132913301331133213331334133513361337133813391340134113421343134413451346134713481349135013511352135313541355135613571358135913601361136213631364136513661367136813691370137113721373137413751376137713781379138013811382138313841385138613871388138913901391139213931394139513961397139813991400140114021403140414051406140714081409141014111412141314141415141614171418141914201421142214231424142514261427142814291430143114321433143414351436143714381439144014411442144314441445144614471448144914501451145214531454145514561457145814591460146114621463146414651466146714681469147014711472147314741475147614771478147914801481148214831484148514861487148814891490149114921493149414951496149714981499150015011502150315041505150615071508150915101511151215131514151515161517151815191520152115221523152415251526152715281529153015311532153315341535153615371538153915401541154215431544154515461547154815491550155115521553155415551556155715581559156015611562156315641565156615671568156915701571157215731574157515761577157815791580158115821583158415851586158715881589159015911592159315941595159615971598159916001601160216031604160516061607160816091610161116121613161416151616161716181619162016211622162316241625162616271628162916301631163216331634163516361637163816391640164116421643164416451646164716481649165016511652165316541655165616571658165916601661166216631664166516661667166816691670167116721673167416751676167716781679168016811682168316841685168616871688168916901691169216931694169516961697169816991700170117021703170417051706170717081709171017111712171317141715171617171718171917201721172217231724172517261727172817291730
  1. \documentclass{llncs}
  2. \usepackage{url}
  3. \usepackage{amsmath}
  4. \usepackage{epsfig}
  5. \setlength{\textwidth}{5.9in}
  6. \setlength{\textheight}{8.4in}
  7. \setlength{\topmargin}{.5cm}
  8. \setlength{\oddsidemargin}{1cm}
  9. \setlength{\evensidemargin}{1cm}
  10. \newenvironment{tightlist}{\begin{list}{$\bullet$}{
  11. \setlength{\itemsep}{0mm}
  12. \setlength{\parsep}{0mm}
  13. % \setlength{\labelsep}{0mm}
  14. % \setlength{\labelwidth}{0mm}
  15. % \setlength{\topsep}{0mm}
  16. }}{\end{list}}
  17. \begin{document}
  18. \title{Design of a blocking-resistant anonymity system\\DRAFT}
  19. %\author{Roger Dingledine\inst{1} \and Nick Mathewson\inst{1}}
  20. \author{Roger Dingledine \and Nick Mathewson}
  21. \institute{The Free Haven Project\\
  22. \email{\{arma,nickm\}@freehaven.net}}
  23. \maketitle
  24. \pagestyle{plain}
  25. \begin{abstract}
  26. Websites around the world are increasingly being blocked by
  27. government-level firewalls. Many people use anonymizing networks like
  28. Tor to contact sites without letting an attacker trace their activities,
  29. and as an added benefit they are no longer affected by local censorship.
  30. But if the attacker simply denies access to the Tor network itself,
  31. blocked users can no longer benefit from the security Tor offers.
  32. Here we describe a design that builds upon the current Tor network
  33. to provide an anonymizing network that resists blocking
  34. by government-level attackers.
  35. \end{abstract}
  36. \section{Introduction and Goals}
  37. Anonymizing networks such as Tor~\cite{tor-design} bounce traffic around
  38. a network of relays. They aim to hide not only what is being said, but
  39. also who is communicating with whom, which users are using which websites,
  40. and so on. These systems have a broad range of users, including ordinary
  41. citizens who want to avoid being profiled for targeted advertisements,
  42. corporations who don't want to reveal information to their competitors,
  43. and law enforcement and government intelligence agencies who need to do
  44. operations on the Internet without being noticed.
  45. Historically, research on anonymizing systems has focused on a passive
  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. An increasing number of users are using the Tor software
  54. less for its anonymity properties than for its censorship
  55. resistance properties---if they use Tor to access Internet sites like
  56. Wikipedia
  57. and Blogspot, they are no longer affected by local censorship
  58. and firewall rules. In fact, an informal user study (described in
  59. Appendix~\ref{app:geoip}) showed China as the third largest user base
  60. for Tor clients, with perhaps ten thousand people accessing the Tor
  61. network from China each day.
  62. The current Tor design is easy to block if the attacker controls Alice's
  63. connection to the Tor network---by blocking the directory authorities,
  64. by blocking all the server IP addresses in the directory, or by filtering
  65. based on the signature of the Tor TLS handshake. Here we describe a
  66. design that builds upon the current Tor network to provide an anonymizing
  67. network that also resists this blocking. Specifically,
  68. Section~\ref{sec:adversary} discusses our threat model---that is,
  69. the assumptions we make about our adversary; Section~\ref{sec:current-tor}
  70. describes the components of the current Tor design and how they can be
  71. leveraged for a new blocking-resistant design; Section~\ref{sec:related}
  72. explains the features and drawbacks of the currently deployed solutions;
  73. and ...
  74. % The other motivation is for places where we're concerned they will
  75. % try to enumerate a list of Tor users. So even if they're not blocking
  76. % the Tor network, it may be smart to not be visible as connecting to it.
  77. %And adding more different classes of users and goals to the Tor network
  78. %improves the anonymity for all Tor users~\cite{econymics,usability:weis2006}.
  79. % Adding use classes for countering blocking as well as anonymity has
  80. % benefits too. Should add something about how providing undetected
  81. % access to Tor would facilitate people talking to, e.g., govt. authorities
  82. % about threats to public safety etc. in an environment where Tor use
  83. % is not otherwise widespread and would make one stand out.
  84. \section{Adversary assumptions}
  85. \label{sec:adversary}
  86. The history of blocking-resistance designs is littered with conflicting
  87. assumptions about what adversaries to expect and what problems are
  88. in the critical path to a solution. Here we try to enumerate our best
  89. understanding of the current situation around the world.
  90. In the traditional security style, we aim to describe a strong
  91. attacker---if we can defend against this attacker, we inherit protection
  92. against weaker attackers as well. After all, we want a general design
  93. that will work for citizens of China, Iran, Thailand, and other censored
  94. countries; for
  95. whistleblowers in firewalled corporate network; and for people in
  96. unanticipated oppressive situations. In fact, by designing with
  97. a variety of adversaries in mind, we can take advantage of the fact that
  98. adversaries will be in different stages of the arms race at each location,
  99. so a server blocked in one locale can still be useful in others.
  100. We assume there are three main network attacks in use by censors
  101. currently~\cite{clayton:pet2006}:
  102. \begin{tightlist}
  103. \item Block a destination or type of traffic by automatically searching for
  104. certain strings or patterns in TCP packets.
  105. \item Block a destination by manually listing its IP address at the
  106. firewall.
  107. \item Intercept DNS requests and give bogus responses for certain
  108. destination hostnames.
  109. \end{tightlist}
  110. We assume the network firewall has limited CPU and memory per
  111. connection~\cite{clayton:pet2006}. Against an adversary who carefully
  112. examines the contents of every packet, we would need
  113. some stronger mechanism such as steganography, which introduces its
  114. own problems~\cite{active-wardens,tcpstego,bar}.
  115. More broadly, we assume that the authorities are more likely to
  116. block a given system as its popularity grows. That is, a system
  117. used by only a few users will probably never be blocked, whereas a
  118. well-publicized system with many users will receive much more scrutiny.
  119. We assume that readers of blocked content are not in as much danger
  120. as publishers. So far in places like China, the authorities mainly go
  121. after people who publish materials and coordinate organized
  122. movements~\cite{mackinnon}.
  123. If they find that a user happens
  124. to be reading a site that should be blocked, the typical response is
  125. simply to block the site. Of course, even with an encrypted connection,
  126. the adversary may be able to distinguish readers from publishers by
  127. observing whether Alice is mostly downloading bytes or mostly uploading
  128. them---we discuss this issue more in Section~\ref{subsec:upload-padding}.
  129. We assume that while various different regimes can coordinate and share
  130. notes, there will be a time lag between one attacker learning
  131. how to overcome a facet of our design and other attackers picking it up.
  132. Similarly, we assume that in the early stages of deployment the insider
  133. threat isn't as high of a risk, because no attackers have put serious
  134. effort into breaking the system yet.
  135. We do not assume that government-level attackers are always uniform across
  136. the country. For example, there is no single centralized place in China
  137. that coordinates its specific censorship decisions and steps.
  138. We assume that our users have control over their hardware and
  139. software---they don't have any spyware installed, there are no
  140. cameras watching their screens, etc. Unfortunately, in many situations
  141. these threats are real~\cite{zuckerman-threatmodels}; yet
  142. software-based security systems like ours are poorly equipped to handle
  143. a user who is entirely observed and controlled by the adversary. See
  144. Section~\ref{subsec:cafes-and-livecds} for more discussion of what little
  145. we can do about this issue.
  146. We assume that widespread access to the Internet is economically,
  147. politically, and/or
  148. socially valuable to the policymakers of each deployment country. After
  149. all, if censorship
  150. is more important than Internet access, the firewall administrators have
  151. an easy job: they should simply block everything. The corollary to this
  152. assumption is that we should design so that increased blocking of our
  153. system results in increased economic damage or public outcry.
  154. We assume that the user will be able to fetch a genuine
  155. version of Tor, rather than one supplied by the adversary; see
  156. Section~\ref{subsec:trust-chain} for discussion on helping the user
  157. confirm that he has a genuine version and that he can connect to the
  158. real Tor network.
  159. \section{Components of the current Tor design}
  160. \label{sec:current-tor}
  161. Tor is popular and sees a lot of use. It's the largest anonymity
  162. network of its kind.
  163. Tor has attracted more than 800 volunteer-operated routers from around the
  164. world. Tor protects users by routing their traffic through a multiply
  165. encrypted ``circuit'' built of a few randomly selected servers, each of which
  166. can remove only a single layer of encryption. Each server sees only the step
  167. before it and the step after it in the circuit, and so no single server can
  168. learn the connection between a user and her chosen communication partners.
  169. In this section, we examine some of the reasons why Tor has become popular,
  170. with particular emphasis to how we can take advantage of these properties
  171. for a blocking-resistance design.
  172. Tor aims to provide three security properties:
  173. \begin{tightlist}
  174. \item 1. A local network attacker can't learn, or influence, your
  175. destination.
  176. \item 2. No single router in the Tor network can link you to your
  177. destination.
  178. \item 3. The destination, or somebody watching the destination,
  179. can't learn your location.
  180. \end{tightlist}
  181. For blocking-resistance, we care most clearly about the first
  182. property. But as the arms race progresses, the second property
  183. will become important---for example, to discourage an adversary
  184. from volunteering a relay in order to learn that Alice is reading
  185. or posting to certain websites. The third property helps keep users safe from
  186. collaborating websites: consider websites and other Internet services
  187. that have been pressured
  188. recently into revealing the identity of bloggers~\cite{arrested-bloggers}
  189. or treating clients differently depending on their network
  190. location~\cite{google-geolocation}.
  191. % and cite{goodell-syverson06} once it's finalized.
  192. The Tor design provides other features as well that are not typically
  193. present in manual or ad hoc circumvention techniques.
  194. First, the Tor directory authorities automatically aggregate, test,
  195. and publish signed summaries of the available Tor routers. Tor clients
  196. can fetch these summaries to learn which routers are available and
  197. which routers are suitable for their needs. Directory information is cached
  198. throughout the Tor network, so once clients have bootstrapped they never
  199. need to interact with the authorities directly. (To tolerate a minority
  200. of compromised directory authorities, we use a threshold trust scheme---
  201. see Section~\ref{subsec:trust-chain} for details.)
  202. Second, Tor clients can be configured to use any directory authorities
  203. they want. They use the default authorities if no others are specified,
  204. but it's easy to start a separate (or even overlapping) Tor network just
  205. by running a different set of authorities and convincing users to prefer
  206. a modified client. For example, we could launch a distinct Tor network
  207. inside China; some users could even use an aggregate network made up of
  208. both the main network and the China network. (But we should not be too
  209. quick to create other Tor networks---part of Tor's anonymity comes from
  210. users behaving like other users, and there are many unsolved anonymity
  211. questions if different users know about different pieces of the network.)
  212. Third, in addition to automatically learning from the chosen directories
  213. which Tor routers are available and working, Tor takes care of building
  214. paths through the network and rebuilding them as needed. So the user
  215. never has to know how paths are chosen, never has to manually pick
  216. working proxies, and so on. More generally, at its core the Tor protocol
  217. is simply a tool that can build paths given a set of routers. Tor is
  218. quite flexible about how it learns about the routers and how it chooses
  219. the paths. Harvard's Blossom project~\cite{blossom-thesis} makes this
  220. flexibility more concrete: Blossom makes use of Tor not for its security
  221. properties but for its reachability properties. It runs a separate set
  222. of directory authorities, its own set of Tor routers (called the Blossom
  223. network), and uses Tor's flexible path-building to let users view Internet
  224. resources from any point in the Blossom network.
  225. Fourth, Tor separates the role of \emph{internal relay} from the
  226. role of \emph{exit relay}. That is, some volunteers choose just to relay
  227. traffic between Tor users and Tor routers, and others choose to also allow
  228. connections to external Internet resources. Because we don't force all
  229. volunteers to play both roles, we end up with more relays. This increased
  230. diversity in turn is what gives Tor its security: the more options the
  231. user has for her first hop, and the more options she has for her last hop,
  232. the less likely it is that a given attacker will be watching both ends
  233. of her circuit~\cite{tor-design}. As a bonus, because our design attracts
  234. more internal relays that want to help out but don't want to deal with
  235. being an exit relay, we end up with more options for the first hop---the
  236. one most critical to being able to reach the Tor network.
  237. Fifth, Tor is sustainable. Zero-Knowledge Systems offered the commercial
  238. but now defunct Freedom Network~\cite{freedom21-security}, a design with
  239. security comparable to Tor's, but its funding model relied on collecting
  240. money from users to pay relay operators. Modern commercial proxy systems
  241. similarly
  242. need to keep collecting money to support their infrastructure. On the
  243. other hand, Tor has built a self-sustaining community of volunteers who
  244. donate their time and resources. This community trust is rooted in Tor's
  245. open design: we tell the world exactly how Tor works, and we provide all
  246. the source code. Users can decide for themselves, or pay any security
  247. expert to decide, whether it is safe to use. Further, Tor's modularity
  248. as described above, along with its open license, mean that its impact
  249. will continue to grow.
  250. Sixth, Tor has an established user base of hundreds of
  251. thousands of people from around the world. This diversity of
  252. users contributes to sustainability as above: Tor is used by
  253. ordinary citizens, activists, corporations, law enforcement, and
  254. even government and military users~\cite{tor-use-cases}, and they can
  255. only achieve their security goals by blending together in the same
  256. network~\cite{econymics,usability:weis2006}. This user base also provides
  257. something else: hundreds of thousands of different and often-changing
  258. addresses that we can leverage for our blocking-resistance design.
  259. We discuss and adapt these components further in
  260. Section~\ref{sec:bridges}. But first we examine the strengths and
  261. weaknesses of other blocking-resistance approaches, so we can expand
  262. our repertoire of building blocks and ideas.
  263. \section{Current proxy solutions}
  264. \label{sec:related}
  265. Relay-based blocking-resistance schemes generally have two main
  266. components: a relay component and a discovery component. The relay part
  267. encompasses the process of establishing a connection, sending traffic
  268. back and forth, and so on---everything that's done once the user knows
  269. where she's going to connect. Discovery is the step before that: the
  270. process of finding one or more usable relays.
  271. For example, we can divide the pieces of Tor in the previous section
  272. into the process of building paths and sending
  273. traffic over them (relay) and the process of learning from the directory
  274. servers about what routers are available (discovery). With this distinction
  275. in mind, we now examine several categories of relay-based schemes.
  276. \subsection{Centrally-controlled shared proxies}
  277. Existing commercial anonymity solutions (like Anonymizer.com) are based
  278. on a set of single-hop proxies. In these systems, each user connects to
  279. a single proxy, which then relays traffic between the user and her
  280. destination. These public proxy
  281. systems are typically characterized by two features: they control and
  282. operate the proxies centrally, and many different users get assigned
  283. to each proxy.
  284. In terms of the relay component, single proxies provide weak security
  285. compared to systems that distribute trust over multiple relays, since a
  286. compromised proxy can trivially observe all of its users' actions, and
  287. an eavesdropper only needs to watch a single proxy to perform timing
  288. correlation attacks against all its users' traffic and thus learn where
  289. everyone is connecting. Worse, all users
  290. need to trust the proxy company to have good security itself as well as
  291. to not reveal user activities.
  292. On the other hand, single-hop proxies are easier to deploy, and they
  293. can provide better performance than distributed-trust designs like Tor,
  294. since traffic only goes through one relay. They're also more convenient
  295. from the user's perspective---since users entirely trust the proxy,
  296. they can just use their web browser directly.
  297. Whether public proxy schemes are more or less scalable than Tor is
  298. still up for debate: commercial anonymity systems can use some of their
  299. revenue to provision more bandwidth as they grow, whereas volunteer-based
  300. anonymity systems can attract thousands of fast relays to spread the load.
  301. The discovery piece can take several forms. Most commercial anonymous
  302. proxies have one or a handful of commonly known websites, and their users
  303. log in to those websites and relay their traffic through them. When
  304. these websites get blocked (generally soon after the company becomes
  305. popular), if the company cares about users in the blocked areas, they
  306. start renting lots of disparate IP addresses and rotating through them
  307. as they get blocked. They notify their users of new addresses (by email,
  308. for example). It's an arms race, since attackers can sign up to receive the
  309. email too, but operators have one nice trick available to them: because they
  310. have a list of paying subscribers, they can notify certain subscribers
  311. about updates earlier than others.
  312. Access control systems on the proxy let them provide service only to
  313. users with certain characteristics, such as paying customers or people
  314. from certain IP address ranges.
  315. Discovery in the face of a government-level firewall is a complex and
  316. unsolved
  317. topic, and we're stuck in this same arms race ourselves; we explore it
  318. in more detail in Section~\ref{sec:discovery}. But first we examine the
  319. other end of the spectrum---getting volunteers to run the proxies,
  320. and telling only a few people about each proxy.
  321. \subsection{Independent personal proxies}
  322. Personal proxies such as Circumventor~\cite{circumventor} and
  323. CGIProxy~\cite{cgiproxy} use the same technology as the public ones as
  324. far as the relay component goes, but they use a different strategy for
  325. discovery. Rather than managing a few centralized proxies and constantly
  326. getting new addresses for them as the old addresses are blocked, they
  327. aim to have a large number of entirely independent proxies, each managing
  328. its own (much smaller) set of users.
  329. As the Circumventor site explains, ``You don't
  330. actually install the Circumventor \emph{on} the computer that is blocked
  331. from accessing Web sites. You, or a friend of yours, has to install the
  332. Circumventor on some \emph{other} machine which is not censored.''
  333. This tactic has great advantages in terms of blocking-resistance---recall
  334. our assumption in Section~\ref{sec:adversary} that the attention
  335. a system attracts from the attacker is proportional to its number of
  336. users and level of publicity. If each proxy only has a few users, and
  337. there is no central list of proxies, most of them will never get noticed by
  338. the censors.
  339. On the other hand, there's a huge scalability question that so far has
  340. prevented these schemes from being widely useful: how does the fellow
  341. in China find a person in Ohio who will run a Circumventor for him? In
  342. some cases he may know and trust some people on the outside, but in many
  343. cases he's just out of luck. Just as hard, how does a new volunteer in
  344. Ohio find a person in China who needs it?
  345. % another key feature of a proxy run by your uncle is that you
  346. % self-censor, so you're unlikely to bring abuse complaints onto
  347. % your uncle. self-censoring clearly has a downside too, though.
  348. This challenge leads to a hybrid design---centrally-distributed
  349. personal proxies---which we will investigate in more detail in
  350. Section~\ref{sec:discovery}.
  351. \subsection{Open proxies}
  352. Yet another currently used approach to bypassing firewalls is to locate
  353. open and misconfigured proxies on the Internet. A quick Google search
  354. for ``open proxy list'' yields a wide variety of freely available lists
  355. of HTTP, HTTPS, and SOCKS proxies. Many small companies have sprung up
  356. providing more refined lists to paying customers.
  357. There are some downsides to using these open proxies though. First,
  358. the proxies are of widely varying quality in terms of bandwidth and
  359. stability, and many of them are entirely unreachable. Second, unlike
  360. networks of volunteers like Tor, the legality of routing traffic through
  361. these proxies is questionable: it's widely believed that most of them
  362. don't realize what they're offering, and probably wouldn't allow it if
  363. they realized. Third, in many cases the connection to the proxy is
  364. unencrypted, so firewalls that filter based on keywords in IP packets
  365. will not be hindered. And last, many users are suspicious that some
  366. open proxies are a little \emph{too} convenient: are they run by the
  367. adversary, in which case they get to monitor all the user's requests
  368. just as single-hop proxies can?
  369. A distributed-trust design like Tor resolves each of these issues for
  370. the relay component, but a constantly changing set of thousands of open
  371. relays is clearly a useful idea for a discovery component. For example,
  372. users might be able to make use of these proxies to bootstrap their
  373. first introduction into the Tor network.
  374. \subsection{Blocking resistance and JAP}
  375. K\"{o}psell's Blocking Resistance design~\cite{koepsell:wpes2004} is probably
  376. the closest related work, and is the starting point for the design in this
  377. paper. In this design, the JAP anonymity system is used as a base instead of
  378. Tor. Volunteers operate a large number of access points to the core JAP
  379. network, which in turn anonymizes users' traffic. The software to run these
  380. relays is, as in our design, included in the JAP client software and enabled
  381. only when the user decides to enable it. Discovery is handled with a
  382. CAPTCHA-based mechanism; users prove that they aren't an automated process,
  383. and are given the address of an access point. (The problem of a determined
  384. attacker with enough manpower to launch many requests and enumerate all the
  385. access points is not considered in depth.) There is also some suggestion
  386. that information about access points could spread through existing social
  387. networks.
  388. \subsection{Infranet}
  389. The Infranet design~\cite{infranet} uses one-hop relays to deliver web
  390. content, but disguises its communications as ordinary HTTP traffic. Requests
  391. are split into multiple requests for URLs on the relay, which then encodes
  392. its responses in the content it returns. The relay needs to be an actual
  393. website with plausible content and a number of URLs which the user might want
  394. to access---if the Infranet software produced its own cover content, it would
  395. be far easier for censors to identify. To keep the censors from noticing
  396. that cover content changes depending on what data is embedded, Infranet needs
  397. the cover content to have an innocuous reason for changing frequently: the
  398. paper recommends watermarked images and webcams.
  399. The attacker and relay operators in Infranet's threat model are significantly
  400. different than in ours. Unlike our attacker, Infranet's censor can't be
  401. bypassed with encrypted traffic (presumably because the censor blocks
  402. encrypted traffic, or at least considers it suspicious), and has more
  403. computational resources to devote to each connection than ours (so it can
  404. notice subtle patterns over time). Unlike our bridge operators, Infranet's
  405. operators (and users) have more bandwidth to spare; the overhead in typical
  406. steganography schemes is far higher than Tor's.
  407. The Infranet design does not include a discovery element. Discovery,
  408. however, is a critical point: if whatever mechanism allows users to learn
  409. about relays also allows the censor to do so, he can trivially discover and
  410. block their addresses, even if the steganography would prevent mere traffic
  411. observation from revealing the relays' addresses.
  412. \subsection{RST-evasion}
  413. In their analysis of China's firewall's content-based blocking, Clayton,
  414. Murdoch and Watson discovered that rather than blocking all packets in a TCP
  415. streams once a forbidden word was noticed, the firewall was simply forging
  416. RST packets to make the communicating parties believe that the connection was
  417. closed~\cite{clayton:pet2006}. Two mechanisms were proposed: altering
  418. operating systems to ignore forged RST packets, and ensuring that sensitive
  419. words are split across multiple TCP packets so that the censors' firewalls
  420. can't notice them without performing expensive stream reconstruction. The
  421. later technique relies on the same insight as our weak steganography
  422. assumption.
  423. \subsection{Internal caching networks}
  424. Freenet~\cite{freenet-pets00} is an anonymous peer-to-peer data store.
  425. Analyzing Freenet's security can be difficult, as its design is in flux as
  426. new discovery and routing mechanisms are proposed, and no complete
  427. specification has (to our knowledge) been written. Freenet servers relay
  428. requests for specific content (indexed by a digest of the content) to the
  429. server that hosts it, and then caches the content as it works its way back to
  430. the requesting user. If Freenet's routing mechanism is successful in
  431. allowing nodes to learn about each other and route correctly even as some
  432. node-to-node links are blocked by firewalls, then users inside censored areas
  433. can ask a local Freenet server for a piece of content, and get an answer
  434. without having to connect out of the country at all. Of course, operators of
  435. servers inside the censored area can still be targeted, and the addresses of
  436. external serves can still be blocked.
  437. \subsection{Skype}
  438. The popular Skype voice-over-IP software uses multiple techniques to tolerate
  439. restrictive networks, some of which allow it to continue operating in the
  440. presence of censorship. By switching ports and using encryption, Skype
  441. attempts to resist trivial blocking and content filtering. Even if no
  442. encryption were used, it would still be quite expensive to scan all voice
  443. traffic for sensitive words. Also, most current keyloggers are unable to
  444. store voice traffic. Nevertheless, Skype can still be blocked, especially at
  445. it central directory service.
  446. \subsection{Tor itself}
  447. And last, we include Tor itself in the list of current solutions
  448. to firewalls. Tens of thousands of people use Tor from countries that
  449. routinely filter their Internet. Tor's website has been blocked in most
  450. of them. But why hasn't the Tor network been blocked yet?
  451. We have several theories. The first is the most straightforward: tens of
  452. thousands of people are simply too few to matter. It may help that Tor is
  453. perceived to be for experts only, and thus not worth attention yet. The
  454. more subtle variant on this theory is that we've positioned Tor in the
  455. public eye as a tool for retaining civil liberties in more free countries,
  456. so perhaps blocking authorities don't view it as a threat. (We revisit
  457. this idea when we consider whether and how to publicize a Tor variant
  458. that improves blocking-resistance---see Section~\ref{subsec:publicity}
  459. for more discussion.)
  460. The broader explanation is that the maintainance of most government-level
  461. filters is aimed at stopping widespread information flow and appearing to be
  462. in control, not by the impossible goal of blocking all possible ways to bypass
  463. censorship. Censors realize that there will always
  464. be ways for a few people to get around the firewall, and as long as Tor
  465. has not publically threatened their control, they see no urgent need to
  466. block it yet.
  467. We should recognize that we're \emph{already} in the arms race. These
  468. constraints can give us insight into the priorities and capabilities of
  469. our various attackers.
  470. \section{The relay component of our blocking-resistant design}
  471. \label{sec:bridges}
  472. Section~\ref{sec:current-tor} describes many reasons why Tor is
  473. well-suited as a building block in our context, but several changes will
  474. allow the design to resist blocking better. The most critical changes are
  475. to get more relay addresses, and to distribute them to users differently.
  476. %We need to address three problems:
  477. %- adapting the relay component of Tor so it resists blocking better.
  478. %- Discovery.
  479. %- Tor's network signature.
  480. %Here we describe the new pieces we need to add to the current Tor design.
  481. \subsection{Bridge relays}
  482. Today, Tor servers operate on less than a thousand distinct IP addresses;
  483. an adversary
  484. could enumerate and block them all with little trouble. To provide a
  485. means of ingress to the network, we need a larger set of entry points, most
  486. of which an adversary won't be able to enumerate easily. Fortunately, we
  487. have such a set: the Tor users.
  488. Hundreds of thousands of people around the world use Tor. We can leverage
  489. our already self-selected user base to produce a list of thousands of
  490. often-changing IP addresses. Specifically, we can give them a little
  491. button in the GUI that says ``Tor for Freedom'', and users who click
  492. the button will turn into \emph{bridge relays} (or just \emph{bridges}
  493. for short). They can rate limit relayed connections to 10 KB/s (almost
  494. nothing for a broadband user in a free country, but plenty for a user
  495. who otherwise has no access at all), and since they are just relaying
  496. bytes back and forth between blocked users and the main Tor network, they
  497. won't need to make any external connections to Internet sites. Because
  498. of this separation of roles, and because we're making use of software
  499. that the volunteers have already installed for their own use, we expect
  500. our scheme to attract and maintain more volunteers than previous schemes.
  501. As usual, there are new anonymity and security implications from running a
  502. bridge relay, particularly from letting people relay traffic through your
  503. Tor client; but we leave this discussion for Section~\ref{sec:security}.
  504. %...need to outline instructions for a Tor config that will publish
  505. %to an alternate directory authority, and for controller commands
  506. %that will do this cleanly.
  507. \subsection{The bridge directory authority}
  508. How do the bridge relays advertise their existence to the world? We
  509. introduce a second new component of the design: a specialized directory
  510. authority that aggregates and tracks bridges. Bridge relays periodically
  511. publish server descriptors (summaries of their keys, locations, etc,
  512. signed by their long-term identity key), just like the relays in the
  513. ``main'' Tor network, but in this case they publish them only to the
  514. bridge directory authorities.
  515. The main difference between bridge authorities and the directory
  516. authorities for the main Tor network is that the main authorities provide
  517. a list of every known relay, but the bridge authorities only give
  518. out a server descriptor if you already know its identity key. That is,
  519. you can keep up-to-date on a bridge's location and other information
  520. once you know about it, but you can't just grab a list of all the bridges.
  521. The identity key, IP address, and directory port for each bridge
  522. authority ship by default with the Tor software, so the bridge relays
  523. can be confident they're publishing to the right location, and the
  524. blocked users can establish an encrypted authenticated channel. See
  525. Section~\ref{subsec:trust-chain} for more discussion of the public key
  526. infrastructure and trust chain.
  527. Bridges use Tor to publish their descriptors privately and securely,
  528. so even an attacker monitoring the bridge directory authority's network
  529. can't make a list of all the addresses contacting the authority.
  530. Bridges may publish to only a subset of the
  531. authorities, to limit the potential impact of an authority compromise.
  532. %\subsection{A simple matter of engineering}
  533. %
  534. %Although we've described bridges and bridge authorities in simple terms
  535. %above, some design modifications and features are needed in the Tor
  536. %codebase to add them. We describe the four main changes here.
  537. %
  538. %Firstly, we need to get smarter about rate limiting:
  539. %Bandwidth classes
  540. %
  541. %Secondly, while users can in fact configure which directory authorities
  542. %they use, we need to add a new type of directory authority and teach
  543. %bridges to fetch directory information from the main authorities while
  544. %publishing server descriptors to the bridge authorities. We're most of
  545. %the way there, since we can already specify attributes for directory
  546. %authorities:
  547. %add a separate flag named ``blocking''.
  548. %
  549. %Thirdly, need to build paths using bridges as the first
  550. %hop. One more hole in the non-clique assumption.
  551. %
  552. %Lastly, since bridge authorities don't answer full network statuses,
  553. %we need to add a new way for users to learn the current status for a
  554. %single relay or a small set of relays---to answer such questions as
  555. %``is it running?'' or ``is it behaving correctly?'' We describe in
  556. %Section~\ref{subsec:enclave-dirs} a way for the bridge authority to
  557. %publish this information without resorting to signing each answer
  558. %individually.
  559. \subsection{Putting them together}
  560. \label{subsec:relay-together}
  561. If a blocked user knows the identity keys of a set of bridge relays, and
  562. he has correct address information for at least one of them, he can use
  563. that one to make a secure connection to the bridge authority and update
  564. his knowledge about the other bridge relays. He can also use it to make
  565. secure connections to the main Tor network and directory servers, so he
  566. can build circuits and connect to the rest of the Internet. All of these
  567. updates happen in the background: from the blocked user's perspective,
  568. he just accesses the Internet via his Tor client like always.
  569. So now we've reduced the problem from how to circumvent the firewall
  570. for all transactions (and how to know that the pages you get have not
  571. been modified by the local attacker) to how to learn about a working
  572. bridge relay.
  573. There's another catch though. We need to make sure that the network
  574. traffic we generate by simply connecting to a bridge relay doesn't stand
  575. out too much.
  576. %The following section describes ways to bootstrap knowledge of your first
  577. %bridge relay, and ways to maintain connectivity once you know a few
  578. %bridge relays.
  579. % (See Section~\ref{subsec:first-bridge} for a discussion
  580. %of exactly what information is sufficient to characterize a bridge relay.)
  581. \section{Hiding Tor's network signatures}
  582. \label{sec:network-signature}
  583. \label{subsec:enclave-dirs}
  584. Currently, Tor uses two protocols for its network communications. The
  585. main protocol uses TLS for encrypted and authenticated communication
  586. between Tor instances. The second protocol is standard HTTP, used for
  587. fetching directory information. All Tor servers listen on their ``ORPort''
  588. for TLS connections, and some of them opt to listen on their ``DirPort''
  589. as well, to serve directory information. Tor servers choose whatever port
  590. numbers they like; the server descriptor they publish to the directory
  591. tells users where to connect.
  592. One format for communicating address information about a bridge relay is
  593. its IP address and DirPort. From there, the user can ask the bridge's
  594. directory cache for an up-to-date copy of its server descriptor, and
  595. learn its current circuit keys, its ORPort, and so on.
  596. However, connecting directly to the directory cache involves a plaintext
  597. HTTP request. A censor could create a network signature for the request
  598. and/or its response, thus preventing these connections. To resolve this
  599. vulnerability, we've modified the Tor protocol so that users can connect
  600. to the directory cache via the main Tor port---they establish a TLS
  601. connection with the bridge as normal, and then send a special ``begindir''
  602. relay command to establish an internal connection to its directory cache.
  603. Therefore a better way to summarize a bridge's address is by its IP
  604. address and ORPort, so all communications between the client and the
  605. bridge will use ordinary TLS. But there are other details that need
  606. more investigation.
  607. What port should bridges pick for their ORPort? We currently recommend
  608. that they listen on port 443 (the default HTTPS port) if they want to
  609. be most useful, because clients behind standard firewalls will have
  610. the best chance to reach them. Is this the best choice in all cases,
  611. or should we encourage some fraction of them pick random ports, or other
  612. ports commonly permitted through firewalls like 53 (DNS) or 110
  613. (POP)? Or perhaps we should use other ports where TLS traffic is
  614. expected, like 993 (IMAPS) or 995 (POP3S). We need more research on our
  615. potential users, and their current and anticipated firewall restrictions.
  616. Furthermore, we need to look at the specifics of Tor's TLS handshake.
  617. Right now Tor uses some predictable strings in its TLS handshakes. For
  618. example, it sets the X.509 organizationName field to ``Tor'', and it puts
  619. the Tor server's nickname in the certificate's commonName field. We
  620. should tweak the handshake protocol so it doesn't rely on any unusual details
  621. in the certificate, yet it remains secure; the certificate itself
  622. should be made to resemble an ordinary HTTPS certificate. We should also try
  623. to make our advertised cipher-suites closer to what an ordinary web server
  624. would support.
  625. Tor's TLS handshake uses two-certificate chains: one certificate
  626. contains the self-signed identity key for
  627. the router, and the second contains a current TLS key, signed by the
  628. identity key. We use these to authenticate that we're talking to the right
  629. router, and to limit the impact of TLS-key exposure. Most (though far from
  630. all) consumer-oriented HTTPS services provide only a single certificate.
  631. These extra certificates may help identify Tor's TLS handshake; instead,
  632. bridges should consider using only a single TLS key certificate signed by
  633. their identity key, and providing the full value of the identity key in an
  634. early handshake cell. More significantly, Tor currently has all clients
  635. present certificates, so that clients are harder to distinguish from servers.
  636. But in a blocking-resistance environment, clients should not present
  637. certificates at all.
  638. Last, what if the adversary starts observing the network traffic even
  639. more closely? Even if our TLS handshake looks innocent, our traffic timing
  640. and volume still look different than a user making a secure web connection
  641. to his bank. The same techniques used in the growing trend to build tools
  642. to recognize encrypted Bittorrent traffic
  643. %~\cite{bt-traffic-shaping}
  644. could be used to identify Tor communication and recognize bridge
  645. relays. Rather than trying to look like encrypted web traffic, we may be
  646. better off trying to blend with some other encrypted network protocol. The
  647. first step is to compare typical network behavior for a Tor client to
  648. typical network behavior for various other protocols. This statistical
  649. cat-and-mouse game is made more complex by the fact that Tor transports a
  650. variety of protocols, and we'll want to automatically handle web browsing
  651. differently from, say, instant messaging.
  652. % Tor cells are 512 bytes each. So TLS records will be roughly
  653. % multiples of this size? How bad is this? -RD
  654. % Look at ``Inferring the Source of Encrypted HTTP Connections''
  655. % by Marc Liberatore and Brian Neil Levine (CCS 2006)
  656. % They substantially flesh out the numbers for the web fingerprinting
  657. % attack. -PS
  658. % Yes, but I meant detecting the signature of Tor traffic itself, not
  659. % learning what websites we're going to. I wouldn't be surprised to
  660. % learn that these are related problems, but it's not obvious to me. -RD
  661. \subsection{Identity keys as part of addressing information}
  662. We have described a way for the blocked user to bootstrap into the
  663. network once he knows the IP address and ORPort of a bridge. What about
  664. local spoofing attacks? That is, since we never learned an identity
  665. key fingerprint for the bridge, a local attacker could intercept our
  666. connection and pretend to be the bridge we had in mind. It turns out
  667. that giving false information isn't that bad---since the Tor client
  668. ships with trusted keys for the bridge directory authority and the Tor
  669. network directory authorities, the user can learn whether he's being
  670. given a real connection to the bridge authorities or not. (After all,
  671. if the adversary intercepts every connection the user makes and gives
  672. him a bad connection each time, there's nothing we can do.)
  673. What about anonymity-breaking attacks from observing traffic, if the
  674. blocked user doesn't start out knowing the identity key of his intended
  675. bridge? The vulnerabilities aren't so bad in this case either---the
  676. adversary could do similar attacks just by monitoring the network
  677. traffic.
  678. % cue paper by steven and george
  679. Once the Tor client has fetched the bridge's server descriptor, it should
  680. remember the identity key fingerprint for that bridge relay. Thus if
  681. the bridge relay moves to a new IP address, the client can query the
  682. bridge directory authority to look up a fresh server descriptor using
  683. this fingerprint.
  684. So we've shown that it's \emph{possible} to bootstrap into the network
  685. just by learning the IP address and ORPort of a bridge, but are there
  686. situations where it's more convenient or more secure to learn the bridge's
  687. identity fingerprint as well as instead, while bootstrapping? We keep
  688. that question in mind as we next investigate bootstrapping and discovery.
  689. \section{Discovering working bridge relays}
  690. \label{sec:discovery}
  691. Tor's modular design means that we can develop a better relay component
  692. independently of developing the discovery component. This modularity's
  693. great promise is that we can pick any discovery approach we like; but the
  694. unfortunate fact is that we have no magic bullet for discovery. We're
  695. in the same arms race as all the other designs we described in
  696. Section~\ref{sec:related}.
  697. In this section we describe a variety of approaches to adding discovery
  698. components for our design.
  699. \subsection{Bootstrapping: finding your first bridge.}
  700. \label{subsec:first-bridge}
  701. In Section~\ref{subsec:relay-together}, we showed that a user who knows
  702. a working bridge address can use it to reach the bridge authority and
  703. to stay connected to the Tor network. But how do new users reach the
  704. bridge authority in the first place? After all, the bridge authority
  705. will be one of the first addresses that a censor blocks.
  706. First, we should recognize that most government firewalls are not
  707. perfect. That is, they may allow connections to Google cache or some
  708. open proxy servers, or they let file-sharing traffic, Skype, instant
  709. messaging, or World-of-Warcraft connections through. Different users will
  710. have different mechanisms for bypassing the firewall initially. Second,
  711. we should remember that most people don't operate in a vacuum; users will
  712. hopefully know other people who are in other situations or have other
  713. resources available. In the rest of this section we develop a toolkit
  714. of different options and mechanisms, so that we can enable users in a
  715. diverse set of contexts to bootstrap into the system.
  716. (For users who can't use any of these techniques, hopefully they know
  717. a friend who can---for example, perhaps the friend already knows some
  718. bridge relay addresses. If they can't get around it at all, then we
  719. can't help them---they should go meet more people or learn more about
  720. the technology running the firewall in their area.)
  721. By deploying all the schemes in the toolkit at once, we let bridges and
  722. blocked users employ the discovery approach that is most appropriate
  723. for their situation.
  724. \subsection{Independent bridges, no central discovery}
  725. The first design is simply to have no centralized discovery component at
  726. all. Volunteers run bridges, and we assume they have some blocked users
  727. in mind and communicate their address information to them out-of-band
  728. (for example, through Gmail). This design allows for small personal
  729. bridges that have only one or a handful of users in mind, but it can
  730. also support an entire community of users. For example, Citizen Lab's
  731. upcoming Psiphon single-hop proxy tool~\cite{psiphon} plans to use this
  732. \emph{social network} approach as its discovery component.
  733. There are several ways to do bootstrapping in this design. In the simple
  734. case, the operator of the bridge informs each chosen user about his
  735. bridge's address information and/or keys. A different approach involves
  736. blocked users introducing new blocked users to the bridges they know.
  737. That is, somebody in the blocked area can pass along a bridge's address to
  738. somebody else they trust. This scheme brings in appealing but complex game
  739. theoretic properties: the blocked user making the decision has an incentive
  740. only to delegate to trustworthy people, since an adversary who learns
  741. the bridge's address and filters it makes it unavailable for both of them.
  742. Also, delegating known bridges to members of your social network can be
  743. dangerous: an the adversary who can learn who knows which bridges may
  744. be able to reconstruct the social network.
  745. Note that a central set of bridge directory authorities can still be
  746. compatible with a decentralized discovery process. That is, how users
  747. first learn about bridges is entirely up to the bridges, but the process
  748. of fetching up-to-date descriptors for them can still proceed as described
  749. in Section~\ref{sec:bridges}. Of course, creating a central place that
  750. knows about all the bridges may not be smart, especially if every other
  751. piece of the system is decentralized. Further, if a user only knows
  752. about one bridge and he loses track of it, it may be quite a hassle to
  753. reach the bridge authority. We address these concerns next.
  754. \subsection{Families of bridges, no central discovery}
  755. Because the blocked users are running our software too, we have many
  756. opportunities to improve usability or robustness. Our second design builds
  757. on the first by encouraging volunteers to run several bridges at once
  758. (or coordinate with other bridge volunteers), such that some
  759. of the bridges are likely to be available at any given time.
  760. The blocked user's Tor client would periodically fetch an updated set of
  761. recommended bridges from any of the working bridges. Now the client can
  762. learn new additions to the bridge pool, and can expire abandoned bridges
  763. or bridges that the adversary has blocked, without the user ever needing
  764. to care. To simplify maintenance of the community's bridge pool, each
  765. community could run its own bridge directory authority---reachable via
  766. the available bridges, and also mirrored at each bridge.
  767. \subsection{Public bridges with central discovery}
  768. What about people who want to volunteer as bridges but don't know any
  769. suitable blocked users? What about people who are blocked but don't
  770. know anybody on the outside? Here we describe how to make use of these
  771. \emph{public bridges} in a way that still makes it hard for the attacker
  772. to learn all of them.
  773. The basic idea is to divide public bridges into a set of pools based on
  774. identity key. Each pool corresponds to a \emph{distribution strategy}:
  775. an approach to distributing its bridge addresses to users. Each strategy
  776. is designed to exercise a different scarce resource or property of
  777. the user.
  778. How do we divide bridges between these strategy pools such that they're
  779. evenly distributed and the allocation is hard to influence or predict,
  780. but also in a way that's amenable to creating more strategies later
  781. on without reshuffling all the pools? We assign a given bridge
  782. to a strategy pool by hashing the bridge's identity key along with a
  783. secret that only the bridge authority knows: the first $n$ bits of this
  784. hash dictate the strategy pool number, where $n$ is a parameter that
  785. describes how many strategy pools we want at this point. We choose $n=3$
  786. to start, so we divide bridges between 8 pools; but as we later invent
  787. new distribution strategies, we can increment $n$ to split the 8 into
  788. 16. Since a bridge can't predict the next bit in its hash, it can't
  789. anticipate which identity key will correspond to a certain new pool
  790. when the pools are split. Further, since the bridge authority doesn't
  791. provide any feedback to the bridge about which strategy pool it's in,
  792. an adversary who signs up bridges with the goal of filling a certain
  793. pool~\cite{casc-rep} will be hindered.
  794. % This algorithm is not ideal. When we split pools, each existing
  795. % pool is cut in half, where half the bridges remain with the
  796. % old distribution policy, and half will be under what the new one
  797. % is. So the new distribution policy inherits a bunch of blocked
  798. % bridges if the old policy was too loose, or a bunch of unblocked
  799. % bridges if its policy was still secure. -RD
  800. %
  801. % I think it should be more chordlike.
  802. % Bridges are allocated to wherever on the ring which is divided
  803. % into arcs (buckets).
  804. % If a bucket gets too full, you can just split it.
  805. % More on this below. -PFS
  806. The first distribution strategy (used for the first pool) publishes bridge
  807. addresses in a time-release fashion. The bridge authority divides the
  808. available bridges into partitions, and each partition is deterministically
  809. available only in certain time windows. That is, over the course of a
  810. given time slot (say, an hour), each requestor is given a random bridge
  811. from within that partition. When the next time slot arrives, a new set
  812. of bridges from the pool are available for discovery. Thus some bridge
  813. address is always available when a new
  814. user arrives, but to learn about all bridges the attacker needs to fetch
  815. all new addresses at every new time slot. By varying the length of the
  816. time slots, we can make it harder for the attacker to guess when to check
  817. back. We expect these bridges will be the first to be blocked, but they'll
  818. help the system bootstrap until they \emph{do} get blocked. Further,
  819. remember that we're dealing with different blocking regimes around the
  820. world that will progress at different rates---so this pool will still
  821. be useful to some users even as the arms races progress.
  822. The second distribution strategy publishes bridge addresses based on the IP
  823. address of the requesting user. Specifically, the bridge authority will
  824. divide the available bridges in the pool into a bunch of partitions
  825. (as in the first distribution scheme), hash the requestor's IP address
  826. with a secret of its own (as in the above allocation scheme for creating
  827. pools), and give the requestor a random bridge from the appropriate
  828. partition. To raise the bar, we should discard the last octet of the
  829. IP address before inputting it to the hash function, so an attacker
  830. who only controls a single ``/24'' network only counts as one user. A
  831. large attacker like China will still be able to control many addresses,
  832. but the hassle of establishing connections from each network (or spoofing
  833. TCP connections) may still slow them down. Similarly, as a special case,
  834. we should treat IP addresses that are Tor exit nodes as all being on
  835. the same network.
  836. The third strategy combines the time-based and location-based
  837. strategies to further constrain and rate-limit the available bridge
  838. addresses. Specifically, the bridge address provided in a given time
  839. slot to a given network location is deterministic within the partition,
  840. rather than chosen randomly each time from the partition. Thus, repeated
  841. requests during that time slot from a given network are given the same
  842. bridge address as the first request.
  843. The fourth strategy is based on Circumventor's discovery strategy.
  844. The Circumventor project, realizing that its adoption will remain limited
  845. if it has no central coordination mechanism, has started a mailing list to
  846. distribute new proxy addresses every few days. From experimentation it
  847. seems they have concluded that sending updates every three or four days
  848. is sufficient to stay ahead of the current attackers.
  849. The fifth strategy provides an alternative approach to a mailing list:
  850. users provide an email address and receive an automated response
  851. listing an available bridge address. We could limit one response per
  852. email address. To further rate limit queries, we could require a CAPTCHA
  853. solution
  854. %~\cite{captcha}
  855. in each case too. In fact, we wouldn't need to
  856. implement the CAPTCHA on our side: if we only deliver bridge addresses
  857. to Yahoo or GMail addresses, we can leverage the rate-limiting schemes
  858. that other parties already impose for account creation.
  859. The sixth strategy ties in the social network design with public
  860. bridges and a reputation system. We pick some seeds---trusted people in
  861. blocked areas---and give them each a few dozen bridge addresses and a few
  862. \emph{delegation tokens}. We run a website next to the bridge authority,
  863. where users can log in (they connect via Tor, and they don't need to
  864. provide actual identities, just persistent pseudonyms). Users can delegate
  865. trust to other people they know by giving them a token, which can be
  866. exchanged for a new account on the website. Accounts in ``good standing''
  867. then accrue new bridge addresses and new tokens. As usual, reputation
  868. schemes bring in a host of new complexities~\cite{rep-anon}: how do we
  869. decide that an account is in good standing? We could tie reputation
  870. to whether the bridges they're told about have been blocked---see
  871. Section~\ref{subsec:geoip} below for initial thoughts on how to discover
  872. whether bridges have been blocked. We could track reputation between
  873. accounts (if you delegate to somebody who screws up, it impacts you too),
  874. or we could use blinded delegation tokens~\cite{chaum-blind} to prevent
  875. the website from mapping the seeds' social network. We put off deeper
  876. discussion of the social network reputation strategy for future work.
  877. Pools seven and eight are held in reserve, in case our currently deployed
  878. tricks all fail at once and the adversary blocks all those bridges---so
  879. we can adapt and move to new approaches quickly, and have some bridges
  880. immediately available for the new schemes. New strategies might be based
  881. on some other scarce resource, such as relaying traffic for others or
  882. other proof of energy spent. (We might also worry about the incentives
  883. for bridges that sign up and get allocated to the reserve pools: will they
  884. be unhappy that they're not being used? But this is a transient problem:
  885. if Tor users are bridges by default, nobody will mind not being used yet.
  886. See also Section~\ref{subsec:incentives}.)
  887. %Is it useful to load balance which bridges are handed out? The above
  888. %pool concept makes some bridges wildly popular and others less so.
  889. %But I guess that's the point.
  890. \subsection{Public bridges with coordinated discovery}
  891. We presented the above discovery strategies in the context of a single
  892. bridge directory authority, but in practice we will want to distribute the
  893. operations over several bridge authorities---a single point of failure
  894. or attack is a bad move. The first answer is to run several independent
  895. bridge directory authorities, and bridges gravitate to one based on
  896. their identity key. The better answer would be some federation of bridge
  897. authorities that work together to provide redundancy but don't introduce
  898. new security issues. We could even imagine designs where the bridge
  899. authorities have encrypted versions of the bridge's server descriptors,
  900. and the users learn a decryption key that they keep private when they
  901. first hear about the bridge---this way the bridge authorities would not
  902. be able to learn the IP address of the bridges.
  903. We leave this design question for future work.
  904. \subsection{Assessing whether bridges are useful}
  905. Learning whether a bridge is useful is important in the bridge authority's
  906. decision to include it in responses to blocked users. For example, if
  907. we end up with a list of thousands of bridges and only a few dozen of
  908. them are reachable right now, most blocked users will not end up knowing
  909. about working bridges.
  910. There are three components for assessing how useful a bridge is. First,
  911. is it reachable from the public Internet? Second, what proportion of
  912. the time is it available? Third, is it blocked in certain jurisdictions?
  913. The first component can be tested just as we test reachability of
  914. ordinary Tor servers. Specifically, the bridges do a self-test---connect
  915. to themselves via the Tor network---before they are willing to
  916. publish their descriptor, to make sure they're not obviously broken or
  917. misconfigured. Once the bridges publish, the bridge authority also tests
  918. reachability to make sure they're not confused or outright lying.
  919. The second component can be measured and tracked by the bridge authority.
  920. By doing periodic reachability tests, we can get a sense of how often the
  921. bridge is available. More complex tests will involve bandwidth-intensive
  922. checks to force the bridge to commit resources in order to be counted as
  923. available. We need to evaluate how the relationship of uptime percentage
  924. should weigh into our choice of which bridges to advertise. We leave
  925. this to future work.
  926. The third component is perhaps the trickiest: with many different
  927. adversaries out there, how do we keep track of which adversaries have
  928. blocked which bridges, and how do we learn about new blocks as they
  929. occur? We examine this problem next.
  930. \subsection{How do we know if a bridge relay has been blocked?}
  931. \label{subsec:geoip}
  932. There are two main mechanisms for testing whether bridges are reachable
  933. from inside each blocked area: active testing via users, and passive
  934. testing via bridges.
  935. In the case of active testing, certain users inside each area
  936. sign up as testing relays. The bridge authorities can then use a
  937. Blossom-like~\cite{blossom-thesis} system to build circuits through them
  938. to each bridge and see if it can establish the connection. But how do
  939. we pick the users? If we ask random users to do the testing (or if we
  940. solicit volunteers from the users), the adversary should sign up so he
  941. can enumerate the bridges we test. Indeed, even if we hand-select our
  942. testers, the adversary might still discover their location and monitor
  943. their network activity to learn bridge addresses.
  944. Another answer is not to measure directly, but rather let the bridges
  945. report whether they're being used.
  946. %If they periodically report to their
  947. %bridge directory authority how much use they're seeing, perhaps the
  948. %authority can make smart decisions from there.
  949. Specifically, bridges should install a GeoIP database such as the public
  950. IP-To-Country list~\cite{ip-to-country}, and then periodically report to the
  951. bridge authorities which countries they're seeing use from. This data
  952. would help us track which countries are making use of the bridge design,
  953. and can also let us learn about new steps the adversary has taken in
  954. the arms race. (The compressed GeoIP database is only several hundred
  955. kilobytes, and we could even automate the update process by serving it
  956. from the bridge authorities.)
  957. More analysis of this passive reachability
  958. testing design is needed to resolve its many edge cases: for example,
  959. if a bridge stops seeing use from a certain area, does that mean the
  960. bridge is blocked or does that mean those users are asleep?
  961. There are many more problems with the general concept of detecting whether
  962. bridges are blocked. First, different zones of the Internet are blocked
  963. in different ways, and the actual firewall jurisdictions do not match
  964. country borders. Our bridge scheme could help us map out the topology
  965. of the censored Internet, but this is a huge task. More generally,
  966. if a bridge relay isn't reachable, is that because of a network block
  967. somewhere, because of a problem at the bridge relay, or just a temporary
  968. outage somewhere in between? And last, an attacker could poison our
  969. bridge database by signing up already-blocked bridges. In this case,
  970. if we're stingy giving out bridge addresses, users in that country won't
  971. learn working bridges.
  972. All of these issues are made more complex when we try to integrate this
  973. testing into our social network reputation system above.
  974. Since in that case we punish or reward users based on whether bridges
  975. get blocked, the adversary has new attacks to trick or bog down the
  976. reputation tracking. Indeed, the bridge authority doesn't even know
  977. what zone the blocked user is in, so do we blame him for any possible
  978. censored zone, or what?
  979. Clearly more analysis is required. The eventual solution will probably
  980. involve a combination of passive measurement via GeoIP and active
  981. measurement from trusted testers. More generally, we can use the passive
  982. feedback mechanism to track usage of the bridge network as a whole---which
  983. would let us respond to attacks and adapt the design, and it would also
  984. let the general public track the progress of the project.
  985. %Worry: the adversary could choose not to block bridges but just record
  986. %connections to them. So be it, I guess.
  987. \subsection{Advantages of deploying all solutions at once}
  988. For once, we're not in the position of the defender: we don't have to
  989. defend against every possible filtering scheme; we just have to defend
  990. against at least one. On the flip side, the attacker is forced to guess
  991. how to allocate his resources to defend against each of these discovery
  992. strategies. So by deploying all of our strategies at once, we not only
  993. increase our chances of finding one that the adversary has difficulty
  994. blocking, but we actually make \emph{all} of the strategies more robust
  995. in the face of an adversary with limited resources.
  996. %\subsection{Remaining unsorted notes}
  997. %In the first subsection we describe how to find a first bridge.
  998. %Going to be an arms race. Need a bag of tricks. Hard to say
  999. %which ones will work. Don't spend them all at once.
  1000. %Some techniques are sufficient to get us an IP address and a port,
  1001. %and others can get us IP:port:key. Lay out some plausible options
  1002. %for how users can bootstrap into learning their first bridge.
  1003. %\section{The account / reputation system}
  1004. %\section{Social networks with directory-side support}
  1005. %\label{sec:accounts}
  1006. %One answer is to measure based on whether the bridge addresses
  1007. %we give it end up blocked. But how do we decide if they get blocked?
  1008. %Perhaps each bridge should be known by a single bridge directory
  1009. %authority. This makes it easier to trace which users have learned about
  1010. %it, so easier to blame or reward. It also makes things more brittle,
  1011. %since loss of that authority means its bridges aren't advertised until
  1012. %they switch, and means its bridge users are sad too.
  1013. %(Need a slick hash algorithm that will map our identity key to a
  1014. %bridge authority, in a way that's sticky even when we add bridge
  1015. %directory authorities, but isn't sticky when our authority goes
  1016. %away. Does this exist?)
  1017. %\subsection{Discovery based on social networks}
  1018. %A token that can be exchanged at the bridge authority (assuming you
  1019. %can reach it) for a new bridge address.
  1020. %The account server runs as a Tor controller for the bridge authority.
  1021. %Users can establish reputations, perhaps based on social network
  1022. %connectivity, perhaps based on not getting their bridge relays blocked,
  1023. %Probably the most critical lesson learned in past work on reputation
  1024. %systems in privacy-oriented environments~\cite{rep-anon} is the need for
  1025. %verifiable transactions. That is, the entity computing and advertising
  1026. %reputations for participants needs to actually learn in a convincing
  1027. %way that a given transaction was successful or unsuccessful.
  1028. %(Lesson from designing reputation systems~\cite{rep-anon}: easy to
  1029. %reward good behavior, hard to punish bad behavior.
  1030. \section{Security considerations}
  1031. \label{sec:security}
  1032. \subsection{Possession of Tor in oppressed areas}
  1033. Many people speculate that installing and using a Tor client in areas with
  1034. particularly extreme firewalls is a high risk---and the risk increases
  1035. as the firewall gets more restrictive. This notion certain has merit, but
  1036. there's
  1037. a counter pressure as well: as the firewall gets more restrictive, more
  1038. ordinary people behind it end up using Tor for more mainstream activities,
  1039. such as learning
  1040. about Wall Street prices or looking at pictures of women's ankles. So
  1041. as the restrictive firewall pushes up the number of Tor users, the
  1042. ``typical'' Tor user becomes more mainstream, and therefore mere
  1043. use or possession of the Tor software is not so surprising.
  1044. It's hard to say which of these pressures will ultimately win out,
  1045. but we should keep both sides of the issue in mind.
  1046. %Nick, want to rewrite/elaborate on this section?
  1047. \subsection{Observers can tell who is publishing and who is reading}
  1048. \label{subsec:upload-padding}
  1049. Tor encrypts traffic on the local network, and it obscures the eventual
  1050. destination of the communication, but it doesn't do much to obscure the
  1051. traffic volume. In particular, a user publishing a home video will have a
  1052. different network signature than a user reading an online news article.
  1053. Based on our assumption in Section~\ref{sec:assumptions} that users who
  1054. publish material are in more danger, should we work to improve Tor's
  1055. security in this situation?
  1056. In the general case this is an extremely challenging task:
  1057. effective \emph{end-to-end traffic confirmation attacks}
  1058. are known where the adversary observes the origin and the
  1059. destination of traffic and confirms that they are part of the
  1060. same communication~\cite{danezis:pet2004,e2e-traffic}. Related are
  1061. \emph{website fingerprinting attacks}, where the adversary downloads
  1062. a few hundred popular websites, makes a set of "signatures" for each
  1063. site, and then observes the target Tor client's traffic to look for
  1064. a match~\cite{pet05-bissias,defensive-dropping}. But can we do better
  1065. against a limited adversary who just does coarse-grained sweeps looking
  1066. for unusually prolific publishers?
  1067. One answer is for bridge users to automatically send bursts of padding
  1068. traffic periodically. (This traffic can be implemented in terms of
  1069. long-range drop cells, which are already part of the Tor specification.)
  1070. Of course, convincingly simulating an actual human publishing interesting
  1071. content is a difficult arms race, but it may be worthwhile to at least
  1072. start the race. More research remains.
  1073. \subsection{Anonymity effects from acting as a bridge relay}
  1074. Against some attacks, relaying traffic for others can improve
  1075. anonymity. The simplest example is an attacker who owns a small number
  1076. of Tor servers. He will see a connection from the bridge, but he won't
  1077. be able to know whether the connection originated there or was relayed
  1078. from somebody else. More generally, the mere uncertainty of whether the
  1079. traffic originated from that user may be helpful.
  1080. There are some cases where it doesn't seem to help: if an attacker can
  1081. watch all of the bridge's incoming and outgoing traffic, then it's easy
  1082. to learn which connections were relayed and which started there. (In this
  1083. case he still doesn't know the final destinations unless he is watching
  1084. them too, but in this case bridges are no better off than if they were
  1085. an ordinary client.)
  1086. There are also some potential downsides to running a bridge. First, while
  1087. we try to make it hard to enumerate all bridges, it's still possible to
  1088. learn about some of them, and for some people just the fact that they're
  1089. running one might signal to an attacker that they place a higher value
  1090. on their anonymity. Second, there are some more esoteric attacks on Tor
  1091. relays that are not as well-understood or well-tested---for example, an
  1092. attacker may be able to ``observe'' whether the bridge is sending traffic
  1093. even if he can't actually watch its network, by relaying traffic through
  1094. it and noticing changes in traffic timing~\cite{attack-tor-oak05}. On
  1095. the other hand, it may be that limiting the bandwidth the bridge is
  1096. willing to relay will allow this sort of attacker to determine if it's
  1097. being used as a bridge but not easily learn whether it is adding traffic
  1098. of its own.
  1099. We also need to examine how entry guards fit in. Entry guards
  1100. (a small set of nodes that are always used for the first
  1101. step in a circuit) help protect against certain attacks
  1102. where the attacker runs a few Tor servers and waits for
  1103. the user to choose these servers as the beginning and end of her
  1104. circuit\footnote{http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ\#EntryGuards}.
  1105. If the blocked user doesn't use the bridge's entry guards, then the bridge
  1106. doesn't gain as much cover benefit. On the other hand, what design changes
  1107. are needed for the blocked user to use the bridge's entry guards without
  1108. learning what they are (this seems hard), and even if we solve that,
  1109. do they then need to use the guards' guards and so on down the line?
  1110. It is an open research question whether the benefits of running a bridge
  1111. outweigh the risks. A lot of the decision rests on which attacks the
  1112. users are most worried about. For most users, we don't think running a
  1113. bridge relay will be that damaging, and it could help quite a bit.
  1114. \subsection{Trusting local hardware: Internet cafes and LiveCDs}
  1115. \label{subsec:cafes-and-livecds}
  1116. Assuming that users have their own trusted hardware is not
  1117. always reasonable.
  1118. For Internet cafe Windows computers that let you attach your own USB key,
  1119. a USB-based Tor image would be smart. There's Torpark, and hopefully
  1120. there will be more thoroughly analyzed options down the road. Worries
  1121. remain about hardware or
  1122. software keyloggers and other spyware---and physical surveillance.
  1123. If the system lets you boot from a CD or from a USB key, you can gain
  1124. a bit more security by bringing a privacy LiveCD with you. (This
  1125. approach isn't foolproof of course, since hardware
  1126. keyloggers and physical surveillance are still a worry).
  1127. In fact, LiveCDs are also useful if it's your own hardware, since it's
  1128. easier to avoid leaving private data and logs scattered around the
  1129. system.
  1130. %\subsection{Forward compatibility and retiring bridge authorities}
  1131. %
  1132. %Eventually we'll want to change the identity key and/or location
  1133. %of a bridge authority. How do we do this mostly cleanly?
  1134. \subsection{The trust chain}
  1135. \label{subsec:trust-chain}
  1136. Tor's ``public key infrastructure'' provides a chain of trust to
  1137. let users verify that they're actually talking to the right servers.
  1138. There are four pieces to this trust chain.
  1139. First, when Tor clients are establishing circuits, at each step
  1140. they demand that the next Tor server in the path prove knowledge of
  1141. its private key~\cite{tor-design}. This step prevents the first node
  1142. in the path from just spoofing the rest of the path. Second, the
  1143. Tor directory authorities provide a signed list of servers along with
  1144. their public keys---so unless the adversary can control a threshold
  1145. of directory authorities, he can't trick the Tor client into using other
  1146. Tor servers. Third, the location and keys of the directory authorities,
  1147. in turn, is hard-coded in the Tor source code---so as long as the user
  1148. got a genuine version of Tor, he can know that he is using the genuine
  1149. Tor network. And last, the source code and other packages are signed
  1150. with the GPG keys of the Tor developers, so users can confirm that they
  1151. did in fact download a genuine version of Tor.
  1152. In the case of blocked users contacting bridges and bridge directory
  1153. authorities, the same logic applies in parallel: the blocked users fetch
  1154. information from both the bridge authorities and the directory authorities
  1155. for the `main' Tor network, and they combine this information locally.
  1156. How can a user in an oppressed country know that he has the correct
  1157. key fingerprints for the developers? As with other security systems, it
  1158. ultimately comes down to human interaction. The keys are signed by dozens
  1159. of people around the world, and we have to hope that our users have met
  1160. enough people in the PGP web of trust
  1161. %~\cite{pgp-wot}
  1162. that they can learn
  1163. the correct keys. For users that aren't connected to the global security
  1164. community, though, this question remains a critical weakness.
  1165. %\subsection{Security through obscurity: publishing our design}
  1166. %Many other schemes like dynaweb use the typical arms race strategy of
  1167. %not publishing their plans. Our goal here is to produce a design---a
  1168. %framework---that can be public and still secure. Where's the tradeoff?
  1169. %\section{Performance improvements}
  1170. %\label{sec:performance}
  1171. %
  1172. %\subsection{Fetch server descriptors just-in-time}
  1173. %
  1174. %I guess we should encourage most places to do this, so blocked
  1175. %users don't stand out.
  1176. %
  1177. %
  1178. %network-status and directory optimizations. caching better. partitioning
  1179. %issues?
  1180. \section{Maintaining reachability}
  1181. \subsection{How many bridge relays should you know about?}
  1182. The strategies described in Section~\ref{sec:discovery} talked about
  1183. learning one bridge address at a time. But if most bridges are ordinary
  1184. Tor users on cable modem or DSL connection, many of them will disappear
  1185. and/or move periodically. How many bridge relays should a blocked user
  1186. know about so that she is likely to have at least one reachable at any
  1187. given point? This is already a challenging problem if we only consider
  1188. natural churn: the best approach is to see what bridges we attract in
  1189. reality and measure their churn. We may also need to factor in a parameter
  1190. for how quickly bridges get discovered and blocked by the attacker;
  1191. we leave this for future work after we have more deployment experience.
  1192. A related question is: if the bridge relays change IP addresses
  1193. periodically, how often does the blocked user need to fetch updates in
  1194. order to keep from being cut out of the loop?
  1195. Once we have more experience and intuition, we should explore technical
  1196. solutions to this problem too. For example, if the discovery strategies
  1197. give out $k$ bridge addresses rather than a single bridge address, perhaps
  1198. we can improve robustness from the user perspective without significantly
  1199. aiding the adversary. Rather than giving out a new random subset of $k$
  1200. addresses at each point, we could bind them together into \emph{bridge
  1201. families}, so all users that learn about one member of the bridge family
  1202. are told about the rest as well.
  1203. This scheme may also help defend against attacks to map the set of
  1204. bridges. That is, if all blocked users learn a random subset of bridges,
  1205. the attacker should learn about a few bridges, monitor the country-level
  1206. firewall for connections to them, then watch those users to see what
  1207. other bridges they use, and repeat. By segmenting the bridge address
  1208. space, we can limit the exposure of other users.
  1209. \subsection{Cablemodem users don't usually provide important websites}
  1210. \label{subsec:block-cable}
  1211. Another attacker we might be concerned about is that the attacker could
  1212. just block all DSL and cablemodem network addresses, on the theory that
  1213. they don't run any important services anyway. If most of our bridges
  1214. are on these networks, this attack could really hurt.
  1215. The first answer is to aim to get volunteers both from traditionally
  1216. ``consumer'' networks and also from traditionally ``producer'' networks.
  1217. Since bridges don't need to be Tor exit nodes, as we improve our usability
  1218. it seems quite feasible to get a lot of websites helping out.
  1219. The second answer (not as practical) would be to encourage more use of
  1220. consumer networks for popular and useful Internet services.
  1221. %(But P2P exists;
  1222. %minor websites exist; gaming exists; IM exists; ...)
  1223. A related attack we might worry about is based on large countries putting
  1224. economic pressure on companies that want to expand their business. For
  1225. example, what happens if Verizon wants to sell services in China, and
  1226. China pressures Verizon to discourage its users in the free world from
  1227. running bridges?
  1228. \subsection{Scanning resistance: making bridges more subtle}
  1229. If it's trivial to verify that a given address is operating as a bridge,
  1230. and most bridges run on a predictable port, then it's conceivable our
  1231. attacker could scan the whole Internet looking for bridges. (In fact, he
  1232. can just concentrate on scanning likely networks like cablemodem and DSL
  1233. services---see Section~\ref{block-cable} above for related attacks.) It
  1234. would be nice to slow down this attack. It would be even nicer to make
  1235. it hard to learn whether we're a bridge without first knowing some
  1236. secret. We call this general property \emph{scanning resistance}.
  1237. Password protecting the bridges.
  1238. Could provide a password to the bridge user. He provides a nonced hash of
  1239. it or something when he connects. We'd need to give him an ID key for the
  1240. bridge too, and wait to present the password until we've TLSed, else the
  1241. adversary can pretend to be the bridge and MITM him to learn the password.
  1242. We could use some kind of ID-based knocking protocol, or we could act like an
  1243. unconfigured HTTPS server if treated like one.
  1244. We can assume that the attacker can easily recognize https connections
  1245. to unknown servers. It can then attempt to connect to them and block
  1246. connections to servers that seem suspicious. It may be that password
  1247. protected web sites will not be suspicious in general, in which case
  1248. that may be the easiest way to give controlled access to the bridge.
  1249. If such sites that have no other overt features are automatically
  1250. blocked when detected, then we may need to be more subtle.
  1251. Possibilities include serving an innocuous web page if a TLS encrypted
  1252. request is received without the authorization needed to access the Tor
  1253. network and only responding to a requested access to the Tor network
  1254. of proper authentication is given. If an unauthenticated request to
  1255. access the Tor network is sent, the bridge should respond as if
  1256. it has received a message it does not understand (as would be the
  1257. case were it not a bridge).
  1258. \subsection{How to motivate people to run bridge relays}
  1259. \label{subsec:incentives}
  1260. One of the traditional ways to get people to run software that benefits
  1261. others is to give them motivation to install it themselves. An often
  1262. suggested approach is to install it as a stunning screensaver so everybody
  1263. will be pleased to run it. We take a similar approach here, by leveraging
  1264. the fact that these users are already interested in protecting their
  1265. own Internet traffic, so they will install and run the software.
  1266. Make all Tor users become bridges if they're reachable---needs more work
  1267. on usability first, but we're making progress.
  1268. Also, we can make a snazzy network graph with Vidalia that emphasizes
  1269. the connections the bridge user is currently relaying. (Minor anonymity
  1270. implications, but hey.) (In many cases there won't be much activity,
  1271. so this may backfire. Or it may be better suited to full-fledged Tor
  1272. servers.)
  1273. % Also consider everybody-a-server. Many of the scalability questions
  1274. % are easier when you're talking about making everybody a bridge.
  1275. %\subsection{What if the clients can't install software?}
  1276. %[this section should probably move to the related work section,
  1277. %or just disappear entirely.]
  1278. %Bridge users without Tor software
  1279. %Bridge relays could always open their socks proxy. This is bad though,
  1280. %first
  1281. %because bridges learn the bridge users' destinations, and second because
  1282. %we've learned that open socks proxies tend to attract abusive users who
  1283. %have no idea they're using Tor.
  1284. %Bridges could require passwords in the socks handshake (not supported
  1285. %by most software including Firefox). Or they could run web proxies
  1286. %that require authentication and then pass the requests into Tor. This
  1287. %approach is probably a good way to help bootstrap the Psiphon network,
  1288. %if one of its barriers to deployment is a lack of volunteers willing
  1289. %to exit directly to websites. But it clearly drops some of the nice
  1290. %anonymity and security features Tor provides.
  1291. %A hybrid approach where the user gets his anonymity from Tor but his
  1292. %software-less use from a web proxy running on a trusted machine on the
  1293. %free side.
  1294. \subsection{Publicity attracts attention}
  1295. \label{subsec:publicity}
  1296. Many people working on this field want to publicize the existence
  1297. and extent of censorship concurrently with the deployment of their
  1298. circumvention software. The easy reason for this two-pronged push is
  1299. to attract volunteers for running proxies in their systems; but in many
  1300. cases their main goal is not to build the software, but rather to educate
  1301. the world about the censorship. The media also tries to do its part by
  1302. broadcasting the existence of each new circumvention system.
  1303. But at the same time, this publicity attracts the attention of the
  1304. censors. We can slow down the arms race by not attracting as much
  1305. attention, and just spreading by word of mouth. If our goal is to
  1306. establish a solid social network of bridges and bridge users before
  1307. the adversary gets involved, does this attention tradeoff work to our
  1308. advantage?
  1309. \subsection{The Tor website: how to get the software}
  1310. One of the first censoring attacks against a system like ours is to
  1311. block the website and make the software itself hard to find. Our system
  1312. should work well once the user is running an authentic
  1313. copy of Tor and has found a working bridge, but to get to that point
  1314. we rely on their individual skills and ingenuity.
  1315. Right now, most countries that block access to Tor block only the main
  1316. website and leave mirrors and the network itself untouched.
  1317. Falling back on word-of-mouth is always a good last resort, but we should
  1318. also take steps to make sure it's relatively easy for users to get a copy,
  1319. such as publicizing the mirrors more and making copies available through
  1320. other media.
  1321. See Section~\ref{subsec:first-bridge} for more discussion.
  1322. \section{Future designs}
  1323. \subsection{Bridges inside the blocked network too}
  1324. Assuming actually crossing the firewall is the risky part of the
  1325. operation, can we have some bridge relays inside the blocked area too,
  1326. and more established users can use them as relays so they don't need to
  1327. communicate over the firewall directly at all? A simple example here is
  1328. to make new blocked users into internal bridges also---so they sign up
  1329. on the bridge authority as part of doing their query, and we give out
  1330. their addresses
  1331. rather than (or along with) the external bridge addresses. This design
  1332. is a lot trickier because it brings in the complexity of whether the
  1333. internal bridges will remain available, can maintain reachability with
  1334. the outside world, etc.
  1335. Hidden services as bridges. Hidden services as bridge directory authorities.
  1336. \section{Conclusion}
  1337. a technical solution won't solve the whole problem. after all, china's
  1338. firewall is *socially* very successful, even if technologies exist to
  1339. get around it.
  1340. but having a strong technical solution is still useful as a piece of the
  1341. puzzle. and tor provides a great set of building blocks to start from.
  1342. \bibliographystyle{plain} \bibliography{tor-design}
  1343. %\appendix
  1344. %\section{Counting Tor users by country}
  1345. %\label{app:geoip}
  1346. \end{document}
  1347. ship geoip db to bridges. they look up users who tls to them in the db,
  1348. and upload a signed list of countries and number-of-users each day. the
  1349. bridge authority aggregates them and publishes stats.
  1350. bridge relays have buddies
  1351. they ask a user to test the reachability of their buddy.
  1352. leaks O(1) bridges, but not O(n).
  1353. we should not be blockable by ordinary cisco censorship features.
  1354. that is, if they want to block our new design, they will need to
  1355. add a feature to block exactly this.
  1356. strategically speaking, this may come in handy.
  1357. Bridges come in clumps of 4 or 8 or whatever. If you know one bridge
  1358. in a clump, the authority will tell you the rest. Now bridges can
  1359. ask users to test reachability of their buddies.
  1360. Giving out clumps helps with dynamic IP addresses too. Whether it
  1361. should be 4 or 8 depends on our churn.
  1362. the account server. let's call it a database, it doesn't have to
  1363. be a thing that human interacts with.
  1364. so how do we reward people for being good?
  1365. \subsubsection{Public Bridges with Coordinated Discovery}
  1366. ****Pretty much this whole subsubsection will probably need to be
  1367. deferred until ``later'' and moved to after end document, but I'm leaving
  1368. it here for now in case useful.******
  1369. Rather than be entirely centralized, we can have a coordinated
  1370. collection of bridge authorities, analogous to how Tor network
  1371. directory authorities now work.
  1372. Key components
  1373. ``Authorities'' will distribute caches of what they know to overlapping
  1374. collections of nodes so that no one node is owned by one authority.
  1375. Also so that it is impossible to DoS info maintained by one authority
  1376. simply by making requests to it.
  1377. Where a bridge gets assigned is not predictable by the bridge?
  1378. If authorities don't know the IP addresses of the bridges they
  1379. are responsible for, they can't abuse that info (or be attacked for
  1380. having it). But, they also can't, e.g., control being sent massive
  1381. lists of nodes that were never good. This raises another question.
  1382. We generally decry use of IP address for location, etc. but we
  1383. need to do that to limit the introduction of functional but useless
  1384. IP addresses because, e.g., they are in China and the adversary
  1385. owns massive chunks of the IP space there.
  1386. We don't want an arbitrary someone to be able to contact the
  1387. authorities and say an IP address is bad because it would be easy
  1388. for an adversary to take down all the suspicious bridges
  1389. even if they provide good cover websites, etc. Only the bridge
  1390. itself and/or the directory authority can declare a bridge blocked
  1391. from somewhere.
  1392. 9. Bridge directories must not simply be a handful of nodes that
  1393. provide the list of bridges. They must flood or otherwise distribute
  1394. information out to other Tor nodes as mirrors. That way it becomes
  1395. difficult for censors to flood the bridge directory servers with
  1396. requests, effectively denying access for others. But, there's lots of
  1397. churn and a much larger size than Tor directories. We are forced to
  1398. handle the directory scaling problem here much sooner than for the
  1399. network in general. Authorities can pass their bridge directories
  1400. (and policy info) to some moderate number of unidentified Tor nodes.
  1401. Anyone contacting one of those nodes can get bridge info. the nodes
  1402. must remain somewhat synched to prevent the adversary from abusing,
  1403. e.g., a timed release policy or the distribution to those nodes must
  1404. be resilient even if they are not coordinating.
  1405. I think some kind of DHT like scheme would work here. A Tor node is
  1406. assigned a chunk of the directory. Lookups in the directory should be
  1407. via hashes of keys (fingerprints) and that should determine the Tor
  1408. nodes responsible. Ordinary directories can publish lists of Tor nodes
  1409. responsible for fingerprint ranges. Clients looking to update info on
  1410. some bridge will make a Tor connection to one of the nodes responsible
  1411. for that address. Instead of shutting down a circuit after getting
  1412. info on one address, extend it to another that is responsible for that
  1413. address (the node from which you are extending knows you are doing so
  1414. anyway). Keep going. This way you can amortize the Tor connection.
  1415. 10. We need some way to give new identity keys out to those who need
  1416. them without letting those get immediately blocked by authorities. One
  1417. way is to give a fingerprint that gets you more fingerprints, as
  1418. already described. These are meted out/updated periodically but allow
  1419. us to keep track of which sources are compromised: if a distribution
  1420. fingerprint repeatedly leads to quickly blocked bridges, it should be
  1421. suspect, dropped, etc. Since we're using hashes, there shouldn't be a
  1422. correlation with bridge directory mirrors, bridges, portions of the
  1423. network observed, etc. It should just be that the authorities know
  1424. about that key that leads to new addresses.
  1425. This last point is very much like the issues in the valet nodes paper,
  1426. which is essentially about blocking resistance wrt exiting the Tor network,
  1427. while this paper is concerned with blocking the entering to the Tor network.
  1428. In fact the tickets used to connect to the IPo (Introduction Point),
  1429. could serve as an example, except that instead of authorizing
  1430. a connection to the Hidden Service, it's authorizing the downloading
  1431. of more fingerprints.
  1432. Also, the fingerprints can follow the hash(q + '1' + cookie) scheme of
  1433. that paper (where q = hash(PK + salt) gave the q.onion address). This
  1434. allows us to control and track which fingerprint was causing problems.
  1435. Note that, unlike many settings, the reputation problem should not be
  1436. hard here. If a bridge says it is blocked, then it might as well be.
  1437. If an adversary can say that the bridge is blocked wrt
  1438. $\mathit{censor}_i$, then it might as well be, since
  1439. $\mathit{censor}_i$ can presumably then block that bridge if it so
  1440. chooses.
  1441. 11. How much damage can the adversary do by running nodes in the Tor
  1442. network and watching for bridge nodes connecting to it? (This is
  1443. analogous to an Introduction Point watching for Valet Nodes connecting
  1444. to it.) What percentage of the network do you need to own to do how
  1445. much damage. Here the entry-guard design comes in helpfully. So we
  1446. need to have bridges use entry-guards, but (cf. 3 above) not use
  1447. bridges as entry-guards. Here's a serious tradeoff (again akin to the
  1448. ratio of valets to IPos) the more bridges/client the worse the
  1449. anonymity of that client. The fewer bridges/client the worse the
  1450. blocking resistance of that client.