sptor.tex 16 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337
  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. \newcommand{\workingnote}[1]{} % The version that hides the note.
  18. %\newcommand{\workingnote}[1]{(**#1)} % The version that makes the note visible.
  19. \begin{document}
  20. \title{Design challenges and social factors in deploying low-latency anonymity}
  21. % Could still use a better title -PFS
  22. \author{Roger Dingledine\inst{1} \and
  23. Nick Mathewson\inst{1} \and
  24. Paul Syverson\inst{2}}
  25. \institute{The Tor Project \email{<\{arma,nickm\}@torproject.org>} \and
  26. Naval Research Laboratory \email{<syverson@itd.nrl.navy.mil>}}
  27. \maketitle
  28. \pagestyle{plain}
  29. \begin{abstract}
  30. There are many unexpected or unexpectedly difficult obstacles to
  31. deploying anonymous communications. We describe Tor (\emph{the}
  32. onion routing), how to use it, our design philosophy, and some of
  33. the challenges that we have faced and continue to face in building,
  34. deploying, and sustaining a scalable, distributed, low-latency
  35. anonymity network.
  36. \end{abstract}
  37. \section{Introduction}
  38. This article describes Tor, a widely-used low-latency general-purpose
  39. anonymous communication system, and discusses some unexpected
  40. challenges arising from our experiences deploying Tor. We will tell
  41. you how to use it, who uses it, how it works, why we designed it the
  42. way we did, and why this makes it usable and stable.
  43. Tor is an overlay network for anonymizing TCP streams over the
  44. Internet~\cite{tor-design}. Tor works on the real-world Internet,
  45. requires no special privileges or kernel modifications, requires
  46. little synchronization or coordination between nodes, and provides a
  47. reasonable trade-off between anonymity, usability, and efficiency.
  48. Since deployment in October 2003 the public Tor network has grown to
  49. about a thousand volunteer-operated nodes worldwide and over 110
  50. megabytes average traffic per second from hundreds of thousands of
  51. concurrent users.
  52. \section{Tor Design and Design Philosophy: Distributed Trust and Usability}
  53. Tor enables users to connect to Internet sites without revealing their
  54. logical or physical locations to those sites or to observers. It
  55. enables hosts to be publicly accessible yet have similar protection
  56. against location through its \emph{location-hidden services}.
  57. To connect to a remote server via Tor, the client software learns
  58. a %signed
  59. list of Tor nodes from several central \emph{directory servers} via a
  60. voting protocol to avoid dependence on or complete trust in any one of
  61. them, and incrementally creates a private pathway or \emph{circuit} of
  62. encrypted connections through authenticated Tor nodes on the network,
  63. negotiating a separate set of encryption keys for each hop along the
  64. circuit. The circuit is extended one node at a time, and each node
  65. along the way knows only the immediately previous and following nodes
  66. in the circuit, so no individual Tor node knows the complete path that
  67. each fixed-sized data packet (or \emph{cell}) will take. Thus,
  68. neither an eavesdropper nor a compromised node can see both the
  69. connection's source and destination. Later requests use a new
  70. circuit to complicate long-term linkability between different actions
  71. by a single user.
  72. Tor attempts to anonymize the transport layer, not the application
  73. layer. Thus, applications such as SSH can provide
  74. authenticated communication that is hidden by Tor from outside observers.
  75. When anonymity from communication partners is desired,
  76. application-level protocols that transmit identifying
  77. information need additional scrubbing proxies, such as
  78. Privoxy~\cite{privoxy} for HTTP\@. Furthermore, Tor does not relay
  79. arbitrary IP packets; it only anonymizes TCP streams and DNS requests.
  80. Tor, the third generation of deployed onion-routing
  81. designs~\cite{or-ih96,or-jsac98,tor-design}, was researched, developed,
  82. and deployed by the Naval Research Laboratory and the Free Haven
  83. Project under ONR and DARPA funding for secure government
  84. communications. In 2005, continuing work by Free Haven was funded by
  85. the Electronic Frontier Foundation for maintaining civil liberties of
  86. ordinary citizens online. In 2006, The Tor Project incorporated as a
  87. non-profit and has received continued funding from the Omidyar Network,
  88. the U.S. International Broadcasting Bureau, and other groups to combat
  89. blocking and censorship on the Internet. This diversity of funding fits
  90. Tor's overall philosophy: a wide variety of interests helps maintain
  91. both the stability and the security of the network.
  92. Usability is also a central goal. Downloading and installing Tor is
  93. easy. Simply go to\\
  94. http://torproject.org/ and download. Tor comes with install
  95. wizards and a GUI for major operating systems: GNU/Linux, OS X, and
  96. Windows. It also runs on various flavors of BSD and UNIX\@. Basic
  97. instructions, documentation, FAQs, etc.\ are available in many
  98. languages. The Tor GUI Vidalia makes server configuration easy, e.g.,
  99. choosing how much bandwidth to allocate to Tor, exit policy choices,
  100. etc. And, the GUI Torbutton allows Firefox users a one-click toggle of
  101. whether browsing goes through Tor or not. Tor is easily configured by
  102. a site administrator to run at either individual desktops or just at a
  103. site firewall or combinations of these.
  104. The ideal Tor network would be practical, useful and anonymous. When
  105. trade-offs arise between these properties, Tor's research strategy has
  106. been to remain useful enough to attract many users, and practical
  107. enough to support them. Only subject to these constraints do we try
  108. to maximize anonymity. Tor thus differs from other deployed systems
  109. for traffic analysis resistance in its security and flexibility. Mix
  110. networks such as
  111. % Mixmaster~\cite{mixmaster-spec} or its successor
  112. Mixminion~\cite{minion-design} gain the highest degrees of practical
  113. anonymity at the expense of introducing highly variable delays, making
  114. them unsuitable for applications such as web browsing. Commercial
  115. single-hop proxies~\cite{anonymizer} can provide good performance, but
  116. a single-point compromise can expose all users' traffic, and a
  117. single-point eavesdropper can perform traffic analysis on the entire
  118. network. Also, their proprietary implementations place any
  119. infrastructure that depends on these single-hop solutions at the mercy
  120. of their providers' financial health as well as network security.
  121. There are numerous other designs for distributed anonymous low-latency
  122. communication~\cite{crowds-tissec,web-mix,freedom21-security,i2p,tarzan:ccs02,morphmix:fc04}.
  123. Some have been deployed or even commercialized; some exist only on
  124. paper. Though each has something unique to offer, we feel Tor has
  125. advantages over each of them that make it a superior choice for most
  126. users and applications. For example, unlike purely P2P designs we
  127. neither limit ordinary users to content and services available only
  128. within our network nor require them to take on responsibility for
  129. connections outside the network, unless they separately choose to run
  130. server nodes.
  131. Our defense lies in having a diverse enough set of nodes to prevent
  132. most real-world adversaries from being in the right places to attack
  133. users, by distributing each transaction over several nodes in the
  134. network. This ``distributed trust'' approach means the Tor network
  135. can be safely operated and used by a wide variety of mutually
  136. distrustful users, providing sustainability and security.
  137. The Tor network has a broad range of users, making it difficult for
  138. eavesdroppers to track them or profile interests. These include
  139. ordinary citizens concerned about their privacy, corporations who
  140. don't want to reveal information to their competitors, and law
  141. enforcement and government intelligence agencies who need to do
  142. operations on the Internet without being noticed. Naturally,
  143. organizations will not want to depend on others for their security.
  144. If most participating providers are reliable, Tor tolerates some
  145. hostile infiltration of the network.
  146. This distribution of trust is central to the Tor philosophy and
  147. pervades Tor at all levels: Onion routing has been open source since
  148. the mid-nineties (mistrusting users can inspect the code themselves);
  149. Tor is free software (anyone could take up the development of Tor from
  150. the current team); anyone can use Tor without license or charge (which
  151. encourages a broad user base with diverse interests); Tor is designed to be
  152. usable (also promotes a large, diverse user base) and configurable (so
  153. users can easily set up and run server nodes); the Tor
  154. infrastructure is run by volunteers (it is not dependent on the
  155. economic viability or business strategy of any company) who are
  156. scattered around the globe (not completely under the jurisdiction of
  157. any single country); ongoing development and deployment has been
  158. funded by diverse sources (development does not fully depend on
  159. funding from any one source or even funding for any one primary
  160. purpose or sources in any one jurisdiction). All of these contribute
  161. to Tor's resilience and sustainability.
  162. \section{Social challenges}
  163. Many of the issues the Tor project needs to address extend beyond
  164. system design and technology development. In particular, the Tor
  165. project's \emph{image} with respect to its users and the rest of the
  166. Internet impacts the security it can provide. With this image issue
  167. in mind, this section discusses the Tor user base and Tor's
  168. interaction with other services on the Internet.
  169. \subsection{Communicating security}
  170. Usability for anonymity systems contributes to their security, because
  171. usability affects the possible anonymity set~\cite{econymics,back01}.
  172. Conversely, an unusable system attracts few users and thus can't
  173. provide much anonymity.
  174. This phenomenon has a second-order effect: knowing this, users should
  175. choose which anonymity system to use based in part on how usable and
  176. secure \emph{others} will find it, in order to get the protection of a
  177. larger anonymity set. Thus we might supplement the adage ``usability
  178. is a security parameter''~\cite{back01} with a new one: ``perceived
  179. usability is a security parameter.''~\cite{usability-network-effect}.
  180. \subsection{Reputability and perceived social value}
  181. Another factor impacting the network's security is its reputability,
  182. the perception of its social value based on its current user base. If
  183. Alice is the only user who has ever downloaded the software, it might
  184. be socially accepted, but she's not getting much anonymity. Add a
  185. thousand activists, and she's anonymous, but everyone thinks she's an
  186. activist too. Add a thousand diverse citizens (cancer survivors,
  187. people concerned about identity theft, law enforcement agents, and so
  188. on) and now she's harder to profile.
  189. Furthermore, the network's reputability affects its operator base:
  190. more people are willing to run a service if they believe it will be
  191. used by human rights workers than if they believe it will be used
  192. exclusively for disreputable ends. This effect becomes stronger if
  193. node operators themselves think they will be associated with their
  194. users' ends.
  195. So the more cancer survivors on Tor, the better for the human rights
  196. activists. The more malicious hackers, the worse for the normal
  197. users. Thus, reputability is an anonymity issue for two
  198. reasons. First, it impacts the sustainability of the network: a
  199. network that's always about to be shut down has difficulty attracting
  200. and keeping adequate nodes. Second, a disreputable network is more
  201. vulnerable to legal and political attacks, since it will attract fewer
  202. supporters.
  203. Reputability becomes even more tricky in the case of privacy networks,
  204. since the good uses of the network (such as publishing by journalists
  205. in dangerous countries, protecting road warriors from profiling and
  206. potential physical harm, tracking of criminals by law enforcement,
  207. protecting corporate research interests, etc.) are typically kept private,
  208. whereas network abuses or other problems tend to be more widely
  209. publicized.
  210. \subsection{Abuse}
  211. \label{subsec:tor-and-blacklists}
  212. For someone willing to be antisocial or even break the law, Tor is
  213. usually a poor choice to hide bad behavior. For example, Tor nodes are
  214. publicly identified, unlike the million-node botnets that are now
  215. common on the Internet. Nonetheless, we always expected that,
  216. alongside legitimate users, Tor would also attract troublemakers who
  217. exploit Tor to abuse services on the Internet with vandalism, rude
  218. mail, and so on. \emph{Exit policies} have allowed individual nodes
  219. to block access to specific IP/port ranges. This approach aims to
  220. make operators more willing to run Tor by allowing them to prevent
  221. their nodes from being used for abusing particular services. For
  222. example, by default Tor nodes block SMTP (port 25), to avoid the issue
  223. of spam.
  224. Exit policies are useful but insufficient: if not all nodes block a
  225. given service, that service may try to block Tor instead. While being
  226. blockable is important to being good netizens, we would like to
  227. encourage services to allow anonymous access. Services should not need
  228. to decide between blocking legitimate anonymous use and allowing
  229. unlimited abuse. Nonetheless, blocking IP addresses is a
  230. course-grained solution~\cite{netauth}: entire apartment buildings,
  231. campuses, and even countries sometimes share a single IP address.
  232. Also, whether intended or not, such blocking supports repression of
  233. free speech. In many locations where Internet access of various kinds
  234. is censored or even punished by imprisonment, Tor is a path both to
  235. the outside world and to others inside. Blocking posts from Tor makes
  236. the job of censoring authorities easier. This is a loss for both Tor
  237. and services that block, such as Wikipedia: we don't want to compete
  238. for (or divvy up) the NAT-protected entities of the world. This is
  239. also unfortunate because there are relatively simple technical
  240. solutions~\cite{nym}. Various schemes for escrowing anonymous posts
  241. until they are reviewed by editors would both prevent abuse and remove
  242. incentives for attempts to abuse. Further, pseudonymous reputation
  243. tracking of posters through Tor would allow those who establish
  244. adequate reputation to post without escrow~\cite{nym,nymble}.
  245. We stress that as far as we can tell, most Tor uses are not
  246. abusive. Most services have not complained, and others are actively
  247. working to find ways besides banning to cope with the abuse. For
  248. example, the Freenode IRC network had a problem with a coordinated
  249. group of abusers joining channels and subtly taking over the
  250. conversation; but when they labelled all users coming from Tor IP
  251. addresses as ``anonymous users,'' removing the ability of the abusers
  252. to blend in, the abusers stopped using Tor. This is an illustration of
  253. how simple
  254. technical mechanisms can remove the ability to abuse anonymously
  255. without undermining the ability to communicate anonymously and can
  256. thus remove the incentive to attempt abusing in this way.
  257. \section{The Future}
  258. \label{sec:conclusion}
  259. Tor is the largest and most diverse low-latency anonymity network
  260. available, but we are still in the early stages. Several major
  261. questions remain.
  262. First, will our volunteer-based approach to sustainability continue to
  263. work as well in the long term as it has the first several years?
  264. Besides node operation, Tor research, deployment, maintainance, and
  265. development is increasingly done by volunteers: package maintenance
  266. for various OSes, document translation, GUI design and implementation,
  267. live CDs, specification of new design changes, etc.\
  268. %
  269. Second, Tor is only one of many components that preserve privacy
  270. online. For applications where it is desirable to keep identifying
  271. information out of application traffic, someone must build more and
  272. better protocol-aware proxies that are usable by ordinary people.
  273. %
  274. Third, we need to maintain a reputation for social good, and learn how to
  275. coexist with the variety of Internet services and their established
  276. authentication mechanisms. We can't just keep escalating the blacklist
  277. standoff forever.
  278. %
  279. Fourth, the current Tor architecture hardly scales even to handle
  280. current user demand. We must deploy designs and incentives to further
  281. encourage clients to relay traffic too, without thereby trading away
  282. too much anonymity or other properties.
  283. These are difficult and open questions. Yet choosing not to solve them
  284. means leaving most users to a less secure network or no anonymizing
  285. network at all.
  286. \bibliographystyle{plain} \bibliography{tor-design}
  287. \end{document}