challenges.tex 78 KB

12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576777879808182838485868788899091929394959697989910010110210310410510610710810911011111211311411511611711811912012112212312412512612712812913013113213313413513613713813914014114214314414514614714814915015115215315415515615715815916016116216316416516616716816917017117217317417517617717817918018118218318418518618718818919019119219319419519619719819920020120220320420520620720820921021121221321421521621721821922022122222322422522622722822923023123223323423523623723823924024124224324424524624724824925025125225325425525625725825926026126226326426526626726826927027127227327427527627727827928028128228328428528628728828929029129229329429529629729829930030130230330430530630730830931031131231331431531631731831932032132232332432532632732832933033133233333433533633733833934034134234334434534634734834935035135235335435535635735835936036136236336436536636736836937037137237337437537637737837938038138238338438538638738838939039139239339439539639739839940040140240340440540640740840941041141241341441541641741841942042142242342442542642742842943043143243343443543643743843944044144244344444544644744844945045145245345445545645745845946046146246346446546646746846947047147247347447547647747847948048148248348448548648748848949049149249349449549649749849950050150250350450550650750850951051151251351451551651751851952052152252352452552652752852953053153253353453553653753853954054154254354454554654754854955055155255355455555655755855956056156256356456556656756856957057157257357457557657757857958058158258358458558658758858959059159259359459559659759859960060160260360460560660760860961061161261361461561661761861962062162262362462562662762862963063163263363463563663763863964064164264364464564664764864965065165265365465565665765865966066166266366466566666766866967067167267367467567667767867968068168268368468568668768868969069169269369469569669769869970070170270370470570670770870971071171271371471571671771871972072172272372472572672772872973073173273373473573673773873974074174274374474574674774874975075175275375475575675775875976076176276376476576676776876977077177277377477577677777877978078178278378478578678778878979079179279379479579679779879980080180280380480580680780880981081181281381481581681781881982082182282382482582682782882983083183283383483583683783883984084184284384484584684784884985085185285385485585685785885986086186286386486586686786886987087187287387487587687787887988088188288388488588688788888989089189289389489589689789889990090190290390490590690790890991091191291391491591691791891992092192292392492592692792892993093193293393493593693793893994094194294394494594694794894995095195295395495595695795895996096196296396496596696796896997097197297397497597697797897998098198298398498598698798898999099199299399499599699799899910001001100210031004100510061007100810091010101110121013101410151016101710181019102010211022102310241025102610271028102910301031103210331034103510361037103810391040104110421043104410451046104710481049105010511052105310541055105610571058105910601061106210631064106510661067106810691070107110721073107410751076107710781079108010811082108310841085108610871088108910901091109210931094109510961097109810991100110111021103110411051106110711081109111011111112111311141115111611171118111911201121112211231124112511261127112811291130113111321133113411351136113711381139114011411142114311441145114611471148114911501151115211531154115511561157115811591160116111621163116411651166116711681169117011711172117311741175117611771178117911801181118211831184118511861187118811891190119111921193119411951196119711981199120012011202120312041205120612071208120912101211121212131214121512161217121812191220122112221223122412251226122712281229123012311232123312341235123612371238123912401241124212431244124512461247124812491250125112521253125412551256125712581259126012611262126312641265126612671268126912701271127212731274127512761277127812791280128112821283128412851286128712881289129012911292129312941295129612971298129913001301130213031304130513061307130813091310131113121313131413151316131713181319132013211322132313241325132613271328132913301331133213331334133513361337133813391340134113421343134413451346134713481349135013511352135313541355135613571358135913601361136213631364136513661367136813691370137113721373137413751376137713781379138013811382138313841385138613871388138913901391139213931394139513961397139813991400140114021403140414051406140714081409141014111412141314141415141614171418141914201421142214231424142514261427142814291430143114321433143414351436143714381439144014411442144314441445144614471448144914501451145214531454145514561457145814591460146114621463146414651466146714681469147014711472147314741475147614771478147914801481148214831484148514861487148814891490149114921493149414951496149714981499150015011502150315041505
  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{Challenges in deploying low-latency anonymity (DRAFT)}
  19. \author{Roger Dingledine\inst{1} \and
  20. Nick Mathewson\inst{1} \and
  21. Paul Syverson\inst{2}}
  22. \institute{The Free Haven Project \email{<\{arma,nickm\}@freehaven.net>} \and
  23. Naval Research Laboratory \email{<syverson@itd.nrl.navy.mil>}}
  24. \maketitle
  25. \pagestyle{plain}
  26. \begin{abstract}
  27. There are many unexpected or unexpectedly difficult obstacles to
  28. deploying anonymous communications. Drawing on our experiences deploying
  29. Tor (the second-generation onion routing network), we describe social
  30. challenges and technical issues that must be faced
  31. in building, deploying, and sustaining a scalable, distributed, low-latency
  32. anonymity network.
  33. \end{abstract}
  34. \section{Introduction}
  35. % Your network is not practical unless it is sustainable and distributed.
  36. Anonymous communication is full of surprises. This paper discusses some
  37. unexpected challenges arising from our experiences deploying Tor, a
  38. low-latency general-purpose anonymous communication system. We will discuss
  39. some of the difficulties we have experienced and how we have met them (or how
  40. we plan to meet them, if we know). We also discuss some less
  41. troublesome open problems that we must nevertheless eventually address.
  42. %We will describe both those future challenges that we intend to explore and
  43. %those that we have decided not to explore and why.
  44. Tor is an overlay network for anonymizing TCP streams over the
  45. Internet~\cite{tor-design}. It addresses limitations in earlier Onion
  46. Routing designs~\cite{or-ih96,or-jsac98,or-discex00,or-pet00} by adding
  47. perfect forward secrecy, congestion control, directory servers, data
  48. integrity, configurable exit policies, and location-hidden services using
  49. rendezvous points. Tor works on the real-world Internet, requires no special
  50. privileges or kernel modifications, requires little synchronization or
  51. coordination between nodes, and provides a reasonable trade-off between
  52. anonymity, usability, and efficiency.
  53. We deployed the public Tor network in October 2003; since then it has
  54. grown to over a hundred volunteer-operated nodes
  55. and as much as 80 megabits of
  56. average traffic per second. Tor's research strategy has focused on deploying
  57. a network to as many users as possible; thus, we have resisted designs that
  58. would compromise deployability by imposing high resource demands on node
  59. operators, and designs that would compromise usability by imposing
  60. unacceptable restrictions on which applications we support. Although this
  61. strategy has
  62. drawbacks (including a weakened threat model, as discussed below), it has
  63. made it possible for Tor to serve many thousands of users and attract
  64. funding from diverse sources whose goals range from security on a
  65. national scale down to individual liberties.
  66. In~\cite{tor-design} we gave an overall view of Tor's
  67. design and goals. Here we describe some policy, social, and technical
  68. issues that we face as we continue deployment.
  69. Rather than providing complete solutions to every problem, we
  70. instead lay out the challenges and constraints that we have observed while
  71. deploying Tor. In doing so, we aim to provide a research agenda
  72. of general interest to projects attempting to build
  73. and deploy practical, usable anonymity networks in the wild.
  74. %While the Tor design paper~\cite{tor-design} gives an overall view its
  75. %design and goals,
  76. %this paper describes the policy and technical issues that Tor faces as
  77. %we continue deployment. Rather than trying to provide complete solutions
  78. %to every problem here, we lay out the assumptions and constraints
  79. %that we have observed through deploying Tor in the wild. In doing so, we
  80. %aim to create a research agenda for others to
  81. %help in addressing these issues.
  82. % Section~\ref{sec:what-is-tor} gives an
  83. %overview of the Tor
  84. %design and ours goals. Sections~\ref{sec:crossroads-policy}
  85. %and~\ref{sec:crossroads-design} go on to describe the practical challenges,
  86. %both policy and technical respectively,
  87. %that stand in the way of moving
  88. %from a practical useful network to a practical useful anonymous network.
  89. %\section{What Is Tor}
  90. \section{Background}
  91. Here we give a basic overview of the Tor design and its properties, and
  92. compare Tor to other low-latency anonymity designs.
  93. \subsection{Tor, threat models, and distributed trust}
  94. \label{sec:what-is-tor}
  95. %Here we give a basic overview of the Tor design and its properties. For
  96. %details on the design, assumptions, and security arguments, we refer
  97. %the reader to the Tor design paper~\cite{tor-design}.
  98. Tor provides \emph{forward privacy}, so that users can connect to
  99. Internet sites without revealing their logical or physical locations
  100. to those sites or to observers. It also provides \emph{location-hidden
  101. services}, so that servers can support authorized users without
  102. giving an effective vector for physical or online attackers.
  103. Tor provides these protections even when a portion of its
  104. infrastructure is compromised.
  105. To connect to a remote server via Tor, the client software learns a signed
  106. list of Tor nodes from one of several central \emph{directory servers}, and
  107. incrementally creates a private pathway or \emph{circuit} of encrypted
  108. connections through authenticated Tor nodes on the network, negotiating a
  109. separate set of encryption keys for each hop along the circuit. The circuit
  110. is extended one node at a time, and each node along the way knows only the
  111. immediately previous and following nodes in the circuit, so no individual Tor
  112. node knows the complete path that each fixed-sized data packet (or
  113. \emph{cell}) will take.
  114. %Because each node sees no more than one hop in the
  115. %circuit,
  116. Thus, neither an eavesdropper nor a compromised node can
  117. see both the connection's source and destination. Later requests use a new
  118. circuit, to complicate long-term linkability between different actions by
  119. a single user.
  120. Tor also helps servers hide their locations while
  121. providing services such as web publishing or instant
  122. messaging. Using ``rendezvous points'', other Tor users can
  123. connect to these authenticated hidden services, neither one learning the
  124. other's network identity.
  125. Tor attempts to anonymize the transport layer, not the application layer.
  126. This approach is useful for applications such as SSH
  127. where authenticated communication is desired. However, when anonymity from
  128. those with whom we communicate is desired,
  129. application protocols that include personally identifying information need
  130. additional application-level scrubbing proxies, such as
  131. Privoxy~\cite{privoxy} for HTTP\@. Furthermore, Tor does not relay arbitrary
  132. IP packets; it only anonymizes TCP streams and DNS requests
  133. %, and only supports
  134. %connections via SOCKS
  135. (but see Section~\ref{subsec:tcp-vs-ip}).
  136. Most node operators do not want to allow arbitrary TCP traffic. % to leave
  137. %their server.
  138. To address this, Tor provides \emph{exit policies} so
  139. each exit node can block the IP addresses and ports it is unwilling to allow.
  140. Tor nodes advertise their exit policies to the directory servers, so that
  141. client can tell which nodes will support their connections.
  142. As of January 2005, the Tor network has grown to around a hundred nodes
  143. on four continents, with a total capacity exceeding 1Gbit/s. Appendix A
  144. shows a graph of the number of working nodes over time, as well as a
  145. graph of the number of bytes being handled by the network over time.
  146. The network is now sufficiently diverse for further development
  147. and testing; but of course we always encourage new nodes
  148. to join.
  149. Tor research and development has been funded by ONR and DARPA
  150. for use in securing government
  151. communications, and by the Electronic Frontier Foundation for use
  152. in maintaining civil liberties for ordinary citizens online. The Tor
  153. protocol is one of the leading choices
  154. for the anonymizing layer in the European Union's PRIME directive to
  155. help maintain privacy in Europe.
  156. The AN.ON project in Germany
  157. has integrated an independent implementation of the Tor protocol into
  158. their popular Java Anon Proxy anonymizing client.
  159. % This wide variety of
  160. %interests helps maintain both the stability and the security of the
  161. %network.
  162. \medskip
  163. \noindent
  164. {\bf Threat models and design philosophy.}
  165. The ideal Tor network would be practical, useful and anonymous. When
  166. trade-offs arise between these properties, Tor's research strategy has been
  167. to remain useful enough to attract many users,
  168. and practical enough to support them. Only subject to these
  169. constraints do we try to maximize
  170. anonymity.\footnote{This is not the only possible
  171. direction in anonymity research: designs exist that provide more anonymity
  172. than Tor at the expense of significantly increased resource requirements, or
  173. decreased flexibility in application support (typically because of increased
  174. latency). Such research does not typically abandon aspirations toward
  175. deployability or utility, but instead tries to maximize deployability and
  176. utility subject to a certain degree of structural anonymity (structural because
  177. usability and practicality affect usage which affects the actual anonymity
  178. provided by the network \cite{econymics,back01}).}
  179. %{We believe that these
  180. %approaches can be promising and useful, but that by focusing on deploying a
  181. %usable system in the wild, Tor helps us experiment with the actual parameters
  182. %of what makes a system ``practical'' for volunteer operators and ``useful''
  183. %for home users, and helps illuminate undernoticed issues which any deployed
  184. %volunteer anonymity network will need to address.}
  185. Because of our strategy, Tor has a weaker threat model than many designs in
  186. the literature. In particular, because we
  187. support interactive communications without impractically expensive padding,
  188. we fall prey to a variety
  189. of intra-network~\cite{back01,attack-tor-oak05,flow-correlation04} and
  190. end-to-end~\cite{danezis:pet2004,SS03} anonymity-breaking attacks.
  191. Tor does not attempt to defend against a global observer. In general, an
  192. attacker who can measure both ends of a connection through the Tor network
  193. % I say 'measure' rather than 'observe', to encompass murdoch-danezis
  194. % style attacks. -RD
  195. can correlate the timing and volume of data on that connection as it enters
  196. and leaves the network, and so link communication partners.
  197. Known solutions to this attack would seem to require introducing a
  198. prohibitive degree of traffic padding between the user and the network, or
  199. introducing an unacceptable degree of latency (but see Section
  200. \ref{subsec:mid-latency}). Also, it is not clear that these methods would
  201. work at all against a minimally active adversary who could introduce timing
  202. patterns or additional traffic. Thus, Tor only attempts to defend against
  203. external observers who cannot observe both sides of a user's connections.
  204. Against internal attackers who sign up Tor nodes, the situation is more
  205. complicated. In the simplest case, if an adversary has compromised $c$ of
  206. $n$ nodes on the Tor network, then the adversary will be able to compromise
  207. a random circuit with probability $\frac{c^2}{n^2}$ (since the circuit
  208. initiator chooses hops randomly). But there are
  209. complicating factors:
  210. (1)~If the user continues to build random circuits over time, an adversary
  211. is pretty certain to see a statistical sample of the user's traffic, and
  212. thereby can build an increasingly accurate profile of her behavior. (See
  213. Section~\ref{subsec:helper-nodes} for possible solutions.)
  214. (2)~An adversary who controls a popular service outside the Tor network
  215. can be certain to observe all connections to that service; he
  216. can therefore trace connections to that service with probability
  217. $\frac{c}{n}$.
  218. (3)~Users do not in fact choose nodes with uniform probability; they
  219. favor nodes with high bandwidth or uptime, and exit nodes that
  220. permit connections to their favorite services.
  221. (See Section~\ref{subsec:routing-zones} for discussion of larger
  222. adversaries and our dispersal goals.)
  223. % I'm trying to make this paragraph work without reference to the
  224. % analysis/confirmation distinction, which we haven't actually introduced
  225. % yet, and which we realize isn't very stable anyway. Also, I don't want to
  226. % deprecate these attacks if we can't demonstrate that they don't work, since
  227. % in case they *do* turn out to work well against Tor, we'll look pretty
  228. % foolish. -NM
  229. More powerful attacks may exist. In \cite{hintz-pet02} it was
  230. shown that an attacker who can catalog data volumes of popular
  231. responder destinations (say, websites with consistent data volumes) may not
  232. need to
  233. observe both ends of a stream to learn source-destination links for those
  234. responders.
  235. Similarly, latencies of going through various routes can be
  236. cataloged~\cite{back01} to connect endpoints.
  237. % Also, \cite{kesdogan:pet2002} takes the
  238. % attack another level further, to narrow down where you could be
  239. % based on an intersection attack on subpages in a website. -RD
  240. It has not yet been shown whether these attacks will succeed or fail
  241. in the presence of the variability and volume quantization introduced by the
  242. Tor network, but it seems likely that these factors will at best delay
  243. rather than halt the attacks in the cases where they succeed.
  244. Along similar lines, the same paper suggests a ``clogging
  245. attack'' in which the throughput on a circuit is observed to slow
  246. down when an adversary clogs the right nodes with his own traffic.
  247. To determine the nodes in a circuit this attack requires the ability
  248. to continuously monitor the traffic exiting the network on a circuit
  249. that is up long enough to probe all network nodes in binary fashion.
  250. % Though somewhat related, clogging and interference are really different
  251. % attacks with different assumptions about adversary distribution and
  252. % capabilities as well as different techniques. -pfs
  253. Murdoch and Danezis~\cite{attack-tor-oak05} show a practical
  254. interference attack against portions of
  255. the fifty node Tor network as deployed in mid 2004.
  256. An outside attacker can actively trace a circuit through the Tor network
  257. by observing changes in the latency of his
  258. own traffic sent through various Tor nodes. This can be done
  259. simultaneously at multiple nodes; however, like clogging,
  260. this attack only reveals
  261. the Tor nodes in the circuit, not initiator and responder addresses,
  262. so it is still necessary to discover the endpoints to complete an
  263. effective attack. Increasing the size and diversity of the Tor network may
  264. help counter these attacks.
  265. %discuss $\frac{c^2}{n^2}$, except how in practice the chance of owning
  266. %the last hop is not $c/n$ since that doesn't take the destination (website)
  267. %into account. so in cases where the adversary does not also control the
  268. %final destination we're in good shape, but if he *does* then we'd be better
  269. %off with a system that lets each hop choose a path.
  270. %
  271. %Isn't it more accurate to say ``If the adversary _always_ controls the final
  272. % dest, we would be just as well off with such as system.'' ? If not, why
  273. % not? -nm
  274. % Sure. In fact, better off, since they seem to scale more easily. -rd
  275. %Murdoch and Danezis describe an attack
  276. %\cite{attack-tor-oak05} that lets an attacker determine the nodes used
  277. %in a circuit; yet s/he cannot identify the initiator or responder,
  278. %e.g., client or web server, through this attack. So the endpoints
  279. %remain secure, which is the goal. It is conceivable that an
  280. %adversary could attack or set up observation of all connections
  281. %to an arbitrary Tor node in only a few minutes. If such an adversary
  282. %were to exist, s/he could use this probing to remotely identify a node
  283. %for further attack. Of more likely immediate practical concern
  284. %an adversary with active access to the responder traffic
  285. %wants to keep a circuit alive long enough to attack an identified
  286. %node. Thus it is important to prevent the responding end of the circuit
  287. %from keeping it open indefinitely.
  288. %Also, someone could identify nodes in this way and if in their
  289. %jurisdiction, immediately get a subpoena (if they even need one)
  290. %telling the node operator(s) that she must retain all the active
  291. %circuit data she now has.
  292. %Further, the enclave model, which had previously looked to be the most
  293. %generally secure, seems particularly threatened by this attack, since
  294. %it identifies endpoints when they're also nodes in the Tor network:
  295. %see Section~\ref{subsec:helper-nodes} for discussion of some ways to
  296. %address this issue.
  297. \medskip
  298. \noindent
  299. {\bf Distributed trust.}
  300. In practice Tor's threat model is based on
  301. dispersal and diversity.
  302. Our defense lies in having a diverse enough set of nodes
  303. to prevent most real-world
  304. adversaries from being in the right places to attack users,
  305. by distributing each transaction
  306. over several nodes in the network. This ``distributed trust'' approach
  307. means the Tor network can be safely operated and used by a wide variety
  308. of mutually distrustful users, providing sustainability and security.
  309. %than some previous attempts at anonymizing networks.
  310. No organization can achieve this security on its own. If a single
  311. corporation or government agency were to build a private network to
  312. protect its operations, any connections entering or leaving that network
  313. would be obviously linkable to the controlling organization. The members
  314. and operations of that agency would be easier, not harder, to distinguish.
  315. Instead, to protect our networks from traffic analysis, we must
  316. collaboratively blend the traffic from many organizations and private
  317. citizens, so that an eavesdropper can't tell which users are which,
  318. and who is looking for what information. %By bringing more users onto
  319. %the network, all users become more secure~\cite{econymics}.
  320. %[XXX I feel uncomfortable saying this last sentence now. -RD]
  321. %[So, I took it out. I think we can do without it. -PFS]
  322. The Tor network has a broad range of users, including ordinary citizens
  323. concerned about their privacy, corporations
  324. who don't want to reveal information to their competitors, and law
  325. enforcement and government intelligence agencies who need
  326. to do operations on the Internet without being noticed.
  327. Naturally, organizations will not want to depend on others for their
  328. security. If most participating providers are reliable, Tor tolerates
  329. some hostile infiltration of the network. For maximum protection,
  330. the Tor design includes an enclave approach that lets data be encrypted
  331. (and authenticated) end-to-end, so high-sensitivity users can be sure it
  332. hasn't been read or modified. This even works for Internet services that
  333. don't have built-in encryption and authentication, such as unencrypted
  334. HTTP or chat, and it requires no modification of those services.
  335. \subsection{Related work}
  336. Tor differs from other deployed systems for traffic analysis resistance
  337. in its security and flexibility. Mix networks such as
  338. Mixmaster~\cite{mixmaster-spec} or its successor Mixminion~\cite{minion-design}
  339. gain the highest degrees of anonymity at the expense of introducing highly
  340. variable delays, making them unsuitable for applications such as web
  341. browsing. Commercial single-hop
  342. proxies~\cite{anonymizer} can provide good performance, but
  343. a single compromise can expose all users' traffic, and a single-point
  344. eavesdropper can perform traffic analysis on the entire network.
  345. %Also, their proprietary implementations place any infrastructure that
  346. %depends on these single-hop solutions at the mercy of their providers'
  347. %financial health as well as network security.
  348. The Java
  349. Anon Proxy~\cite{web-mix} provides similar functionality to Tor but
  350. handles only web browsing rather than all TCP\@.
  351. %Some peer-to-peer file-sharing overlay networks such as
  352. %Freenet~\cite{freenet} and Mute~\cite{mute}
  353. The Freedom
  354. network from Zero-Knowledge Systems~\cite{freedom21-security}
  355. was even more flexible than Tor in
  356. transporting arbitrary IP packets, and also supported
  357. pseudonymity in addition to anonymity; but it had
  358. a different approach to sustainability (collecting money from users
  359. and paying ISPs to run Tor nodes), and was eventually shut down due to financial
  360. load. Finally, %potentially more scalable
  361. % [I had added 'potentially' because the scalability of these designs
  362. % is not established, and I am uncomfortable making the
  363. % bolder unmodified assertion. Roger took 'potentially' out.
  364. % Here's an attempt at more neutral wording -pfs]
  365. peer-to-peer designs that are intended to be more scalable,
  366. for example Tarzan~\cite{tarzan:ccs02} and
  367. MorphMix~\cite{morphmix:fc04}, have been proposed in the literature but
  368. have not been fielded. These systems differ somewhat
  369. in threat model and presumably practical resistance to threats.
  370. Note that MorphMix differs from Tor only in
  371. node discovery and circuit setup; so Tor's architecture is flexible
  372. enough to contain a MorphMix experiment.
  373. We direct the interested reader
  374. to~\cite{tor-design} for a more in-depth review of related work.
  375. %XXXX six-four. crowds. i2p.
  376. %XXXX
  377. %have a serious discussion of morphmix's assumptions, since they would
  378. %seem to be the direct competition. in fact tor is a flexible architecture
  379. %that would encompass morphmix, and they're nearly identical except for
  380. %path selection and node discovery. and the trust system morphmix has
  381. %seems overkill (and/or insecure) based on the threat model we've picked.
  382. % this para should probably move to the scalability / directory system. -RD
  383. % Nope. Cut for space, except for small comment added above -PFS
  384. \section{Social challenges}
  385. Many of the issues the Tor project needs to address extend beyond
  386. system design and technology development. In particular, the
  387. Tor project's \emph{image} with respect to its users and the rest of
  388. the Internet impacts the security it can provide.
  389. With this image issue in mind, this section discusses the Tor user base and
  390. Tor's interaction with other services on the Internet.
  391. \subsection{Communicating security}
  392. Usability for anonymity systems
  393. contributes to their security, because usability
  394. affects the possible anonymity set~\cite{econymics,back01}.
  395. Conversely, an unusable system attracts few users and thus can't provide
  396. much anonymity.
  397. This phenomenon has a second-order effect: knowing this, users should
  398. choose which anonymity system to use based in part on how usable
  399. and secure
  400. \emph{others} will find it, in order to get the protection of a larger
  401. anonymity set. Thus we might supplement the adage ``usability is a security
  402. parameter''~\cite{back01} with a new one: ``perceived usability is a
  403. security parameter.'' From here we can better understand the effects
  404. of publicity on security: the more convincing your
  405. advertising, the more likely people will believe you have users, and thus
  406. the more users you will attract. Perversely, over-hyped systems (if they
  407. are not too broken) may be a better choice than modestly promoted ones,
  408. if the hype attracts more users~\cite{usability-network-effect}.
  409. So it follows that we should come up with ways to accurately communicate
  410. the available security levels to the user, so she can make informed
  411. decisions. JAP aims to do this by including a
  412. comforting `anonymity meter' dial in the software's graphical interface,
  413. giving the user an impression of the level of protection for her current
  414. traffic.
  415. However, there's a catch. For users to share the same anonymity set,
  416. they need to act like each other. An attacker who can distinguish
  417. a given user's traffic from the rest of the traffic will not be
  418. distracted by anonymity set size. For high-latency systems like
  419. Mixminion, where the threat model is based on mixing messages with each
  420. other, there's an arms race between end-to-end statistical attacks and
  421. counter-strategies~\cite{statistical-disclosure,minion-design,e2e-traffic,trickle02}.
  422. But for low-latency systems like Tor, end-to-end \emph{traffic
  423. correlation} attacks~\cite{danezis:pet2004,defensive-dropping,SS03}
  424. allow an attacker who can observe both ends of a communication
  425. to correlate packet timing and volume, quickly linking
  426. the initiator to her destination.
  427. Like Tor, the current JAP implementation does not pad connections
  428. apart from using small fixed-size cells for transport. In fact,
  429. JAP's cascade-based network topology may be more vulnerable to these
  430. attacks, because its network has fewer edges. JAP was born out of
  431. the ISDN mix design~\cite{isdn-mixes}, where padding made sense because
  432. every user had a fixed bandwidth allocation and altering the timing
  433. pattern of packets could be immediately detected. But in its current context
  434. as an Internet web anonymizer, adding sufficient padding to JAP
  435. would probably be prohibitively expensive and ineffective against a
  436. minimally active attacker.\footnote{Even if JAP could
  437. fund higher-capacity nodes indefinitely, our experience
  438. suggests that many users would not accept the increased per-user
  439. bandwidth requirements, leading to an overall much smaller user base. But
  440. see Section~\ref{subsec:mid-latency}.} Therefore, since under this threat
  441. model the number of concurrent users does not seem to have much impact
  442. on the anonymity provided, we suggest that JAP's anonymity meter is not
  443. accurately communicating security levels to its users.
  444. On the other hand, while the number of active concurrent users may not
  445. matter as much as we'd like, it still helps to have some other users
  446. on the network. We investigate this issue next.
  447. \subsection{Reputability and perceived social value}
  448. Another factor impacting the network's security is its reputability:
  449. the perception of its social value based on its current user base. If Alice is
  450. the only user who has ever downloaded the software, it might be socially
  451. accepted, but she's not getting much anonymity. Add a thousand
  452. activists, and she's anonymous, but everyone thinks she's an activist too.
  453. Add a thousand
  454. diverse citizens (cancer survivors, privacy enthusiasts, and so on)
  455. and now she's harder to profile.
  456. Furthermore, the network's reputability affects its operator base: more people
  457. are willing to run a service if they believe it will be used by human rights
  458. workers than if they believe it will be used exclusively for disreputable
  459. ends. This effect becomes stronger if node operators themselves think they
  460. will be associated with their users' disreputable ends.
  461. So the more cancer survivors on Tor, the better for the human rights
  462. activists. The more malicious hackers, the worse for the normal users. Thus,
  463. reputability is an anonymity issue for two reasons. First, it impacts
  464. the sustainability of the network: a network that's always about to be
  465. shut down has difficulty attracting and keeping adequate nodes.
  466. Second, a disreputable network is more vulnerable to legal and
  467. political attacks, since it will attract fewer supporters.
  468. While people therefore have an incentive for the network to be used for
  469. ``more reputable'' activities than their own, there are still trade-offs
  470. involved when it comes to anonymity. To follow the above example, a
  471. network used entirely by cancer survivors might welcome file sharers
  472. onto the network, though of course they'd prefer a wider
  473. variety of users.
  474. Reputability becomes even more tricky in the case of privacy networks,
  475. since the good uses of the network (such as publishing by journalists in
  476. dangerous countries) are typically kept private, whereas network abuses
  477. or other problems tend to be more widely publicized.
  478. The impact of public perception on security is especially important
  479. during the bootstrapping phase of the network, where the first few
  480. widely publicized uses of the network can dictate the types of users it
  481. attracts next.
  482. As an example, some U.S.~Department of Energy
  483. penetration testing engineers are tasked with compromising DoE computers
  484. from the outside. They only have a limited number of ISPs from which to
  485. launch their attacks, and they found that the defenders were recognizing
  486. attacks because they came from the same IP space. These engineers wanted
  487. to use Tor to hide their tracks. First, from a technical standpoint,
  488. Tor does not support the variety of IP packets one would like to use in
  489. such attacks (see Section~\ref{subsec:tcp-vs-ip}). But aside from this,
  490. we also decided that it would probably be poor precedent to encourage
  491. such use---even legal use that improves national security---and managed
  492. to dissuade them.
  493. %% "outside of academia, jap has just lost, permanently". (That is,
  494. %% even though the crime detection issues are resolved and are unlikely
  495. %% to go down the same way again, public perception has not been kind.)
  496. \subsection{Sustainability and incentives}
  497. One of the unsolved problems in low-latency anonymity designs is
  498. how to keep the nodes running. ZKS's Freedom network
  499. depended on paying third parties to run its servers; the JAP project's
  500. bandwidth depends on grants to pay for its bandwidth and
  501. administrative expenses. In Tor, bandwidth and administrative costs are
  502. distributed across the volunteers who run Tor nodes, so we at least have
  503. reason to think that the Tor network could survive without continued research
  504. funding.\footnote{It also helps that Tor is implemented with free and open
  505. source software that can be maintained by anybody with the ability and
  506. inclination.} But why are these volunteers running nodes, and what can we
  507. do to encourage more volunteers to do so?
  508. We have not formally surveyed Tor node operators to learn why they are
  509. running nodes, but
  510. from the information they have provided, it seems that many of them run Tor
  511. nodes for reasons of personal interest in privacy issues. It is possible
  512. that others are running Tor nodes to protect their own
  513. anonymity, but of course they are
  514. hardly likely to tell us specifics if they are.
  515. %Significantly, Tor's threat model changes the anonymity incentives for running
  516. %a node. In a high-latency mix network, users can receive additional
  517. %anonymity by running their own node, since doing so obscures when they are
  518. %injecting messages into the network. But, anybody observing all I/O to a Tor
  519. %node can tell when the node is generating traffic that corresponds to
  520. %none of its incoming traffic.
  521. %
  522. %I didn't buy the above for reason's subtle enough that I just cut it -PFS
  523. Tor exit node operators do attain a degree of
  524. ``deniability'' for traffic that originates at that exit node. For
  525. example, it is likely in practice that HTTP requests from a Tor node's IP
  526. will be assumed to be from the Tor network.
  527. More significantly, people and organizations who use Tor for
  528. anonymity depend on the
  529. continued existence of the Tor network to do so; running a node helps to
  530. keep the network operational.
  531. %\item Local Tor entry and exit nodes allow users on a network to run in an
  532. % `enclave' configuration. [XXXX need to resolve this. They would do this
  533. % for E2E encryption + auth?]
  534. %We must try to make the costs of running a Tor node easily minimized.
  535. Since Tor is run by volunteers, the most crucial software usability issue is
  536. usability by operators: when an operator leaves, the network becomes less
  537. usable by everybody. To keep operators pleased, we must try to keep Tor's
  538. resource and administrative demands as low as possible.
  539. Because of ISP billing structures, many Tor operators have underused capacity
  540. that they are willing to donate to the network, at no additional monetary
  541. cost to them. Features to limit bandwidth have been essential to adoption.
  542. Also useful has been a ``hibernation'' feature that allows a Tor node that
  543. wants to provide high bandwidth, but no more than a certain amount in a
  544. giving billing cycle, to become dormant once its bandwidth is exhausted, and
  545. to reawaken at a random offset into the next billing cycle. This feature has
  546. interesting policy implications, however; see
  547. the next section below.
  548. Exit policies help to limit administrative costs by limiting the frequency of
  549. abuse complaints (see Section~\ref{subsec:tor-and-blacklists}). We discuss
  550. technical incentive mechanisms in Section~\ref{subsec:incentives-by-design}.
  551. %[XXXX say more. Why else would you run a node? What else can we do/do we
  552. % already do to make running a node more attractive?]
  553. %[We can enforce incentives; see Section 6.1. We can rate-limit clients.
  554. % We can put "top bandwidth nodes lists" up a la seti@home.]
  555. \subsection{Bandwidth and file-sharing}
  556. \label{subsec:bandwidth-and-file-sharing}
  557. %One potentially problematical area with deploying Tor has been our response
  558. %to file-sharing applications.
  559. Once users have configured their applications to work with Tor, the largest
  560. remaining usability issue is performance. Users begin to suffer
  561. when websites ``feel slow.''
  562. Clients currently try to build their connections through nodes that they
  563. guess will have enough bandwidth. But even if capacity is allocated
  564. optimally, it seems unlikely that the current network architecture will have
  565. enough capacity to provide every user with as much bandwidth as she would
  566. receive if she weren't using Tor, unless far more nodes join the network.
  567. %Limited capacity does not destroy the network, however. Instead, usage tends
  568. %towards an equilibrium: when performance suffers, users who value performance
  569. %over anonymity tend to leave the system, thus freeing capacity until the
  570. %remaining users on the network are exactly those willing to use that capacity
  571. %there is.
  572. Much of Tor's recent bandwidth difficulties have come from file-sharing
  573. applications. These applications provide two challenges to
  574. any anonymizing network: their intensive bandwidth requirement, and the
  575. degree to which they are associated (correctly or not) with copyright
  576. infringement.
  577. High-bandwidth protocols can make the network unresponsive,
  578. but tend to be somewhat self-correcting as lack of bandwidth drives away
  579. users who need it. Issues of copyright violation,
  580. however, are more interesting. Typical exit node operators want to help
  581. people achieve private and anonymous speech, not to help people (say) host
  582. Vin Diesel movies for download; and typical ISPs would rather not
  583. deal with customers who draw menacing letters
  584. from the MPAA\@. While it is quite likely that the operators are doing nothing
  585. illegal, many ISPs have policies of dropping users who get repeated legal
  586. threats regardless of the merits of those threats, and many operators would
  587. prefer to avoid receiving even meritless legal threats.
  588. So when letters arrive, operators are likely to face
  589. pressure to block file-sharing applications entirely, in order to avoid the
  590. hassle.
  591. But blocking file-sharing is not easy: popular
  592. protocols have evolved to run on non-standard ports to
  593. get around other port-based bans. Thus, exit node operators who want to
  594. block file-sharing would have to find some way to integrate Tor with a
  595. protocol-aware exit filter. This could be a technically expensive
  596. undertaking, and one with poor prospects: it is unlikely that Tor exit nodes
  597. would succeed where so many institutional firewalls have failed. Another
  598. possibility for sensitive operators is to run a restrictive node that
  599. only permits exit connections to a restricted range of ports that are
  600. not frequently associated with file sharing. There are increasingly few such
  601. ports.
  602. Other possible approaches might include rate-limiting connections, especially
  603. long-lived connections or connections to file-sharing ports, so that
  604. high-bandwidth connections do not flood the network. We might also want to
  605. give priority to cells on low-bandwidth connections to keep them interactive,
  606. but this could have negative anonymity implications.
  607. For the moment, it seems that Tor's bandwidth issues have rendered it
  608. unattractive for bulk file-sharing traffic; this may continue to be so in the
  609. future. Nevertheless, Tor will likely remain attractive for limited use in
  610. file-sharing protocols that have separate control and data channels.
  611. %[We should say more -- but what? That we'll see a similar
  612. % equilibriating effect as with bandwidth, where sensitive ops switch to
  613. % middleman, and we become less useful for file-sharing, so the file-sharing
  614. % people back off, so we get more ops since there's less file-sharing, so the
  615. % file-sharers come back, etc.]
  616. %XXXX
  617. %in practice, plausible deniability is hypothetical and doesn't seem very
  618. %convincing. if ISPs find the activity antisocial, they don't care *why*
  619. %your computer is doing that behavior.
  620. \subsection{Tor and blacklists}
  621. \label{subsec:tor-and-blacklists}
  622. It was long expected that, alongside legitimate users, Tor would also
  623. attract troublemakers who exploit Tor to abuse services on the
  624. Internet with vandalism, rude mail, and so on.
  625. Our initial answer to this situation was to use ``exit policies''
  626. to allow individual Tor nodes to block access to specific IP/port ranges.
  627. This approach aims to make operators more willing to run Tor by allowing
  628. them to prevent their nodes from being used for abusing particular
  629. services. For example, all Tor nodes currently block SMTP (port 25),
  630. to avoid being used for spam.
  631. Exit policies are useful, but they are insufficient: if not all nodes
  632. block a given service, that service may try to block Tor instead.
  633. While being blockable is important to being good netizens, we would like
  634. to encourage services to allow anonymous access. Services should not
  635. need to decide between blocking legitimate anonymous use and allowing
  636. unlimited abuse.
  637. This is potentially a bigger problem than it may appear.
  638. On the one hand, services should be allowed to refuse connections from
  639. sources of possible abuse.
  640. But when a Tor node administrator decides whether he prefers to be able
  641. to post to Wikipedia from his IP address, or to allow people to read
  642. Wikipedia anonymously through his Tor node, he is making the decision
  643. for others as well. (For a while, Wikipedia
  644. blocked all posting from all Tor nodes based on IP addresses.) If
  645. the Tor node shares an address with a campus or corporate NAT,
  646. then the decision can prevent the entire population from posting.
  647. This is a loss for both Tor
  648. and Wikipedia: we don't want to compete for (or divvy up) the
  649. NAT-protected entities of the world.
  650. Worse, many IP blacklists are coarse-grained: they ignore Tor's exit
  651. policies, partly because it's easier to implement and partly
  652. so they can punish
  653. all Tor nodes. One IP blacklist even bans
  654. every class C network that contains a Tor node, and recommends banning SMTP
  655. from these networks even though Tor does not allow SMTP at all. This
  656. strategic decision aims to discourage the
  657. operation of anything resembling an open proxy by encouraging its neighbors
  658. to shut it down to get unblocked themselves. This pressure even
  659. affects Tor nodes running in middleman mode (disallowing all exits) when
  660. those nodes are blacklisted too.
  661. Problems of abuse occur mainly with services such as IRC networks and
  662. Wikipedia, which rely on IP blocking to ban abusive users. While at first
  663. blush this practice might seem to depend on the anachronistic assumption that
  664. each IP is an identifier for a single user, it is actually more reasonable in
  665. practice: it assumes that non-proxy IPs are a costly resource, and that an
  666. abuser can not change IPs at will. By blocking IPs which are used by Tor
  667. nodes, open proxies, and service abusers, these systems hope to make
  668. ongoing abuse difficult. Although the system is imperfect, it works
  669. tolerably well for them in practice.
  670. Of course, we would prefer that legitimate anonymous users be able to
  671. access abuse-prone services. One conceivable approach would require
  672. would-be IRC users, for instance, to register accounts if they want to
  673. access the IRC network from Tor. In practice this would not
  674. significantly impede abuse if creating new accounts were easily automatable;
  675. this is why services use IP blocking. To deter abuse, pseudonymous
  676. identities need to require a significant switching cost in resources or human
  677. time. Some popular webmail applications
  678. impose cost with Reverse Turing Tests, but this step may not deter all
  679. abusers. Freedom used blind signatures to limit
  680. the number of pseudonyms for each paying account, but Tor has neither the
  681. ability nor the desire to collect payment.
  682. We stress that as far as we can tell, most Tor uses are not
  683. abusive. Most services have not complained, and others are actively
  684. working to find ways besides banning to cope with the abuse. For example,
  685. the Freenode IRC network had a problem with a coordinated group of
  686. abusers joining channels and subtly taking over the conversation; but
  687. when they labelled all users coming from Tor IPs as ``anonymous users,''
  688. removing the ability of the abusers to blend in, the abuse stopped.
  689. %The use of squishy IP-based ``authentication'' and ``authorization''
  690. %has not broken down even to the level that SSNs used for these
  691. %purposes have in commercial and public record contexts. Externalities
  692. %and misplaced incentives cause a continued focus on fighting identity
  693. %theft by protecting SSNs rather than developing better authentication
  694. %and incentive schemes \cite{price-privacy}. Similarly we can expect a
  695. %continued use of identification by IP number as long as there is no
  696. %workable alternative.
  697. %[XXX Mention correct DNS-RBL implementation. -NM]
  698. \section{Design choices}
  699. In addition to social issues, Tor also faces some design trade-offs that must
  700. be investigated as the network develops.
  701. \subsection{Transporting the stream vs transporting the packets}
  702. \label{subsec:stream-vs-packet}
  703. \label{subsec:tcp-vs-ip}
  704. Tor transports streams; it does not tunnel packets.
  705. It has often been suggested that like the old Freedom
  706. network~\cite{freedom21-security}, Tor should
  707. ``obviously'' anonymize IP traffic
  708. at the IP layer. Before this could be done, many issues need to be resolved:
  709. \begin{enumerate}
  710. \setlength{\itemsep}{0mm}
  711. \setlength{\parsep}{0mm}
  712. \item \emph{IP packets reveal OS characteristics.} We would still need to do
  713. IP-level packet normalization, to stop things like TCP fingerprinting
  714. attacks. %There likely exist libraries that can help with this.
  715. This is unlikely to be a trivial task, given the diversity and complexity of
  716. TCP stacks.
  717. \item \emph{Application-level streams still need scrubbing.} We still need
  718. Tor to be easy to integrate with user-level application-specific proxies
  719. such as Privoxy. So it's not just a matter of capturing packets and
  720. anonymizing them at the IP layer.
  721. \item \emph{Certain protocols will still leak information.} For example, we
  722. must rewrite DNS requests so they are delivered to an unlinkable DNS server
  723. rather than the DNS server at a user's ISP; thus, we must understand the
  724. protocols we are transporting.
  725. \item \emph{The crypto is unspecified.} First we need a block-level encryption
  726. approach that can provide security despite
  727. packet loss and out-of-order delivery. Freedom allegedly had one, but it was
  728. never publicly specified.
  729. Also, TLS over UDP is not yet implemented or
  730. specified, though some early work has begun~\cite{dtls}.
  731. \item \emph{We'll still need to tune network parameters.} Since the above
  732. encryption system will likely need sequence numbers (and maybe more) to do
  733. replay detection, handle duplicate frames, and so on, we will be reimplementing
  734. a subset of TCP anyway---a notoriously tricky path.
  735. \item \emph{Exit policies for arbitrary IP packets mean building a secure
  736. IDS\@.} Our node operators tell us that exit policies are one of
  737. the main reasons they're willing to run Tor.
  738. Adding an Intrusion Detection System to handle exit policies would
  739. increase the security complexity of Tor, and would likely not work anyway,
  740. as evidenced by the entire field of IDS and counter-IDS papers. Many
  741. potential abuse issues are resolved by the fact that Tor only transports
  742. valid TCP streams (as opposed to arbitrary IP including malformed packets
  743. and IP floods), so exit policies become even \emph{more} important as
  744. we become able to transport IP packets. We also need to compactly
  745. describe exit policies so clients can predict
  746. which nodes will allow which packets to exit.
  747. \item \emph{The Tor-internal name spaces would need to be redesigned.} We
  748. support hidden service {\tt{.onion}} addresses (and other special addresses,
  749. like {\tt{.exit}} which lets the user request a particular exit node),
  750. by intercepting the addresses when they are passed to the Tor client.
  751. Doing so at the IP level would require a more complex interface between
  752. Tor and the local DNS resolver.
  753. \end{enumerate}
  754. This list is discouragingly long, but being able to transport more
  755. protocols obviously has some advantages. It would be good to learn which
  756. items are actual roadblocks and which are easier to resolve than we think.
  757. To be fair, Tor's stream-based approach has run into
  758. stumbling blocks as well. While Tor supports the SOCKS protocol,
  759. which provides a standardized interface for generic TCP proxies, many
  760. applications do not support SOCKS\@. For them we already need to
  761. replace the networking system calls with SOCKS-aware
  762. versions, or run a SOCKS tunnel locally, neither of which is
  763. easy for the average user. %---even with good instructions.
  764. Even when applications can use SOCKS, they often make DNS requests
  765. themselves before handing an IP address to Tor, which advertises
  766. where the user is about to connect.
  767. We are still working on more usable solutions.
  768. %So to actually provide good anonymity, we need to make sure that
  769. %users have a practical way to use Tor anonymously. Possibilities include
  770. %writing wrappers for applications to anonymize them automatically; improving
  771. %the applications' support for SOCKS; writing libraries to help application
  772. %writers use Tor properly; and implementing a local DNS proxy to reroute DNS
  773. %requests to Tor so that applications can simply point their DNS resolvers at
  774. %localhost and continue to use SOCKS for data only.
  775. \subsection{Mid-latency}
  776. \label{subsec:mid-latency}
  777. Some users need to resist traffic correlation attacks. Higher-latency
  778. mix-networks introduce variability into message
  779. arrival times: as timing variance increases, timing correlation attacks
  780. require increasingly more data~\cite{e2e-traffic}. Can we improve Tor's
  781. resistance without losing too much usability?
  782. We need to learn whether we can trade a small increase in latency
  783. for a large anonymity increase, or if we'd end up trading a lot of
  784. latency for only a minimal security gain. A trade-off might be worthwhile
  785. even if we
  786. could only protect certain use cases, such as infrequent short-duration
  787. transactions. % To answer this question
  788. We might adapt the techniques of~\cite{e2e-traffic} to a lower-latency mix
  789. network, where the messages are batches of cells in temporally clustered
  790. connections. These large fixed-size batches can also help resist volume
  791. signature attacks~\cite{hintz-pet02}. We could also experiment with traffic
  792. shaping to get a good balance of throughput and security.
  793. %Other padding regimens might supplement the
  794. %mid-latency option; however, we should continue the caution with which
  795. %we have always approached padding lest the overhead cost us too much
  796. %performance or too many volunteers.
  797. We must keep usability in mind too. How much can latency increase
  798. before we drive users away? We've already been forced to increase
  799. latency slightly, as our growing network incorporates more DSL and
  800. cable-modem nodes and more nodes in distant continents. Perhaps we can
  801. harness this increased latency to improve anonymity rather than just
  802. reduce usability. Further, if we let clients label certain circuits as
  803. mid-latency as they are constructed, we could handle both types of traffic
  804. on the same network, giving users a choice between speed and security---and
  805. giving researchers a chance to experiment with parameters to improve the
  806. quality of those choices.
  807. \subsection{Enclaves and helper nodes}
  808. \label{subsec:helper-nodes}
  809. It has long been thought that users can improve their anonymity by
  810. running their own node~\cite{tor-design,or-ih96,or-pet00}, and using
  811. it in an \emph{enclave} configuration, where all their circuits begin
  812. at the node under their control. Running Tor clients or servers at
  813. the enclave perimeter is useful when policy or other requirements
  814. prevent individual machines within the enclave from running Tor
  815. clients~\cite{or-jsac98,or-discex00}.
  816. Of course, Tor's default path length of
  817. three is insufficient for these enclaves, since the entry and/or exit
  818. % [edit war: without the ``and/'' the natural reading here
  819. % is aut rather than vel. And the use of the plural verb does not work -pfs]
  820. themselves are sensitive. Tor thus increments path length by one
  821. for each sensitive endpoint in the circuit.
  822. Enclaves also help to protect against end-to-end attacks, since it's
  823. possible that traffic coming from the node has simply been relayed from
  824. elsewhere. However, if the node has recognizable behavior patterns,
  825. an attacker who runs nodes in the network can triangulate over time to
  826. gain confidence that it is in fact originating the traffic. Wright et
  827. al.~\cite{wright03} introduce the notion of a \emph{helper node}---a
  828. single fixed entry node for each user---to combat this \emph{predecessor
  829. attack}.
  830. However, the attack in~\cite{attack-tor-oak05} shows that simply adding
  831. to the path length, or using a helper node, may not protect an enclave
  832. node. A hostile web server can send constant interference traffic to
  833. all nodes in the network, and learn which nodes are involved in the
  834. circuit (though at least in the current attack, he can't learn their
  835. order). Using randomized path lengths may help some, since the attacker
  836. will never be certain he has identified all nodes in the path unless
  837. he probes the entire network, but as
  838. long as the network remains small this attack will still be feasible.
  839. Helper nodes also aim to help Tor clients, because choosing entry and exit
  840. points
  841. randomly and changing them frequently allows an attacker who controls
  842. even a few nodes to eventually link some of their destinations. The goal
  843. is to take the risk once and for all about choosing a bad entry node,
  844. rather than taking a new risk for each new circuit. (Choosing fixed
  845. exit nodes is less useful, since even an honest exit node still doesn't
  846. protect against a hostile website.) But obstacles remain before
  847. we can implement helper nodes.
  848. For one, the literature does not describe how to choose helpers from a list
  849. of nodes that changes over time. If Alice is forced to choose a new entry
  850. helper every $d$ days and $c$ of the $n$ nodes are bad, she can expect
  851. to choose a compromised node around
  852. every $dc/n$ days. Statistically over time this approach only helps
  853. if she is better at choosing honest helper nodes than at choosing
  854. honest nodes. Worse, an attacker with the ability to DoS nodes could
  855. force users to switch helper nodes more frequently, or remove
  856. other candidate helpers.
  857. %Do general DoS attacks have anonymity implications? See e.g. Adam
  858. %Back's IH paper, but I think there's more to be pointed out here. -RD
  859. % Not sure what you want to say here. -NM
  860. %Game theory for helper nodes: if Alice offers a hidden service on a
  861. %server (enclave model), and nobody ever uses helper nodes, then against
  862. %George+Steven's attack she's totally nailed. If only Alice uses a helper
  863. %node, then she's still identified as the source of the data. If everybody
  864. %uses a helper node (including Alice), then the attack identifies the
  865. %helper node and also Alice, and knows which one is which. If everybody
  866. %uses a helper node (but not Alice), then the attacker figures the real
  867. %source was a client that is using Alice as a helper node. [How's my
  868. %logic here?] -RD
  869. %
  870. % Not sure about the logic. For the attack to work with helper nodes, the
  871. %attacker needs to guess that Alice is running the hidden service, right?
  872. %Otherwise, how can he know to measure her traffic specifically? -NM
  873. %
  874. % In the Murdoch-Danezis attack, the adversary measures all servers. -RD
  875. %point to routing-zones section re: helper nodes to defend against
  876. %big stuff.
  877. \subsection{Location-hidden services}
  878. \label{subsec:hidden-services}
  879. % This section is first up against the wall when the revolution comes.
  880. Tor's \emph{rendezvous points}
  881. let users provide TCP services to other Tor users without revealing
  882. the service's location. Since this feature is relatively recent, we describe
  883. here
  884. a couple of our early observations from its deployment.
  885. First, our implementation of hidden services seems less hidden than we'd
  886. like, since they build a different rendezvous circuit for each user,
  887. and an external adversary can induce them to
  888. produce traffic. This insecurity means that they may not be suitable as
  889. a building block for Free Haven~\cite{freehaven-berk} or other anonymous
  890. publishing systems that aim to provide long-term security, though helper
  891. nodes, as discussed above, would seem to help.
  892. \emph{Hot-swap} hidden services, where more than one location can
  893. provide the service and loss of any one location does not imply a
  894. change in service, would help foil intersection and observation attacks
  895. where an adversary monitors availability of a hidden service and also
  896. monitors whether certain users or servers are online. The design
  897. challenges in providing such services without otherwise compromising
  898. the hidden service's anonymity remain an open problem;
  899. however, see~\cite{move-ndss05}.
  900. In practice, hidden services are used for more than just providing private
  901. access to a web server or IRC server. People are using hidden services
  902. as a poor man's VPN and firewall-buster. Many people want to be able
  903. to connect to the computers in their private network via secure shell,
  904. and rather than playing with dyndns and trying to pierce holes in their
  905. firewall, they run a hidden service on the inside and then rendezvous
  906. with that hidden service externally.
  907. News sites like Bloggers Without Borders (www.b19s.org) are advertising
  908. a hidden-service address on their front page. Doing this can provide
  909. increased robustness if they use the dual-IP approach we describe
  910. in~\cite{tor-design},
  911. but in practice they do it to increase visibility
  912. of the Tor project and their support for privacy, and to offer
  913. a way for their users, using unmodified software, to get end-to-end
  914. encryption and authentication to their website.
  915. \subsection{Location diversity and ISP-class adversaries}
  916. \label{subsec:routing-zones}
  917. Anonymity networks have long relied on diversity of node location for
  918. protection against attacks---typically an adversary who can observe a
  919. larger fraction of the network can launch a more effective attack. One
  920. way to achieve dispersal involves growing the network so a given adversary
  921. sees less. Alternately, we can arrange the topology so traffic can enter
  922. or exit at many places (for example, by using a free-route network
  923. like Tor rather than a cascade network like JAP). Lastly, we can use
  924. distributed trust to spread each transaction over multiple jurisdictions.
  925. But how do we decide whether two nodes are in related locations?
  926. Feamster and Dingledine defined a \emph{location diversity} metric
  927. in~\cite{feamster:wpes2004}, and began investigating a variant of location
  928. diversity based on the fact that the Internet is divided into thousands of
  929. independently operated networks called {\em autonomous systems} (ASes).
  930. The key insight from their paper is that while we typically think of a
  931. connection as going directly from the Tor client to the first Tor node,
  932. actually it traverses many different ASes on each hop. An adversary at
  933. any of these ASes can monitor or influence traffic. Specifically, given
  934. plausible initiators and recipients, and given random path selection,
  935. some ASes in the simulation were able to observe 10\% to 30\% of the
  936. transactions (that is, learn both the origin and the destination) on
  937. the deployed Tor network (33 nodes as of June 2004).
  938. The paper concludes that for best protection against the AS-level
  939. adversary, nodes should be in ASes that have the most links to other ASes:
  940. Tier-1 ISPs such as AT\&T and Abovenet. Further, a given transaction
  941. is safest when it starts or ends in a Tier-1 ISP\@. Therefore, assuming
  942. initiator and responder are both in the U.S., it actually \emph{hurts}
  943. our location diversity to use far-flung nodes in
  944. continents like Asia or South America.
  945. % it's not just entering or exiting from them. using them as the middle
  946. % hop reduces your effective path length, which you presumably don't
  947. % want because you chose that path length for a reason.
  948. %
  949. % Not sure I buy that argument. Two end nodes in the right ASs to
  950. % discourage linking are still not known to each other. If some
  951. % adversary in a single AS can bridge the middle node, it shouldn't
  952. % therefore be able to identify initiator or responder; although it could
  953. % contribute to further attacks given more assumptions.
  954. % Nonetheless, no change to the actual text for now.
  955. Many open questions remain. First, it will be an immense engineering
  956. challenge to get an entire BGP routing table to each Tor client, or to
  957. summarize it sufficiently. Without a local copy, clients won't be
  958. able to safely predict what ASes will be traversed on the various paths
  959. through the Tor network to the final destination. Tarzan~\cite{tarzan:ccs02}
  960. and MorphMix~\cite{morphmix:fc04} suggest that we compare IP prefixes to
  961. determine location diversity; but the above paper showed that in practice
  962. many of the Mixmaster nodes that share a single AS have entirely different
  963. IP prefixes. When the network has scaled to thousands of nodes, does IP
  964. prefix comparison become a more useful approximation? % Alternatively, can
  965. %relevant parts of the routing tables be summarized centrally and delivered to
  966. %clients in a less verbose format?
  967. %% i already said "or to summarize is sufficiently" above. is that not
  968. %% enough? -RD
  969. %
  970. Second, we can take advantage of caching certain content at the
  971. exit nodes, to limit the number of requests that need to leave the
  972. network at all. What about taking advantage of caches like Akamai or
  973. Google~\cite{shsm03}? (Note that they're also well-positioned as global
  974. adversaries.)
  975. %
  976. Third, if we follow the recommendations in~\cite{feamster:wpes2004}
  977. and tailor path selection
  978. to avoid choosing endpoints in similar locations, how much are we hurting
  979. anonymity against larger real-world adversaries who can take advantage
  980. of knowing our algorithm?
  981. %
  982. Fourth, can we use this knowledge to figure out which gaps in our network
  983. most affect our robustness to this class of attack, and go recruit
  984. new nodes with those ASes in mind?
  985. %Tor's security relies in large part on the dispersal properties of its
  986. %network. We need to be more aware of the anonymity properties of various
  987. %approaches so we can make better design decisions in the future.
  988. \subsection{The Anti-censorship problem}
  989. \label{subsec:china}
  990. Citizens in a variety of countries, such as most recently China and
  991. Iran, are blocked from accessing various sites outside
  992. their country. These users try to find any tools available to allow
  993. them to get-around these firewalls. Some anonymity networks, such as
  994. Six-Four~\cite{six-four}, are designed specifically with this goal in
  995. mind; others like the Anonymizer~\cite{anonymizer} are paid by sponsors
  996. such as Voice of America to encourage Internet
  997. freedom. Even though Tor wasn't
  998. designed with ubiquitous access to the network in mind, thousands of
  999. users across the world are now using it for exactly this purpose.
  1000. % Academic and NGO organizations, peacefire, \cite{berkman}, etc
  1001. Anti-censorship networks hoping to bridge country-level blocks face
  1002. a variety of challenges. One of these is that they need to find enough
  1003. exit nodes---servers on the `free' side that are willing to relay
  1004. traffic from users to their final destinations. Anonymizing
  1005. networks like Tor are well-suited to this task since we have
  1006. already gathered a set of exit nodes that are willing to tolerate some
  1007. political heat.
  1008. The other main challenge is to distribute a list of reachable relays
  1009. to the users inside the country, and give them software to use those relays,
  1010. without letting the censors also enumerate this list and block each
  1011. relay. Anonymizer solves this by buying lots of seemingly-unrelated IP
  1012. addresses (or having them donated), abandoning old addresses as they are
  1013. `used up,' and telling a few users about the new ones. Distributed
  1014. anonymizing networks again have an advantage here, in that we already
  1015. have tens of thousands of separate IP addresses whose users might
  1016. volunteer to provide this service since they've already installed and use
  1017. the software for their own privacy~\cite{koepsell:wpes2004}. Because
  1018. the Tor protocol separates routing from network discovery \cite{tor-design},
  1019. volunteers could configure their Tor clients
  1020. to generate node descriptors and send them to a special directory
  1021. server that gives them out to dissidents who need to get around blocks.
  1022. Of course, this still doesn't prevent the adversary
  1023. from enumerating and preemptively blocking the volunteer relays.
  1024. Perhaps a tiered-trust system could be built where a few individuals are
  1025. given relays' locations. They could then recommend other individuals
  1026. by telling them
  1027. those addresses, thus providing a built-in incentive to avoid letting the
  1028. adversary intercept them. Max-flow trust algorithms~\cite{advogato}
  1029. might help to bound the number of IP addresses leaked to the adversary. Groups
  1030. like the W3C are looking into using Tor as a component in an overall system to
  1031. help address censorship; we wish them success.
  1032. %\cite{infranet}
  1033. \section{Scaling}
  1034. \label{sec:scaling}
  1035. Tor is running today with hundreds of nodes and tens of thousands of
  1036. users, but it will certainly not scale to millions.
  1037. Scaling Tor involves four main challenges. First, to get a
  1038. large set of nodes, we must address incentives for
  1039. users to carry traffic for others. Next is safe node discovery, both
  1040. while bootstrapping (Tor clients must robustly find an initial
  1041. node list) and later (Tor clients must learn about a fair sample
  1042. of honest nodes and not let the adversary control circuits).
  1043. We must also detect and handle node speed and reliability as the network
  1044. becomes increasingly heterogeneous: since the speed and reliability
  1045. of a circuit is limited by its worst link, we must learn to track and
  1046. predict performance. Finally, we must stop assuming that all points on
  1047. the network can connect to all other points.
  1048. \subsection{Incentives by Design}
  1049. \label{subsec:incentives-by-design}
  1050. There are three behaviors we need to encourage for each Tor node: relaying
  1051. traffic; providing good throughput and reliability while doing it;
  1052. and allowing traffic to exit the network from that node.
  1053. We encourage these behaviors through \emph{indirect} incentives: that
  1054. is, by designing the system and educating users in such a way that users
  1055. with certain goals will choose to relay traffic. One
  1056. main incentive for running a Tor node is social: volunteers
  1057. altruistically donate their bandwidth and time. We encourage this with
  1058. public rankings of the throughput and reliability of nodes, much like
  1059. seti@home. We further explain to users that they can get
  1060. deniability for any traffic emerging from the same address as a Tor
  1061. exit node, and they can use their own Tor node
  1062. as an entry or exit point with confidence that it's not run by an adversary.
  1063. Further, users may run a node simply because they need such a network
  1064. to be persistently available and usable, and the value of supporting this
  1065. exceeds any countervening costs.
  1066. Finally, we can encourage operators by improving the usability and feature
  1067. set of the software:
  1068. rate limiting support and easy packaging decrease the hassle of
  1069. maintaining a node, and our configurable exit policies allow each
  1070. operator to advertise a policy describing the hosts and ports to which
  1071. he feels comfortable connecting.
  1072. To date these incentives appear to have been adequate. As the system scales
  1073. or as new issues emerge, however, we may also need to provide
  1074. \emph{direct} incentives:
  1075. providing payment or other resources in return for high-quality service.
  1076. Paying actual money is problematic: decentralized e-cash systems are
  1077. not yet practical, and a centralized collection system not only reduces
  1078. robustness, but also has failed in the past (the history of commercial
  1079. anonymizing networks is littered with failed attempts). A more promising
  1080. option is to use a tit-for-tat incentive scheme, where nodes provide better
  1081. service to nodes that have provided good service for them.
  1082. Unfortunately, such an approach introduces new anonymity problems.
  1083. There are many surprising ways for nodes to game the incentive and
  1084. reputation system to undermine anonymity---such systems are typically
  1085. designed to encourage fairness in storage or bandwidth usage, not
  1086. fairness of provided anonymity. An adversary can attract more traffic
  1087. by performing well or can target individual users by selectively
  1088. performing, to undermine their anonymity. Typically a user who
  1089. chooses evenly from all nodes is most resistant to an adversary
  1090. targeting him, but that approach hampers the efficient use
  1091. of heterogeneous nodes.
  1092. %When a node (call him Steve) performs well for Alice, does Steve gain
  1093. %reputation with the entire system, or just with Alice? If the entire
  1094. %system, how does Alice tell everybody about her experience in a way that
  1095. %prevents her from lying about it yet still protects her identity? If
  1096. %Steve's behavior only affects Alice's behavior, does this allow Steve to
  1097. %selectively perform only for Alice, and then break her anonymity later
  1098. %when somebody (presumably Alice) routes through his node?
  1099. A possible solution is a simplified approach to the tit-for-tat
  1100. incentive scheme based on two rules: (1) each node should measure the
  1101. service it receives from adjacent nodes, and provide service relative
  1102. to the received service, but (2) when a node is making decisions that
  1103. affect its own security (such as building a circuit for its own
  1104. application connections), it should choose evenly from a sufficiently
  1105. large set of nodes that meet some minimum service
  1106. threshold~\cite{casc-rep}. This approach allows us to discourage
  1107. bad service
  1108. without opening Alice up as much to attacks. All of this requires
  1109. further study.
  1110. \subsection{Trust and discovery}
  1111. \label{subsec:trust-and-discovery}
  1112. The published Tor design is deliberately simplistic in how
  1113. new nodes are authorized and how clients are informed about Tor
  1114. nodes and their status.
  1115. All nodes periodically upload a signed description
  1116. of their locations, keys, and capabilities to each of several well-known {\it
  1117. directory servers}. These directory servers construct a signed summary
  1118. of all known Tor nodes (a ``directory''), and a signed statement of which
  1119. nodes they
  1120. believe to be operational then (a ``network status''). Clients
  1121. periodically download a directory to learn the latest nodes and
  1122. keys, and more frequently download a network status to learn which nodes are
  1123. likely to be running. Tor nodes also operate as directory caches, to
  1124. lighten the bandwidth on the directory servers.
  1125. To prevent Sybil attacks (wherein an adversary signs up many
  1126. purportedly independent nodes to increase her network view),
  1127. this design
  1128. requires the directory server operators to manually
  1129. approve new nodes. Unapproved nodes are included in the directory,
  1130. but clients
  1131. do not use them at the start or end of their circuits. In practice,
  1132. directory administrators perform little actual verification, and tend to
  1133. approve any Tor node whose operator can compose a coherent email.
  1134. This procedure
  1135. may prevent trivial automated Sybil attacks, but will do little
  1136. against a clever and determined attacker.
  1137. There are a number of flaws in this system that need to be addressed as we
  1138. move forward. First,
  1139. each directory server represents an independent point of failure: any
  1140. compromised directory server could start recommending only compromised
  1141. nodes.
  1142. Second, as more nodes join the network, %the more unreasonable it
  1143. %becomes to expect clients to know about them all.
  1144. directories
  1145. become infeasibly large, and downloading the list of nodes becomes
  1146. burdensome.
  1147. Third, the validation scheme may do as much harm as it does good. It
  1148. does not prevent clever attackers from mounting Sybil attacks,
  1149. and it may deter node operators from joining the network---if
  1150. they expect the validation process to be difficult, or they do not share
  1151. any languages in common with the directory server operators.
  1152. We could try to move the system in several directions, depending on our
  1153. choice of threat model and requirements. If we did not need to increase
  1154. network capacity to support more users, we could simply
  1155. adopt even stricter validation requirements, and reduce the number of
  1156. nodes in the network to a trusted minimum.
  1157. But, we can only do that if can simultaneously make node capacity
  1158. scale much more than we anticipate to be feasible soon, and if we can find
  1159. entities willing to run such nodes, an equally daunting prospect.
  1160. In order to address the first two issues, it seems wise to move to a system
  1161. including a number of semi-trusted directory servers, no one of which can
  1162. compromise a user on its own. Ultimately, of course, we cannot escape the
  1163. problem of a first introducer: since most users will run Tor in whatever
  1164. configuration the software ships with, the Tor distribution itself will
  1165. remain a single point of failure so long as it includes the seed
  1166. keys for directory servers, a list of directory servers, or any other means
  1167. to learn which nodes are on the network. But omitting this information
  1168. from the Tor distribution would only delegate the trust problem to each
  1169. individual user. %, most of whom are presumably less informed about how to make
  1170. %trust decisions than the Tor developers.
  1171. A well publicized, widely available, authoritatively and independently
  1172. endorsed and signed list of initial directory servers and their keys
  1173. is a possible solution. But, setting that up properly is itself a large
  1174. bootstrapping task.
  1175. %Network discovery, sybil, node admission, scaling. It seems that the code
  1176. %will ship with something and that's our trust root. We could try to get
  1177. %people to build a web of trust, but no. Where we go from here depends
  1178. %on what threats we have in mind. Really decentralized if your threat is
  1179. %RIAA; less so if threat is to application data or individuals or...
  1180. \subsection{Measuring performance and capacity}
  1181. \label{subsec:performance}
  1182. One of the paradoxes with engineering an anonymity network is that we'd like
  1183. to learn as much as we can about how traffic flows so we can improve the
  1184. network, but we want to prevent others from learning how traffic flows in
  1185. order to trace users' connections through the network. Furthermore, many
  1186. mechanisms that help Tor run efficiently
  1187. require measurements about the network.
  1188. Currently, nodes try to deduce their own available bandwidth (based on how
  1189. much traffic they have been able to transfer recently) and include this
  1190. information in the descriptors they upload to the directory. Clients
  1191. choose servers weighted by their bandwidth, neglecting really slow
  1192. servers and capping the influence of really fast ones.
  1193. %
  1194. This is, of course, eminently cheatable. A malicious node can get a
  1195. disproportionate amount of traffic simply by claiming to have more bandwidth
  1196. than it does. But better mechanisms have their problems. If bandwidth data
  1197. is to be measured rather than self-reported, it is usually possible for
  1198. nodes to selectively provide better service for the measuring party, or
  1199. sabotage the measured value of other nodes. Complex solutions for
  1200. mix networks have been proposed, but do not address the issues
  1201. completely~\cite{mix-acc,casc-rep}.
  1202. Even with no cheating, network measurement is complex. It is common
  1203. for views of a node's latency and/or bandwidth to vary wildly between
  1204. observers. Further, it is unclear whether total bandwidth is really
  1205. the right measure; perhaps clients should instead be considering nodes
  1206. based on unused bandwidth or observed throughput.
  1207. %How to measure performance without letting people selectively deny service
  1208. %by distinguishing pings. Heck, just how to measure performance at all. In
  1209. %practice people have funny firewalls that don't match up to their exit
  1210. %policies and Tor doesn't deal.
  1211. %
  1212. %Network investigation: Is all this bandwidth publishing thing a good idea?
  1213. %How can we collect stats better? Note weasel's smokeping, at
  1214. %http://seppia.noreply.org/cgi-bin/smokeping.cgi?target=Tor
  1215. %which probably gives george and steven enough info to break tor?
  1216. %
  1217. And even if we can collect and use this network information effectively,
  1218. we must ensure
  1219. that it is not more useful to attackers than to us. While it
  1220. seems plausible that bandwidth data alone is not enough to reveal
  1221. sender-recipient connections under most circumstances, it could certainly
  1222. reveal the path taken by large traffic flows under low-usage circumstances.
  1223. \subsection{Non-clique topologies}
  1224. Tor's comparatively weak threat model may allow easier scaling than
  1225. other
  1226. designs. High-latency mix networks need to avoid partitioning attacks, where
  1227. network splits let an attacker distinguish users in different partitions.
  1228. Since Tor assumes the adversary cannot cheaply observe nodes at will,
  1229. a network split may not decrease protection much.
  1230. Thus, one option when the scale of a Tor network
  1231. exceeds some size is simply to split it. Nodes could be allocated into
  1232. partitions while hampering collaborating hostile nodes from taking over
  1233. a single partition~\cite{casc-rep}.
  1234. Clients could switch between
  1235. networks, even on a per-circuit basis.
  1236. %Future analysis may uncover
  1237. %other dangers beyond those affecting mix-nets.
  1238. More conservatively, we can try to scale a single Tor network. Likely
  1239. problems with adding more servers to a single Tor network include an
  1240. explosion in the number of sockets needed on each server as more servers
  1241. join, and increased coordination overhead to keep each users' view of
  1242. the network consistent. As we grow, we will also have more instances of
  1243. servers that can't reach each other simply due to Internet topology or
  1244. routing problems.
  1245. %include restricting the number of sockets and the amount of bandwidth
  1246. %used by each node. The number of sockets is determined by the network's
  1247. %connectivity and the number of users, while bandwidth capacity is determined
  1248. %by the total bandwidth of nodes on the network. The simplest solution to
  1249. %bandwidth capacity is to add more nodes, since adding a Tor node of any
  1250. %feasible bandwidth will increase the traffic capacity of the network. So as
  1251. %a first step to scaling, we should focus on making the network tolerate more
  1252. %nodes, by reducing the interconnectivity of the nodes; later we can reduce
  1253. %overhead associated with directories, discovery, and so on.
  1254. We can address these points by reducing the network's connectivity.
  1255. Danezis~\cite{danezis:pet2003} considers
  1256. the anonymity implications of restricting routes on mix networks and
  1257. recommends an approach based on expander graphs (where any subgraph is likely
  1258. to have many neighbors). It is not immediately clear that this approach will
  1259. extend to Tor, which has a weaker threat model but higher performance
  1260. requirements: instead of analyzing the
  1261. probability of an attacker's viewing whole paths, we will need to examine the
  1262. attacker's likelihood of compromising the endpoints.
  1263. %
  1264. Tor may not need an expander graph per se: it
  1265. may be enough to have a single central subnet that is highly connected, like
  1266. an Internet backbone. % As an
  1267. %example, assume fifty nodes of relatively high traffic capacity. This
  1268. %\emph{center} forms a clique. Assume each center node can
  1269. %handle 200 connections to other nodes (including the other ones in the
  1270. %center). Assume every noncenter node connects to three nodes in the
  1271. %center and anyone out of the center that they want to. Then the
  1272. %network easily scales to c. 2500 nodes with commensurate increase in
  1273. %bandwidth.
  1274. There are many open questions: how to distribute connectivity information
  1275. (presumably nodes will learn about the central nodes
  1276. when they download Tor), whether central nodes
  1277. will need to function as a `backbone', and so on. As above,
  1278. this could reduce the amount of anonymity available from a mix-net,
  1279. but for a low-latency network where anonymity derives largely from
  1280. the edges, it may be feasible.
  1281. %In a sense, Tor already has a non-clique topology.
  1282. %Individuals can set up and run Tor nodes without informing the
  1283. %directory servers. This allows groups to run a
  1284. %local Tor network of private nodes that connects to the public Tor
  1285. %network. This network is hidden behind the Tor network, and its
  1286. %only visible connection to Tor is at those points where it connects.
  1287. %As far as the public network, or anyone observing it, is concerned,
  1288. %they are running clients.
  1289. \section{The Future}
  1290. \label{sec:conclusion}
  1291. Tor is the largest and most diverse low-latency anonymity network
  1292. available, but we are still in the beginning stages of deployment. Several
  1293. major questions remain.
  1294. First, will our volunteer-based approach to sustainability work in the
  1295. long term? As we add more features and destabilize the network, the
  1296. developers spend a lot of time keeping the server operators happy. Even
  1297. though Tor is free software, the network would likely stagnate and die at
  1298. this stage if the developers stopped actively working on it. We may get
  1299. an unexpected boon from the fact that we're a general-purpose overlay
  1300. network: as Tor grows more popular, other groups who need an overlay
  1301. network on the Internet are starting to adapt Tor to their needs.
  1302. %
  1303. Second, Tor is only one of many components that preserve privacy online.
  1304. For applications where it is desirable to
  1305. keep identifying information out of application traffic, someone must build
  1306. more and better protocol-aware proxies that are usable by ordinary people.
  1307. %
  1308. Third, we need to gain a reputation for social good, and learn how to
  1309. coexist with the variety of Internet services and their established
  1310. authentication mechanisms. We can't just keep escalating the blacklist
  1311. standoff forever.
  1312. %
  1313. Fourth, the current Tor
  1314. architecture does not scale even to handle current user demand. We must
  1315. find designs and incentives to let some clients relay traffic too, without
  1316. sacrificing too much anonymity.
  1317. These are difficult and open questions. Yet choosing not to solve them
  1318. means leaving most users to a less secure network or no anonymizing
  1319. network at all.
  1320. \bibliographystyle{plain} \bibliography{tor-design}
  1321. \clearpage
  1322. \appendix
  1323. \begin{figure}[t]
  1324. %\unitlength=1in
  1325. \centering
  1326. %\begin{picture}(6.0,2.0)
  1327. %\put(3,1){\makebox(0,0)[c]{\epsfig{figure=graphnodes,width=6in}}}
  1328. %\end{picture}
  1329. \mbox{\epsfig{figure=graphnodes,width=5in}}
  1330. \caption{Number of Tor nodes over time, through January 2005. Lowest
  1331. line is number of exit
  1332. nodes that allow connections to port 80. Middle line is total number of
  1333. verified (registered) Tor nodes. The line above that represents nodes
  1334. that are running but not yet registered.}
  1335. \label{fig:graphnodes}
  1336. \end{figure}
  1337. \begin{figure}[t]
  1338. \centering
  1339. \mbox{\epsfig{figure=graphtraffic,width=5in}}
  1340. \caption{The sum of traffic reported by each node over time, through
  1341. January 2005. The bottom
  1342. pair show average throughput, and the top pair represent the largest 15
  1343. minute burst in each 4 hour period.}
  1344. \label{fig:graphtraffic}
  1345. \end{figure}
  1346. \end{document}
  1347. %Making use of nodes with little bandwidth, or high latency/packet loss.
  1348. %Running Tor nodes behind NATs, behind great-firewalls-of-China, etc.
  1349. %Restricted routes. How to propagate to everybody the topology? BGP
  1350. %style doesn't work because we don't want just *one* path. Point to
  1351. %Geoff's stuff.