sptor.tex 16 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335
  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 Free Haven Project \email{<\{arma,nickm\}@freehaven.net>} \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. Since 2005, continuing work by Free Haven has also
  85. been funded by the Omidyar Network, the Electronic Frontier Foundation
  86. for maintaining civil liberties of ordinary citizens online, and the
  87. International Broadcasting Bureau and Reporters without Borders to
  88. combat blocking and censorship on the Internet. This diversity of
  89. funding fits Tor's overall philosophy: a wide variety of interests
  90. helps maintain both the stability and the security of the network.
  91. Usability is also a central goal. Downloading and installing Tor is
  92. easy. Simply go to\\
  93. http://tor.freehaven.net and download. Tor comes with install
  94. wizards and a GUI for major operating systems: GNU/Linux, OS X, and
  95. Windows. It also runs on various flavors of BSD and UNIX\@. Basic
  96. instructions, documentation, FAQs, etc.\ are available in many
  97. languages. The Tor GUI Vidalia makes server configuration easy, e.g.,
  98. choosing how much bandwidth to allocate to Tor, exit policy choices,
  99. etc. And, the GUI Torbutton allows Firefox users a one-click toggle of
  100. whether browsing goes through Tor or not. Tor is easily configured by
  101. a site administrator to run at either individual desktops or just at a
  102. site firewall or combinations of these.
  103. The ideal Tor network would be practical, useful and anonymous. When
  104. trade-offs arise between these properties, Tor's research strategy has
  105. been to remain useful enough to attract many users, and practical
  106. enough to support them. Only subject to these constraints do we try
  107. to maximize anonymity. Tor thus differs from other deployed systems
  108. for traffic analysis resistance in its security and flexibility. Mix
  109. networks such as
  110. % Mixmaster~\cite{mixmaster-spec} or its successor
  111. Mixminion~\cite{minion-design} gain the highest degrees of practical
  112. anonymity at the expense of introducing highly variable delays, making
  113. them unsuitable for applications such as web browsing. Commercial
  114. single-hop proxies~\cite{anonymizer} can provide good performance, but
  115. a single-point compromise can expose all users' traffic, and a
  116. single-point eavesdropper can perform traffic analysis on the entire
  117. network. Also, their proprietary implementations place any
  118. infrastructure that depends on these single-hop solutions at the mercy
  119. of their providers' financial health as well as network security.
  120. There are numerous other designs for distributed anonymous low-latency
  121. communication~\cite{crowds-tissec,web-mix,freedom21-security,i2p,tarzan:ccs02,morphmix:fc04}.
  122. Some have been deployed or even commercialized; some exist only on
  123. paper. Though each has something unique to offer, we feel Tor has
  124. advantages over each of them that make it a superior choice for most
  125. users and applications. For example, unlike purely P2P designs we
  126. neither limit ordinary users to content and services available only
  127. within our network nor require them to take on responsibility for
  128. connections outside the network, unless they separately choose to run
  129. server nodes.
  130. Our defense lies in having a diverse enough set of nodes to prevent
  131. most real-world adversaries from being in the right places to attack
  132. users, by distributing each transaction over several nodes in the
  133. network. This ``distributed trust'' approach means the Tor network
  134. can be safely operated and used by a wide variety of mutually
  135. distrustful users, providing sustainability and security.
  136. The Tor network has a broad range of users making it difficult for
  137. eavesdroppers to track them or profile interests. These include
  138. ordinary citizens concerned about their privacy, corporations who
  139. don't want to reveal information to their competitors, and law
  140. enforcement and government intelligence agencies who need to do
  141. operations on the Internet without being noticed. Naturally,
  142. organizations will not want to depend on others for their security.
  143. If most participating providers are reliable, Tor tolerates some
  144. hostile infiltration of the network.
  145. This distribution of trust is central to the Tor philosophy and
  146. pervades Tor at all levels: Onion routing has been open source since
  147. the mid-nineties (mistrusting users can inspect the code themselves);
  148. Tor is free software (anyone could take up the development of Tor from
  149. the current team); anyone can use Tor without license or charge, (which
  150. encourages a broad userbase with diverse interests); Tor is designed to be
  151. usable (also promotes a large, diverse userbase); and configurable (so
  152. users can easily set up and run server nodes); the Tor
  153. infrastructure is run by volunteers (it is not dependent on the
  154. economic viability or business strategy of any company) who are
  155. scattered around the globe (not completely under the jurisdiction of
  156. any single country); ongoing development and deployment has been
  157. funded by diverse sources (development does not fully depend on
  158. funding from any one source or even funding for any one primary
  159. purpose or sources in any one jurisdiction). All of these contribute
  160. to Tor's resilience and sustainability.
  161. \section{Social challenges}
  162. Many of the issues the Tor project needs to address extend beyond
  163. system design and technology development. In particular, the Tor
  164. project's \emph{image} with respect to its users and the rest of the
  165. Internet impacts the security it can provide. With this image issue
  166. in mind, this section discusses the Tor user base and Tor's
  167. interaction with other services on the Internet.
  168. \subsection{Communicating security}
  169. Usability for anonymity systems contributes to their security, because
  170. usability affects the possible anonymity set~\cite{econymics,back01}.
  171. Conversely, an unusable system attracts few users and thus can't
  172. provide much anonymity.
  173. This phenomenon has a second-order effect: knowing this, users should
  174. choose which anonymity system to use based in part on how usable and
  175. secure \emph{others} will find it, in order to get the protection of a
  176. larger anonymity set. Thus we might supplement the adage ``usability
  177. is a security parameter''~\cite{back01} with a new one: ``perceived
  178. usability is a security parameter.''~\cite{usability-network-effect}.
  179. \subsection{Reputability and perceived social value}
  180. Another factor impacting the network's security is its reputability,
  181. the perception of its social value based on its current user base. If
  182. Alice is the only user who has ever downloaded the software, it might
  183. be socially accepted, but she's not getting much anonymity. Add a
  184. thousand activists, and she's anonymous, but everyone thinks she's an
  185. activist too. Add a thousand diverse citizens (cancer survivors,
  186. people concerned about identity theft, law enforcement agents, and so
  187. on) and now she's harder to profile.
  188. Furthermore, the network's reputability affects its operator base:
  189. more people are willing to run a service if they believe it will be
  190. used by human rights workers than if they believe it will be used
  191. exclusively for disreputable ends. This effect becomes stronger if
  192. node operators themselves think they will be associated with their
  193. users' ends.
  194. So the more cancer survivors on Tor, the better for the human rights
  195. activists. The more malicious hackers, the worse for the normal
  196. users. Thus, reputability is an anonymity issue for two
  197. reasons. First, it impacts the sustainability of the network: a
  198. network that's always about to be shut down has difficulty attracting
  199. and keeping adequate nodes. Second, a disreputable network is more
  200. vulnerable to legal and political attacks, since it will attract fewer
  201. supporters.
  202. Reputability becomes even more tricky in the case of privacy networks,
  203. since the good uses of the network (such as publishing by journalists
  204. in dangerous countries, protecting road warriors from profiling and
  205. potential physical harm, tracking of criminals by law enforcement,
  206. protecting corporate research interests, etc.) are typically kept private,
  207. whereas network abuses or other problems tend to be more widely
  208. publicized.
  209. \subsection{Abuse}
  210. \label{subsec:tor-and-blacklists}
  211. For someone willing to be antisocial or even break the law, Tor is
  212. usually a poor choice to hide bad behavior. For example, Tor nodes are
  213. publicly identified, unlike the million-node botnets that are now
  214. common on the Internet. Nonetheless, we always expected that,
  215. alongside legitimate users, Tor would also attract troublemakers who
  216. exploit Tor to abuse services on the Internet with vandalism, rude
  217. mail, and so on. \emph{Exit policies} have allowed individual nodes
  218. to block access to specific IP/port ranges. This approach aims to
  219. make operators more willing to run Tor by allowing them to prevent
  220. their nodes from being used for abusing particular services. For
  221. example, by default Tor nodes block SMTP (port 25), to avoid the issue
  222. of spam.
  223. Exit policies are useful but insufficient: if not all nodes block a
  224. given service, that service may try to block Tor instead. While being
  225. blockable is important to being good netizens, we would like to
  226. encourage services to allow anonymous access. Services should not need
  227. to decide between blocking legitimate anonymous use and allowing
  228. unlimited abuse. Nonetheless, blocking IP addresses is a
  229. course-grained solution~\cite{netauth}: entire appartment buildings,
  230. campuses, and even countries sometimes share a single IP address.
  231. Also, whether intended or not, such blocking supports repression of
  232. free speech. In many locations where Internet access of various kinds
  233. is censored or even punished by imprisonment, Tor is a path both to
  234. the outside world and to others inside. Blocking posts from Tor makes
  235. the job of censoring authorities easier. This is a loss for both Tor
  236. and services that block, such as Wikipedia: we don't want to compete
  237. for (or divvy up) the NAT-protected entities of the world. This is
  238. also unfortunate because there are relatively simple technical
  239. solutions~\cite{nym}. Various schemes for escrowing anonymous posts
  240. until they are reviewed by editors would both prevent abuse and remove
  241. incentives for attempts to abuse. Further, pseudonymous reputation
  242. tracking of posters through Tor would allow those who establish
  243. adequate reputation to post without escrow~\cite{nym,nymble}.
  244. We stress that as far as we can tell, most Tor uses are not
  245. abusive. Most services have not complained, and others are actively
  246. working to find ways besides banning to cope with the abuse. For
  247. example, the Freenode IRC network had a problem with a coordinated
  248. group of abusers joining channels and subtly taking over the
  249. conversation; but when they labelled all users coming from Tor IP
  250. addresses as ``anonymous users,'' removing the ability of the abusers
  251. to blend in, the abuse stopped. This is an illustration of how simple
  252. technical mechanisms can remove the ability to abuse anonymously
  253. without undermining the ability to communicate anonymously and can
  254. thus remove the incentive to attempt abusing in this way.
  255. \section{The Future}
  256. \label{sec:conclusion}
  257. Tor is the largest and most diverse low-latency anonymity network
  258. available, but we are still in the early stages. Several major
  259. questions remain.
  260. First, will our volunteer-based approach to sustainability continue to
  261. work as well in the long term as it has the first several years?
  262. Besides node operation, Tor research, deployment, maintainance, and
  263. development is increasingly done by volunteers: package maintenance
  264. for various OSes, document translation, GUI design and implementation,
  265. live CDs, specification of new design changes, etc.\
  266. %
  267. Second, Tor is only one of many components that preserve privacy
  268. online. For applications where it is desirable to keep identifying
  269. information out of application traffic, someone must build more and
  270. better protocol-aware proxies that are usable by ordinary people.
  271. %
  272. Third, we need to maintain a reputation for social good, and learn how to
  273. coexist with the variety of Internet services and their established
  274. authentication mechanisms. We can't just keep escalating the blacklist
  275. standoff forever.
  276. %
  277. Fourth, the current Tor architecture hardly scales even to handle
  278. current user demand. We must deploy designs and incentives to further
  279. encourage clients to relay traffic too, without thereby trading away
  280. too much anonymity or other properties.
  281. These are difficult and open questions. Yet choosing not to solve them
  282. means leaving most users to a less secure network or no anonymizing
  283. network at all.
  284. \bibliographystyle{plain} \bibliography{tor-design}
  285. \end{document}