tor-design.tex 93 KB

12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576777879808182838485868788899091929394959697989910010110210310410510610710810911011111211311411511611711811912012112212312412512612712812913013113213313413513613713813914014114214314414514614714814915015115215315415515615715815916016116216316416516616716816917017117217317417517617717817918018118218318418518618718818919019119219319419519619719819920020120220320420520620720820921021121221321421521621721821922022122222322422522622722822923023123223323423523623723823924024124224324424524624724824925025125225325425525625725825926026126226326426526626726826927027127227327427527627727827928028128228328428528628728828929029129229329429529629729829930030130230330430530630730830931031131231331431531631731831932032132232332432532632732832933033133233333433533633733833934034134234334434534634734834935035135235335435535635735835936036136236336436536636736836937037137237337437537637737837938038138238338438538638738838939039139239339439539639739839940040140240340440540640740840941041141241341441541641741841942042142242342442542642742842943043143243343443543643743843944044144244344444544644744844945045145245345445545645745845946046146246346446546646746846947047147247347447547647747847948048148248348448548648748848949049149249349449549649749849950050150250350450550650750850951051151251351451551651751851952052152252352452552652752852953053153253353453553653753853954054154254354454554654754854955055155255355455555655755855956056156256356456556656756856957057157257357457557657757857958058158258358458558658758858959059159259359459559659759859960060160260360460560660760860961061161261361461561661761861962062162262362462562662762862963063163263363463563663763863964064164264364464564664764864965065165265365465565665765865966066166266366466566666766866967067167267367467567667767867968068168268368468568668768868969069169269369469569669769869970070170270370470570670770870971071171271371471571671771871972072172272372472572672772872973073173273373473573673773873974074174274374474574674774874975075175275375475575675775875976076176276376476576676776876977077177277377477577677777877978078178278378478578678778878979079179279379479579679779879980080180280380480580680780880981081181281381481581681781881982082182282382482582682782882983083183283383483583683783883984084184284384484584684784884985085185285385485585685785885986086186286386486586686786886987087187287387487587687787887988088188288388488588688788888989089189289389489589689789889990090190290390490590690790890991091191291391491591691791891992092192292392492592692792892993093193293393493593693793893994094194294394494594694794894995095195295395495595695795895996096196296396496596696796896997097197297397497597697797897998098198298398498598698798898999099199299399499599699799899910001001100210031004100510061007100810091010101110121013101410151016101710181019102010211022102310241025102610271028102910301031103210331034103510361037103810391040104110421043104410451046104710481049105010511052105310541055105610571058105910601061106210631064106510661067106810691070107110721073107410751076107710781079108010811082108310841085108610871088108910901091109210931094109510961097109810991100110111021103110411051106110711081109111011111112111311141115111611171118111911201121112211231124112511261127112811291130113111321133113411351136113711381139114011411142114311441145114611471148114911501151115211531154115511561157115811591160116111621163116411651166116711681169117011711172117311741175117611771178117911801181118211831184118511861187118811891190119111921193119411951196119711981199120012011202120312041205120612071208120912101211121212131214121512161217121812191220122112221223122412251226122712281229123012311232123312341235123612371238123912401241124212431244124512461247124812491250125112521253125412551256125712581259126012611262126312641265126612671268126912701271127212731274127512761277127812791280128112821283128412851286128712881289129012911292129312941295129612971298129913001301130213031304130513061307130813091310131113121313131413151316131713181319132013211322132313241325132613271328132913301331133213331334133513361337133813391340134113421343134413451346134713481349135013511352135313541355135613571358135913601361136213631364136513661367136813691370137113721373137413751376137713781379138013811382138313841385138613871388138913901391139213931394139513961397139813991400140114021403140414051406140714081409141014111412141314141415141614171418141914201421142214231424142514261427142814291430143114321433143414351436143714381439144014411442144314441445144614471448144914501451145214531454145514561457145814591460146114621463146414651466146714681469147014711472147314741475147614771478147914801481148214831484148514861487148814891490149114921493149414951496149714981499150015011502150315041505150615071508150915101511151215131514151515161517151815191520152115221523152415251526152715281529153015311532153315341535153615371538153915401541154215431544154515461547154815491550155115521553155415551556155715581559156015611562156315641565156615671568156915701571157215731574157515761577157815791580158115821583158415851586158715881589159015911592159315941595159615971598159916001601160216031604160516061607160816091610161116121613161416151616161716181619162016211622162316241625162616271628162916301631163216331634163516361637163816391640164116421643164416451646164716481649165016511652165316541655165616571658165916601661166216631664166516661667166816691670167116721673167416751676167716781679168016811682168316841685168616871688168916901691169216931694169516961697169816991700170117021703170417051706170717081709171017111712171317141715171617171718171917201721172217231724172517261727172817291730173117321733173417351736173717381739174017411742174317441745174617471748174917501751175217531754175517561757175817591760176117621763176417651766176717681769177017711772177317741775177617771778177917801781178217831784178517861787178817891790179117921793179417951796179717981799180018011802180318041805180618071808180918101811181218131814181518161817181818191820182118221823182418251826182718281829183018311832183318341835183618371838183918401841184218431844184518461847
  1. \documentclass[times,10pt,twocolumn]{article}
  2. \usepackage{latex8}
  3. \usepackage{times}
  4. \usepackage{url}
  5. \usepackage{graphics}
  6. \usepackage{amsmath}
  7. %\pagestyle{empty}
  8. \renewcommand\url{\begingroup \def\UrlLeft{<}\def\UrlRight{>}\urlstyle{tt}\Url}
  9. \newcommand\emailaddr{\begingroup \def\UrlLeft{<}\def\UrlRight{>}\urlstyle{tt}\Url}
  10. \newcommand{\workingnote}[1]{} % The version that hides the note.
  11. %\newcommand{\workingnote}[1]{(**#1)} % The version that makes the note visible.
  12. % If an URL ends up with '%'s in it, that's because the line *in the .bib/.tex
  13. % file* is too long, so break it there (it doesn't matter if the next line is
  14. % indented with spaces). -DH
  15. %\newif\ifpdf
  16. %\ifx\pdfoutput\undefined
  17. % \pdffalse
  18. %\else
  19. % \pdfoutput=1
  20. % \pdftrue
  21. %\fi
  22. \newenvironment{tightlist}{\begin{list}{$\bullet$}{
  23. \setlength{\itemsep}{0mm}
  24. \setlength{\parsep}{0mm}
  25. % \setlength{\labelsep}{0mm}
  26. % \setlength{\labelwidth}{0mm}
  27. % \setlength{\topsep}{0mm}
  28. }}{\end{list}}
  29. \begin{document}
  30. %% Use dvipdfm instead. --DH
  31. %\ifpdf
  32. % \pdfcompresslevel=9
  33. % \pdfpagewidth=\the\paperwidth
  34. % \pdfpageheight=\the\paperheight
  35. %\fi
  36. \title{Tor: The Second-Generation Onion Router}
  37. % Putting the 'Private' back in 'Virtual Private Network'
  38. \author{Roger Dingledine \\ The Free Haven Project \\ arma@freehaven.net \and
  39. Nick Mathewson \\ The Free Haven Project \\ nickm@freehaven.net \and
  40. Paul Syverson \\ Naval Research Lab \\ syverson@itd.nrl.navy.mil}
  41. \maketitle
  42. \thispagestyle{empty}
  43. \begin{abstract}
  44. We present Tor, a circuit-based low-latency anonymous communication
  45. service. This second-generation Onion Routing system addresses limitations
  46. in the original design. Tor adds perfect forward secrecy, congestion
  47. control, directory servers, integrity checking, variable exit policies,
  48. and a practical design for rendezvous points. Tor works on the real-world
  49. Internet, requires no special privileges or kernel modifications, requires
  50. little synchronization or coordination between nodes, and provides a
  51. reasonable tradeoff between anonymity, usability, and efficiency. We
  52. close with a list of open problems in anonymous communication.
  53. \end{abstract}
  54. %\begin{center}
  55. %\textbf{Keywords:} anonymity, peer-to-peer, remailer, nymserver, reply block
  56. %\end{center}
  57. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
  58. \Section{Overview}
  59. \label{sec:intro}
  60. Onion Routing is a distributed overlay network designed to anonymize
  61. low-latency TCP-based applications such as web browsing, secure shell,
  62. and instant messaging. Clients choose a path through the network and
  63. build a \emph{circuit}, in which each node (or ``onion router'' or ``OR'')
  64. in the path knows its predecessor and successor, but no other nodes in
  65. the circuit. Traffic flowing down the circuit is sent in fixed-size
  66. \emph{cells}, which are unwrapped by a symmetric key at each node
  67. (like the layers of an onion) and relayed downstream. The
  68. Onion Routing project published several design and analysis papers
  69. \cite{or-ih96,or-jsac98,or-discex00,or-pet00}. While a wide area Onion
  70. Routing network was deployed briefly, the only long-running and
  71. publicly accessible implementation was a fragile
  72. proof-of-concept that ran on a single machine. Even this simple deployment
  73. processed connections from over sixty thousand distinct IP addresses from
  74. all over the world at a rate of about fifty thousand per day.
  75. But many critical design and deployment issues were never
  76. resolved, and the design has not been updated in several years. Here
  77. we describe Tor, a protocol for asynchronous, loosely federated onion
  78. routers that provides the following improvements over the old Onion
  79. Routing design:
  80. \textbf{Perfect forward secrecy:} Onion Routing
  81. was originally vulnerable to a single hostile node recording traffic and
  82. later compromising successive nodes in the circuit and forcing them
  83. to decrypt it. Rather than using a single multiply encrypted data
  84. structure (an \emph{onion}) to lay each circuit,
  85. Tor now uses an incremental or \emph{telescoping} path-building design,
  86. where the initiator negotiates session keys with each successive hop in
  87. the circuit. Once these keys are deleted, subsequently compromised nodes
  88. cannot decrypt old traffic. As a side benefit, onion replay detection
  89. is no longer necessary, and the process of building circuits is more
  90. reliable, since the initiator knows when a hop fails and can then try
  91. extending to a new node.
  92. \textbf{Separation of ``protocol cleaning'' from anonymity:}
  93. Onion Routing originally required a separate ``application
  94. proxy'' for each supported application protocol---most of which were
  95. never written, so many applications were never supported. Tor uses the
  96. standard and near-ubiquitous SOCKS \cite{socks4} proxy interface, allowing
  97. us to support most TCP-based programs without modification. Tor now
  98. relies on the filtering features of privacy-enhancing
  99. application-level proxies such as Privoxy \cite{privoxy}, without trying
  100. to duplicate those features itself.
  101. \textbf{No mixing, padding, or traffic shaping yet:} Onion
  102. Routing originally called for batching and reordering cells as they arrived,
  103. assumed padding between ORs, and in
  104. later designs added padding between onion proxies (users) and ORs
  105. \cite{or-ih96,or-jsac98}. Tradeoffs between padding protection
  106. and cost were discussed, and \emph{traffic shaping} algorithms were
  107. theorized \cite{or-pet00} to provide good security without expensive
  108. padding, but no concrete padding scheme was suggested.
  109. Recent research \cite{econymics}
  110. and deployment experience \cite{freedom21-security} suggest that this
  111. level of resource use is not practical or economical; and even full
  112. link padding is still vulnerable \cite{defensive-dropping}. Thus,
  113. until we have a proven and convenient design for traffic shaping or
  114. low-latency mixing that improves anonymity against a realistic
  115. adversary, we leave these strategies out.
  116. \textbf{Many TCP streams can share one circuit:} Onion Routing originally
  117. built a separate circuit for each
  118. application-level request, but this required
  119. multiple public key operations for every request, and also presented
  120. a threat to anonymity from building so many circuits; see
  121. Section~\ref{sec:maintaining-anonymity}. Tor multiplexes multiple TCP
  122. streams along each circuit to improve efficiency and anonymity.
  123. \textbf{Leaky-pipe circuit topology:} Through in-band signaling
  124. within the circuit, Tor initiators can direct traffic to nodes partway
  125. down the circuit. This novel approach
  126. allows traffic to exit the circuit from the middle---possibly
  127. frustrating traffic shape and volume attacks based on observing the end
  128. of the circuit. (It also allows for long-range padding if
  129. future research shows this to be worthwhile.)
  130. \textbf{Congestion control:} Earlier anonymity designs do not
  131. address traffic bottlenecks. Unfortunately, typical approaches to
  132. load balancing and flow control in overlay networks involve inter-node
  133. control communication and global views of traffic. Tor's decentralized
  134. congestion control uses end-to-end acks to maintain anonymity
  135. while allowing nodes at the edges of the network to detect congestion
  136. or flooding and send less data until the congestion subsides.
  137. \textbf{Directory servers:} The earlier Onion Routing design
  138. planned to flood link-state information through the network---an approach
  139. that can be unreliable and open to partitioning attacks.
  140. Tor takes a simplified view toward distributing such
  141. information. Certain more trusted nodes act as \emph{directory
  142. servers}: they provide signed directories that describe known
  143. routers and their availability. Users periodically download the
  144. directories via HTTP.
  145. \textbf{Variable exit policies:} Tor provides a consistent mechanism
  146. for each node to advertise a policy describing the hosts
  147. and ports to which it will connect. These exit policies are critical
  148. in a volunteer-based distributed infrastructure, because each operator
  149. is comfortable with allowing different types of traffic to exit the Tor
  150. network from his node.
  151. \textbf{End-to-end integrity checking:} The original Onion Routing
  152. design did no integrity checking on data. Any node on the
  153. circuit could change the contents of data cells as they passed by---for
  154. example, to alter a connection request so it would connect
  155. to a different webserver, or to `tag' encrypted traffic and look for
  156. corresponding corrupted traffic at the network edges \cite{minion-design}.
  157. Tor hampers these attacks by checking data integrity before it leaves
  158. the network.
  159. \textbf{Improved robustness to failed nodes:} A failed node
  160. in the old design meant that circuit building failed, but thanks to
  161. Tor's step-by-step circuit building, users notice failed nodes
  162. while building circuits and route around them. Additionally, liveness
  163. information from directories allows users to avoid unreliable nodes in
  164. the first place.
  165. \textbf{Rendezvous points and hidden services:}
  166. Tor provides an integrated mechanism for responder anonymity via
  167. location-protected servers. Previous Onion Routing designs included
  168. long-lived ``reply onions'' that could be used to build circuits
  169. to a hidden server, but these reply onions did not provide forward
  170. security, and became useless if any node in the path went down
  171. or rotated its keys. In Tor, clients negotiate {\it rendezvous points}
  172. to connect with hidden servers; reply onions are no longer required.
  173. Unlike Freedom \cite{freedom2-arch}, Tor only tries to anonymize
  174. TCP streams. Not requiring patches (or built-in support) in an
  175. operating system's network stack has been valuable to Tor's
  176. portability and deployability.
  177. We have implemented most of the above features. Our source code is
  178. available under a free license, and, as far as we know, is unencumbered by
  179. patents. We have recently begun deploying a wide-area alpha network
  180. to test the design in practice, to get more experience with usability
  181. and users, and to provide a research platform for experimentation.
  182. We review previous work in Section~\ref{sec:related-work}, describe
  183. our goals and assumptions in Section~\ref{sec:assumptions},
  184. and then address the above list of improvements in
  185. Sections~\ref{sec:design}-\ref{sec:rendezvous}. We summarize
  186. in Section~\ref{sec:attacks} how our design stands up to
  187. known attacks, and conclude with a list of open problems in
  188. Section~\ref{sec:maintaining-anonymity} and future work for the Onion
  189. Routing project in Section~\ref{sec:conclusion}.
  190. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
  191. \Section{Related work}
  192. \label{sec:related-work}
  193. Modern anonymity systems date to Chaum's {\bf Mix-Net} design
  194. \cite{chaum-mix}. Chaum
  195. proposed hiding the correspondence between sender and recipient by
  196. wrapping messages in layers of public-key cryptography, and relaying them
  197. through a path composed of ``mixes.'' Each mix in turn
  198. decrypts, delays, and re-orders messages, before relaying them toward
  199. their destinations.
  200. Subsequent relay-based anonymity designs have diverged in two
  201. main directions. Some have tried to maximize anonymity at
  202. the cost of introducing comparatively large and variable latencies,
  203. including {\bf Babel} \cite{babel}, {\bf Mixmaster}
  204. \cite{mixmaster-spec}, and
  205. {\bf Mixminion} \cite{minion-design}. Because of this
  206. decision, these \emph{high-latency} networks resist strong global
  207. adversaries,
  208. but introduce too much lag for interactive tasks like web browsing,
  209. internet chat, or SSH connections.
  210. Tor belongs to the second category: \emph{low-latency} designs that
  211. try to anonymize interactive network traffic. These systems handle
  212. a variety of bidirectional protocols.
  213. They also provide more convenient
  214. mail delivery than the high-latency anonymous email
  215. networks, because the remote mail server provides explicit and timely
  216. delivery confirmation.
  217. But because these designs typically
  218. involve many packets that must be delivered quickly, it is
  219. difficult for them to prevent an attacker who can eavesdrop both ends of the
  220. communication from correlating the timing and volume
  221. of traffic entering the anonymity network with traffic leaving it. These
  222. protocols are also vulnerable against active attacks in which an
  223. adversary introduces timing patterns into traffic entering the network and
  224. looks
  225. for correlated patterns among exiting traffic.
  226. Although some work has been done to frustrate
  227. these attacks, %\footnote{
  228. % The most common approach is to pad and limit communication to a constant
  229. % rate, or to limit
  230. % the variation in traffic shape. Doing so can have prohibitive bandwidth
  231. % costs and/or performance limitations.
  232. %}
  233. % Point in the footnote is covered above, yes? -PS
  234. most designs protect primarily against traffic analysis rather than traffic
  235. confirmation (cf.\ Section~\ref{subsec:threat-model}).
  236. The simplest low-latency designs are single-hop proxies such as the
  237. {\bf Anonymizer} \cite{anonymizer}, wherein a single trusted server strips the
  238. data's origin before relaying it. These designs are easy to
  239. analyze, but users must trust the anonymizing proxy.
  240. Concentrating the traffic to a single point increases the anonymity set
  241. (the people a given user is hiding among), but it is vulnerable if the
  242. adversary can observe all traffic going into and out of the proxy.
  243. More complex are distributed-trust, circuit-based anonymizing systems.
  244. In these designs, a user establishes one or more medium-term bidirectional
  245. end-to-end circuits, and tunnels data in fixed-size cells.
  246. Establishing circuits is computationally expensive and typically
  247. requires public-key
  248. cryptography, whereas relaying cells is comparatively inexpensive and
  249. typically requires only symmetric encryption.
  250. Because a circuit crosses several servers, and each server only knows
  251. the adjacent servers in the circuit, no single server can link a
  252. user to her communication partners.
  253. The {\bf Java Anon Proxy} (also known as JAP or Web MIXes) uses fixed shared
  254. routes known as \emph{cascades}. As with a single-hop proxy, this
  255. approach aggregates users into larger anonymity sets, but again an
  256. attacker only needs to observe both ends of the cascade to bridge all
  257. the system's traffic. The Java Anon Proxy's design
  258. calls for padding between end users and the head of the cascade
  259. \cite{web-mix}. However, it is not demonstrated whether the current
  260. implementation's padding policy improves anonymity.
  261. {\bf PipeNet} \cite{back01, pipenet}, another low-latency design proposed at
  262. about the same time as Onion Routing, provided
  263. stronger anonymity at the cost of allowing a single user to shut
  264. down the network simply by not sending. Systems like {\bf ISDN mixes}
  265. \cite{isdn-mixes} were designed for other environments with
  266. different assumptions.
  267. In P2P designs like {\bf Tarzan} \cite{tarzan:ccs02} and {\bf MorphMix}
  268. \cite{morphmix:fc04}, all participants both generate traffic and relay
  269. traffic for others. These systems aim to conceal
  270. whether a given peer originated a request
  271. or just relayed it from another peer. While Tarzan and MorphMix use
  272. layered encryption as above, {\bf Crowds} \cite{crowds-tissec} simply assumes
  273. an adversary who cannot observe the initiator: it uses no public-key
  274. encryption, so any node on a circuit can read that circuit's traffic.
  275. {\bf Hordes} \cite{hordes-jcs} is based on Crowds but also uses multicast
  276. responses to hide the initiator. {\bf Herbivore} \cite{herbivore} and
  277. $\mbox{\bf P}^{\mathbf 5}$ \cite{p5} go even further, requiring broadcast.
  278. These systems are designed primarily for communication between peers,
  279. although Herbivore users can make external connections by
  280. requesting a peer to serve as a proxy.
  281. Systems like {\bf Freedom} and the original Onion Routing build the circuit
  282. all at once, using a layered ``onion'' of public-key encrypted messages,
  283. each layer of which provides a set of session keys and the address of the
  284. next server in the circuit. Tor as described herein, Tarzan, MorphMix,
  285. {\bf Cebolla} \cite{cebolla}, and Rennhard's {\bf Anonymity Network} \cite{anonnet}
  286. build the circuit
  287. in stages, extending it one hop at a time.
  288. Section~\ref{subsubsec:constructing-a-circuit} describes how this
  289. approach makes perfect forward secrecy feasible.
  290. Circuit-based anonymity designs must choose which protocol layer
  291. to anonymize. They may choose to intercept IP packets directly, and
  292. relay them whole (stripping the source address) along the circuit
  293. \cite{freedom2-arch,tarzan:ccs02}. Alternatively, like
  294. Tor, they may accept TCP streams and relay the data in those streams
  295. along the circuit, ignoring the breakdown of that data into TCP segments
  296. \cite{morphmix:fc04,anonnet}. Finally, they may accept application-level
  297. protocols (such as HTTP) and relay the application requests themselves
  298. along the circuit.
  299. Making this protocol-layer decision requires a compromise between flexibility
  300. and anonymity. For example, a system that understands HTTP, such as Crowds,
  301. can strip
  302. identifying information from those requests, can take advantage of caching
  303. to limit the number of requests that leave the network, and can batch
  304. or encode those requests in order to minimize the number of connections.
  305. On the other hand, an IP-level anonymizer can handle nearly any protocol,
  306. even ones unforeseen by its designers (though these systems require
  307. kernel-level modifications to some operating systems, and so are more
  308. complex and less portable). TCP-level anonymity networks like Tor present
  309. a middle approach: they are fairly application neutral (so long as the
  310. application supports, or can be tunneled across, TCP), but by treating
  311. application connections as data streams rather than raw TCP packets,
  312. they avoid the well-known inefficiencies of tunneling TCP over TCP
  313. \cite{tcp-over-tcp-is-bad}.
  314. Distributed-trust anonymizing systems need to prevent attackers from
  315. adding too many servers and thus compromising user paths.
  316. Tor relies on a small set of well-known directory servers, run by
  317. independent parties, to decide which nodes can
  318. join. Tarzan and MorphMix allow unknown users to run servers, and use
  319. a limited resource (like IP addresses) to prevent an attacker from
  320. controlling too much of the network. Crowds suggests requiring
  321. written, notarized requests from potential crowd members.
  322. Anonymous communication is essential for censorship-resistant
  323. systems like Eternity \cite{eternity}, Free~Haven \cite{freehaven-berk},
  324. Publius \cite{publius}, and Tangler \cite{tangler}. Tor's rendezvous
  325. points enable connections between mutually anonymous entities; they
  326. are a building block for location-hidden servers, which are needed by
  327. Eternity and Free~Haven.
  328. % didn't include rewebbers. No clear place to put them, so I'll leave
  329. % them out for now. -RD
  330. \Section{Design goals and assumptions}
  331. \label{sec:assumptions}
  332. \noindent{\large\bf Goals}\\
  333. Like other low-latency anonymity designs, Tor seeks to frustrate
  334. attackers from linking communication partners, or from linking
  335. multiple communications to or from a single user. Within this
  336. main goal, however, several considerations have directed
  337. Tor's evolution.
  338. \textbf{Deployability:} The design must be deployed and used in the
  339. real world. Thus it
  340. must not be expensive to run (for example, by requiring more bandwidth
  341. than volunteers are willing to provide); must not place a heavy
  342. liability burden on operators (for example, by allowing attackers to
  343. implicate onion routers in illegal activities); and must not be
  344. difficult or expensive to implement (for example, by requiring kernel
  345. patches, or separate proxies for every protocol). We also cannot
  346. require non-anonymous parties (such as websites)
  347. to run our software. (Our rendezvous point design does not meet
  348. this goal for non-anonymous users talking to hidden servers,
  349. however; see Section~\ref{sec:rendezvous}.)
  350. \textbf{Usability:} A hard-to-use system has fewer users---and because
  351. anonymity systems hide users among users, a system with fewer users
  352. provides less anonymity. Usability is thus not only a convenience:
  353. it is a security requirement \cite{econymics,back01}. Tor should
  354. therefore not
  355. require modifying applications; should not introduce prohibitive delays;
  356. and should require users to make as few configuration decisions
  357. as possible. Finally, Tor should be easily implemented on all common
  358. platforms; we cannot require users to change their operating system in order
  359. to be anonymous. (The current Tor implementation runs on Windows and
  360. assorted Unix clones including Linux, FreeBSD, and MacOS X.)
  361. \textbf{Flexibility:} The protocol must be flexible and well-specified,
  362. so Tor can serve as a test-bed for future research.
  363. Many of the open problems in low-latency anonymity
  364. networks, such as generating dummy traffic or preventing Sybil attacks
  365. \cite{sybil}, may be solvable independently from the issues solved by
  366. Tor. Hopefully future systems will not need to reinvent Tor's design.
  367. (But note that while a flexible design benefits researchers,
  368. there is a danger that differing choices of extensions will make users
  369. distinguishable. Experiments should be run on a separate network.)
  370. \textbf{Simple design:} The protocol's design and security
  371. parameters must be well-understood. Additional features impose implementation
  372. and complexity costs; adding unproven techniques to the design threatens
  373. deployability, readability, and ease of security analysis. Tor aims to
  374. deploy a simple and stable system that integrates the best accepted
  375. approaches to protecting anonymity.\\
  376. \noindent{\large\bf Non-goals}\label{subsec:non-goals}\\
  377. In favoring simple, deployable designs, we have explicitly deferred
  378. several possible goals, either because they are solved elsewhere, or because
  379. they are not yet solved.
  380. \textbf{Not peer-to-peer:} Tarzan and MorphMix aim to scale to completely
  381. decentralized peer-to-peer environments with thousands of short-lived
  382. servers, many of which may be controlled by an adversary. This approach
  383. is appealing, but still has many open problems
  384. \cite{tarzan:ccs02,morphmix:fc04}.
  385. \textbf{Not secure against end-to-end attacks:} Tor does not claim
  386. to provide a definitive solution to end-to-end timing or intersection
  387. attacks. Some approaches, such as running an onion router, may help;
  388. see Section~\ref{sec:maintaining-anonymity} for more discussion.
  389. \textbf{No protocol normalization:} Tor does not provide \emph{protocol
  390. normalization} like Privoxy or the Anonymizer. If anonymization from
  391. the responder is desired for complex and variable
  392. protocols like HTTP, Tor must be layered with a filtering proxy such
  393. as Privoxy to hide differences between clients, and expunge protocol
  394. features that leak identity.
  395. Note that by this separation Tor can also provide services that
  396. are anonymous to the network yet authenticated to the responder, like
  397. SSH. Similarly, Tor does not currently integrate
  398. tunneling for non-stream-based protocols like UDP; this too must be
  399. provided by an external service.
  400. \textbf{Not steganographic:} Tor does not try to conceal who is connected
  401. to the network.
  402. \SubSection{Threat Model}
  403. \label{subsec:threat-model}
  404. A global passive adversary is the most commonly assumed threat when
  405. analyzing theoretical anonymity designs. But like all practical
  406. low-latency systems, Tor does not protect against such a strong
  407. adversary. Instead, we assume an adversary who can observe some fraction
  408. of network traffic; who can generate, modify, delete, or delay
  409. traffic; who can operate onion routers of its own; and who can
  410. compromise some fraction of the onion routers.
  411. In low-latency anonymity systems that use layered encryption, the
  412. adversary's typical goal is to observe both the initiator and the
  413. responder. By observing both ends, passive attackers can confirm a
  414. suspicion that Alice is
  415. talking to Bob if the timing and volume patterns of the traffic on the
  416. connection are distinct enough; active attackers can induce timing
  417. signatures on the traffic to force distinct patterns. Rather
  418. than focusing on these \emph{traffic confirmation} attacks,
  419. we aim to prevent \emph{traffic
  420. analysis} attacks, where the adversary uses traffic patterns to learn
  421. which points in the network he should attack.
  422. Our adversary might try to link an initiator Alice with her
  423. communication partners, or try to build a profile of Alice's
  424. behavior. He might mount passive attacks by observing the network edges
  425. and correlating traffic entering and leaving the network---by
  426. relationships in packet timing, volume, or externally visible
  427. user-selected
  428. options. The adversary can also mount active attacks by compromising
  429. routers or keys; by replaying traffic; by selectively denying service
  430. to trustworthy routers to move users to
  431. compromised routers, or denying service to users to see if traffic
  432. elsewhere in the
  433. network stops; or by introducing patterns into traffic that can later be
  434. detected. The adversary might subvert the directory servers to give users
  435. differing views of network state. Additionally, he can try to decrease
  436. the network's reliability by attacking nodes or by performing antisocial
  437. activities from reliable servers and trying to get them taken down;
  438. making the network unreliable flushes users to other less anonymous
  439. systems, where they may be easier to attack.
  440. We summarize
  441. in Section~\ref{sec:attacks} how well the Tor design defends against
  442. each of these attacks.
  443. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
  444. \Section{The Tor Design}
  445. \label{sec:design}
  446. The Tor network is an overlay network; each onion router (OR)
  447. runs as a normal
  448. user-level process without any special privileges.
  449. Each onion router maintains a long-term TLS \cite{TLS}
  450. connection to every other onion router.
  451. %(We discuss alternatives to this clique-topology assumption in
  452. %Section~\ref{sec:maintaining-anonymity}.)
  453. % A subset of the ORs also act as
  454. %directory servers, tracking which routers are in the network;
  455. %see Section~\ref{subsec:dirservers} for directory server details.
  456. Each user
  457. runs local software called an onion proxy (OP) to fetch directories,
  458. establish circuits across the network,
  459. and handle connections from user applications. These onion proxies accept
  460. TCP streams and multiplex them across the circuits. The onion
  461. router on the other side
  462. of the circuit connects to the destinations of
  463. the TCP streams and relays data.
  464. Each onion router uses three public keys: a long-term identity key, a
  465. short-term onion key, and a short-term link key. The identity
  466. key is used to sign TLS certificates, to sign the OR's \emph{router
  467. descriptor} (a summary of its keys, address, bandwidth, exit policy,
  468. and so on), and (by directory servers) to sign directories. Changing
  469. the identity key of a router is considered equivalent to creating a
  470. new router. The onion key is used to decrypt requests
  471. from users to set up a circuit and negotiate ephemeral keys. Finally,
  472. link keys are used by the TLS protocol when communicating between
  473. onion routers. Each short-term key is rotated periodically and
  474. independently, to limit the impact of key compromise.
  475. Section~\ref{subsec:cells} presents the fixed-size
  476. \emph{cells} that are the unit of communication in Tor. We describe
  477. in Section~\ref{subsec:circuits} how circuits are
  478. built, extended, truncated, and destroyed. Section~\ref{subsec:tcp}
  479. describes how TCP streams are routed through the network. We address
  480. integrity checking in Section~\ref{subsec:integrity-checking},
  481. and resource limiting in Section~\ref{subsec:rate-limit}.
  482. Finally,
  483. Section~\ref{subsec:congestion} talks about congestion control and
  484. fairness issues.
  485. \SubSection{Cells}
  486. \label{subsec:cells}
  487. Onion routers communicate with one another, and with users' OPs, via
  488. TLS connections with ephemeral keys. Using TLS conceals the data on
  489. the connection with perfect forward secrecy, and prevents an attacker
  490. from modifying data on the wire or impersonating an OR.
  491. Traffic passes along these connections in fixed-size cells. Each cell
  492. is 256 bytes (but see Section~\ref{sec:conclusion} for a discussion of
  493. allowing large cells and small cells on the same network), and
  494. consists of a header and a payload. The header includes a circuit
  495. identifier (circID) that specifies which circuit the cell refers to
  496. (many circuits can be multiplexed over the single TLS connection), and
  497. a command to describe what to do with the cell's payload. (Circuit
  498. identifiers are connection-specific: each single circuit has a different
  499. circID on each OP/OR or OR/OR connection it traverses.)
  500. Based on their command, cells are either \emph{control} cells, which are
  501. always interpreted by the node that receives them, or \emph{relay} cells,
  502. which carry end-to-end stream data. The control cell commands are:
  503. \emph{padding} (currently used for keepalive, but also usable for link
  504. padding); \emph{create} or \emph{created} (used to set up a new circuit);
  505. and \emph{destroy} (to tear down a circuit).
  506. Relay cells have an additional header (the relay header) after the
  507. cell header, containing a stream identifier (many streams can
  508. be multiplexed over a circuit); an end-to-end checksum for integrity
  509. checking; the length of the relay payload; and a relay command.
  510. The entire contents of the relay header and the relay cell payload
  511. are encrypted or decrypted together as the relay cell moves along the
  512. circuit, using the 128-bit AES cipher in counter mode to generate a
  513. cipher stream.
  514. The
  515. relay commands are: \emph{relay
  516. data} (for data flowing down the stream), \emph{relay begin} (to open a
  517. stream), \emph{relay end} (to close a stream cleanly), \emph{relay
  518. teardown} (to close a broken stream), \emph{relay connected}
  519. (to notify the OP that a relay begin has succeeded), \emph{relay
  520. extend} and \emph{relay extended} (to extend the circuit by a hop,
  521. and to acknowledge), \emph{relay truncate} and \emph{relay truncated}
  522. (to tear down only part of the circuit, and to acknowledge), \emph{relay
  523. sendme} (used for congestion control), and \emph{relay drop} (used to
  524. implement long-range dummies).
  525. We describe each of these cell types and commands in more detail below.
  526. \SubSection{Circuits and streams}
  527. \label{subsec:circuits}
  528. Onion Routing originally built one circuit for each
  529. TCP stream. Because building a circuit can take several tenths of a
  530. second (due to public-key cryptography and network latency),
  531. this design imposed high costs on applications like web browsing that
  532. open many TCP streams.
  533. In Tor, each circuit can be shared by many TCP streams. To avoid
  534. delays, users construct circuits preemptively. To limit linkability
  535. among their streams, users' OPs build a new circuit
  536. periodically if the previous one has been used,
  537. and expire old used circuits that no longer have any open streams.
  538. OPs consider making a new circuit once a minute: thus
  539. even heavy users spend negligible time
  540. building circuits, but a limited number of requests can be linked
  541. to each other through a given exit node. Also, because circuits are built
  542. in the background, OPs can recover from failed circuit creation
  543. without delaying streams and thereby harming user experience.\\
  544. \noindent{\large\bf Constructing a circuit}\label{subsubsec:constructing-a-circuit}\\
  545. %\subsubsection{Constructing a circuit}
  546. A user's OP constructs circuits incrementally, negotiating a
  547. symmetric key with each OR on the circuit, one hop at a time. To begin
  548. creating a new circuit, the OP (call her Alice) sends a
  549. \emph{create} cell to the first node in her chosen path (call him Bob).
  550. (She chooses a new
  551. circID $C_{AB}$ not currently used on the connection from her to Bob.)
  552. The \emph{create} cell's
  553. payload contains the first half of the Diffie-Hellman handshake
  554. ($g^x$), encrypted to the onion key of the OR (call him Bob). Bob
  555. responds with a \emph{created} cell containing the second half of the
  556. DH handshake, along with a hash of the negotiated key $K=g^{xy}$.
  557. Once the circuit has been established, Alice and Bob can send one
  558. another relay cells encrypted with the negotiated
  559. key.\footnote{Actually, the negotiated key is used to derive two
  560. symmetric keys: one for each direction.} More detail is given in
  561. the next section.
  562. To extend the circuit further, Alice sends a \emph{relay extend} cell
  563. to Bob, specifying the address of the next OR (call her Carol), and
  564. an encrypted $g^{x_2}$ for her. Bob copies the half-handshake into a
  565. \emph{create} cell, and passes it to Carol to extend the circuit.
  566. (Bob chooses a new circID $C_{BC}$ not currently used on the connection
  567. between him and Carol. Alice never needs to know this circID; only Bob
  568. associates $C_{AB}$ on his connection with Alice to $C_{BC}$ on
  569. his connection with Carol.)
  570. When Carol responds with a \emph{created} cell, Bob wraps the payload
  571. into a \emph{relay extended} cell and passes it back to Alice. Now
  572. the circuit is extended to Carol, and Alice and Carol share a common key
  573. $K_2 = g^{x_2 y_2}$.
  574. To extend the circuit to a third node or beyond, Alice
  575. proceeds as above, always telling the last node in the circuit to
  576. extend one hop further.
  577. This circuit-level handshake protocol achieves unilateral entity
  578. authentication (Alice knows she's handshaking with the OR, but
  579. the OR doesn't care who is opening the circuit---Alice uses no public key
  580. and is trying to remain anonymous) and unilateral key authentication
  581. (Alice and the OR agree on a key, and Alice knows only the OR learns
  582. it). It also achieves forward
  583. secrecy and key freshness. More formally, the protocol is as follows
  584. (where $E_{PK_{Bob}}(\cdot)$ is encryption with Bob's public key,
  585. $H$ is a secure hash function, and $|$ is concatenation):
  586. \begin{equation*}
  587. \begin{aligned}
  588. \mathrm{Alice} \rightarrow \mathrm{Bob}&: E_{PK_{Bob}}(g^x) \\
  589. \mathrm{Bob} \rightarrow \mathrm{Alice}&: g^y, H(K | \mathrm{``handshake"}) \\
  590. \end{aligned}
  591. \end{equation*}
  592. \noindent In the second step, Bob proves that it was he who received $g^x$,
  593. and who chose $y$. We use PK encryption in the first step
  594. (rather than, say, using the first two steps of STS, which has a
  595. signature in the second step) because a single cell is too small to
  596. hold both a public key and a signature. Preliminary analysis with the
  597. NRL protocol analyzer \cite{meadows96} shows this protocol to be
  598. secure (including perfect forward secrecy) under the
  599. traditional Dolev-Yao model.\\
  600. \noindent{\large\bf Relay cells}\\
  601. %\subsubsection{Relay cells}
  602. %
  603. Once Alice has established the circuit (so she shares keys with each
  604. OR on the circuit), she can send relay cells. Recall that every relay
  605. cell has a streamID that indicates to which
  606. stream the cell belongs. This streamID allows a relay cell to be
  607. addressed to any OR on the circuit. Upon receiving a relay
  608. cell, an OR looks up the corresponding circuit, and decrypts the relay
  609. header and payload with the session key for that circuit.
  610. If the cell is headed downstream (away from Alice) the OR then checks
  611. whether the decrypted streamID is recognized---either because it
  612. corresponds to an open stream at this OR for the given circuit, or because
  613. it is the control streamID (zero). If the OR recognizes the
  614. streamID, it accepts the relay cell and processes it as described
  615. below. Otherwise,
  616. the OR looks up the circID and OR for the
  617. next step in the circuit, replaces the circID as appropriate, and
  618. sends the decrypted relay cell to the next OR. (If the OR at the end
  619. of the circuit receives an unrecognized relay cell, an error has
  620. occurred, and the cell is discarded.)
  621. OPs treat incoming relay cells similarly: they iteratively unwrap the
  622. relay header and payload with the session keys shared with each
  623. OR on the circuit, from the closest to farthest. (Because we use a
  624. stream cipher, encryption operations may be inverted in any order.)
  625. If at any stage the OP recognizes the streamID, the cell must have
  626. originated at the OR whose encryption has just been removed.
  627. To construct a relay cell addressed to a given OR, Alice iteratively
  628. encrypts the cell payload (that is, the relay header and payload) with
  629. the symmetric key of each hop up to that OR. Because the streamID is
  630. encrypted to a different value at each step, only at the targeted OR
  631. will it have a meaningful value.\footnote{
  632. % Should we just say that 2^56 is itself negligible?
  633. % Assuming 4-hop circuits with 10 streams per hop, there are 33
  634. % possible bad streamIDs before the last circuit. This still
  635. % gives an error only once every 2 million terabytes (approx).
  636. With 56 bits of streamID per cell, the probability of an accidental
  637. collision is far lower than the chance of hardware failure.}
  638. This \emph{leaky pipe} circuit topology
  639. allows Alice's streams to exit at different ORs on a single circuit.
  640. Alice may choose different exit points because of their exit policies,
  641. or to keep the ORs from knowing that two streams
  642. originate from the same person.
  643. When an OR later replies to Alice with a relay cell, it
  644. encrypts the cell's relay header and payload with the single key it
  645. shares with Alice, and sends the cell back toward Alice along the
  646. circuit. Subsequent ORs add further layers of encryption as they
  647. relay the cell back to Alice.
  648. To tear down a whole circuit, Alice sends a \emph{destroy} control
  649. cell. Each OR in the circuit receives the \emph{destroy} cell, closes
  650. all open streams on that circuit, and passes a new \emph{destroy} cell
  651. forward. But just as circuits are built incrementally, they can also
  652. be torn down incrementally: Alice can send a \emph{relay
  653. truncate} cell to a single OR on the circuit. That OR then sends a
  654. \emph{destroy} cell forward, and acknowledges with a
  655. \emph{relay truncated} cell. Alice can then extend the circuit to
  656. different nodes, all without signaling to the intermediate nodes (or
  657. a limited observer) that she has changed her circuit.
  658. Similarly, if a node on the circuit goes down, the adjacent
  659. node can send a \emph{relay truncated} cell back to Alice. Thus the
  660. ``break a node and see which circuits go down'' attack
  661. \cite{freedom21-security} is weakened.
  662. \SubSection{Opening and closing streams}
  663. \label{subsec:tcp}
  664. When Alice's application wants a TCP connection to a given
  665. address and port, it asks the OP (via SOCKS) to make the
  666. connection. The OP chooses the newest open circuit (or creates one if
  667. none is available), and chooses a suitable OR on that circuit to be the
  668. exit node (usually the last node, but maybe others due to exit policy
  669. conflicts; see Section~\ref{subsec:exitpolicies}.) The OP then opens
  670. the stream by sending a \emph{relay begin} cell to the exit node,
  671. using a streamID of zero (so the OR will recognize it), containing as
  672. its relay payload a new randomly generated streamID, the destination
  673. address, and the destination port. Once the
  674. exit node completes the connection to the remote host, it responds
  675. with a \emph{relay connected} cell. Upon receipt, the OP sends a
  676. SOCKS reply to notify the application of its success. The OP
  677. now accepts data from the application's TCP stream, packaging it into
  678. \emph{relay data} cells and sending those cells along the circuit to
  679. the chosen OR.
  680. There's a catch to using SOCKS, however---some applications pass the
  681. alphanumeric hostname to the proxy, while others resolve it into an IP
  682. address first and then pass the IP address to the proxy. If the
  683. application does DNS resolution first, Alice will thereby
  684. reveal her destination to the DNS server. Common applications
  685. like Mozilla and SSH have this flaw.
  686. In the case of Mozilla, the flaw is easy to address: the filtering HTTP
  687. proxy called Privoxy does the SOCKS call safely, and Mozilla talks to
  688. Privoxy safely. But a portable general solution, such as is needed for
  689. SSH, is
  690. an open problem. Modifying or replacing the local nameserver
  691. can be invasive, brittle, and not portable. Forcing the resolver
  692. library to do resolution via TCP rather than UDP is
  693. hard, and also has portability problems. We could also provide a
  694. tool similar to \emph{dig} to perform a private lookup through the
  695. Tor network. Our current answer is to encourage the use of
  696. privacy-aware proxies like Privoxy wherever possible.
  697. Closing a Tor stream is analogous to closing a TCP stream: it uses a
  698. two-step handshake for normal operation, or a one-step handshake for
  699. errors. If the stream closes abnormally, the adjacent node simply sends a
  700. \emph{relay teardown} cell. If the stream closes normally, the node sends
  701. a \emph{relay end} cell down the circuit. When the other side has sent
  702. back its own \emph{relay end} cell, the stream can be torn down. Because
  703. all relay cells use layered encryption, only the destination OR knows
  704. that a given relay cell is a request to close a stream. This two-step
  705. handshake allows Tor to support TCP-based applications that use half-closed
  706. connections.
  707. % such as broken HTTP clients that close their side of the
  708. %stream after writing but are still willing to read.
  709. \SubSection{Integrity checking on streams}
  710. \label{subsec:integrity-checking}
  711. Because the old Onion Routing design used a stream cipher, traffic was
  712. vulnerable to a malleability attack: though the attacker could not
  713. decrypt cells, any changes to encrypted data
  714. would create corresponding changes to the data leaving the network.
  715. (Even an external adversary could do this, despite link encryption, by
  716. inverting bits on the wire.)
  717. This weakness allowed an adversary to change a padding cell to a destroy
  718. cell; change the destination address in a \emph{relay begin} cell to the
  719. adversary's webserver; or change an FTP command from
  720. {\tt dir} to {\tt rm~*}. Any OR or external adversary
  721. along the circuit could introduce such corruption in a stream, if it
  722. knew or could guess the encrypted content.
  723. Tor prevents external adversaries from mounting this attack by
  724. using TLS on its links, which provides integrity checking.
  725. Addressing the insider malleability attack, however, is
  726. more complex.
  727. We could do integrity checking of the relay cells at each hop, either
  728. by including hashes or by using an authenticating cipher mode like
  729. EAX \cite{eax}, but there are some problems. First, these approaches
  730. impose a message-expansion overhead at each hop, and so we would have to
  731. either leak the path length or waste bytes by padding to a maximum
  732. path length. Second, these solutions can only verify traffic coming
  733. from Alice: ORs would not be able to include suitable hashes for
  734. the intermediate hops, since the ORs on a circuit do not know the
  735. other ORs' session keys. Third, we have already accepted that our design
  736. is vulnerable to end-to-end timing attacks; tagging attacks performed
  737. within the circuit provide no additional information to the attacker.
  738. Thus, we check integrity only at the edges of each stream. When Alice
  739. negotiates a key with a new hop, they each initialize a SHA-1
  740. digest with a derivative of that key,
  741. thus beginning with randomness that only the two of them know. From
  742. then on they each incrementally add to the SHA-1 digest the contents of
  743. all relay cells they create, and include with each relay cell the
  744. first four bytes of the current digest. Each also keeps a SHA-1
  745. digest of data received, to verify that the received hashes are correct.
  746. To be sure of removing or modifying a cell, the attacker must be able
  747. to either deduce the current digest state (which depends on all
  748. traffic between Alice and Bob, starting with their negotiated key).
  749. Attacks on SHA-1 where the adversary can incrementally add to a hash
  750. to produce a new valid hash don't work, because all hashes are
  751. end-to-end encrypted across the circuit. The computational overhead
  752. of computing the digests is minimal compared to doing the AES
  753. encryption performed at each hop of the circuit. We use only four
  754. bytes per cell to minimize overhead; the chance that an adversary will
  755. correctly guess a valid hash
  756. %, plus the payload the current cell,
  757. is
  758. acceptably low, given that Alice or Bob tear down the circuit if they
  759. receive a bad hash.
  760. \SubSection{Rate limiting and fairness}
  761. \label{subsec:rate-limit}
  762. Volunteers are generally more willing to run services that can limit
  763. their own bandwidth usage. To accommodate them, Tor servers use a
  764. token bucket approach \cite{tannenbaum96} to
  765. enforce a long-term average rate of incoming bytes, while still
  766. permitting short-term bursts above the allowed bandwidth. Current bucket
  767. sizes are set to ten seconds' worth of traffic.
  768. %Further, we want to avoid starving any Tor streams. Entire circuits
  769. %could starve if we read greedily from connections and one connection
  770. %uses all the remaining bandwidth. We solve this by dividing the number
  771. %of tokens in the bucket by the number of connections that want to read,
  772. %and reading at most that number of bytes from each connection. We iterate
  773. %this procedure until the number of tokens in the bucket is under some
  774. %threshold (currently 10KB), at which point we greedily read from connections.
  775. Because the Tor protocol generates roughly the same number of outgoing
  776. bytes as incoming bytes, it is sufficient in practice to limit only
  777. incoming bytes.
  778. With TCP streams, however, the correspondence is not one-to-one:
  779. relaying a single incoming byte can require an entire 256-byte cell.
  780. (We can't just wait for more bytes, because the local application may
  781. be waiting for a reply.) Therefore, we treat this case as if the entire
  782. cell size had been read, regardless of the fullness of the cell.
  783. Further, inspired by Rennhard et al's design in \cite{anonnet}, a
  784. circuit's edges heuristically distinguish interactive streams from bulk
  785. streams by comparing the frequency with which they supply cells. We can
  786. provide good latency for interactive streams by giving them preferential
  787. service, while still giving good overall throughput to the bulk
  788. streams. Such preferential treatment presents a possible end-to-end
  789. attack, but an adversary observing both
  790. ends of the stream can already learn this information through timing
  791. attacks.
  792. \SubSection{Congestion control}
  793. \label{subsec:congestion}
  794. Even with bandwidth rate limiting, we still need to worry about
  795. congestion, either accidental or intentional. If enough users choose the
  796. same OR-to-OR connection for their circuits, that connection can become
  797. saturated. For example, an attacker could send a large file
  798. through the Tor network to a webserver he runs, and then
  799. refuse to read any of the bytes at the webserver end of the
  800. circuit. Without some congestion control mechanism, these bottlenecks
  801. can propagate back through the entire network. We don't need to
  802. reimplement full TCP windows (with sequence numbers,
  803. the ability to drop cells when we're full and retransmit later, and so
  804. on),
  805. because TCP already guarantees in-order delivery of each
  806. cell.
  807. %But we need to investigate further the effects of the current
  808. %parameters on throughput and latency, while also keeping privacy in mind;
  809. %see Section~\ref{sec:maintaining-anonymity} for more discussion.
  810. We describe our response below.
  811. \textbf{Circuit-level throttling:}
  812. To control a circuit's bandwidth usage, each OR keeps track of two
  813. windows. The \emph{packaging window} tracks how many relay data cells the OR is
  814. allowed to package (from incoming TCP streams) for transmission back to the OP,
  815. and the \emph{delivery window} tracks how many relay data cells it is willing
  816. to deliver to TCP streams outside the network. Each window is initialized
  817. (say, to 1000 data cells). When a data cell is packaged or delivered,
  818. the appropriate window is decremented. When an OR has received enough
  819. data cells (currently 100), it sends a \emph{relay sendme} cell towards the OP,
  820. with streamID zero. When an OR receives a \emph{relay sendme} cell with
  821. streamID zero, it increments its packaging window. Either of these cells
  822. increments the corresponding window by 100. If the packaging window
  823. reaches 0, the OR stops reading from TCP connections for all streams
  824. on the corresponding circuit, and sends no more relay data cells until
  825. receiving a \emph{relay sendme} cell.
  826. The OP behaves identically, except that it must track a packaging window
  827. and a delivery window for every OR in the circuit. If a packaging window
  828. reaches 0, it stops reading from streams destined for that OR.
  829. \textbf{Stream-level throttling}:
  830. The stream-level congestion control mechanism is similar to the
  831. circuit-level mechanism. ORs and OPs use \emph{relay sendme} cells
  832. to implement end-to-end flow control for individual streams across
  833. circuits. Each stream begins with a packaging window (currently 500 cells),
  834. and increments the window by a fixed value (50) upon receiving a \emph{relay
  835. sendme} cell. Rather than always returning a \emph{relay sendme} cell as soon
  836. as enough cells have arrived, the stream-level congestion control also
  837. has to check whether data has been successfully flushed onto the TCP
  838. stream; it sends the \emph{relay sendme} cell only when the number of bytes pending
  839. to be flushed is under some threshold (currently 10 cells' worth).
  840. Currently, non-data relay cells do not affect the windows. Thus we
  841. avoid potential deadlock issues, for example, arising because a stream
  842. can't send a \emph{relay sendme} cell when its packaging window is empty.
  843. These arbitrarily chosen parameters
  844. %are probably not optimal; more
  845. %research remains to find which parameters
  846. seem to give tolerable throughput and delay; more research remains.
  847. \Section{Other design decisions}
  848. \SubSection{Resource management and denial-of-service}
  849. \label{subsec:dos}
  850. Providing Tor as a public service creates many opportunities for
  851. denial-of-service attacks against the network. While
  852. flow control and rate limiting (discussed in
  853. Section~\ref{subsec:congestion}) prevent users from consuming more
  854. bandwidth than routers are willing to provide, opportunities remain for
  855. users to
  856. consume more network resources than their fair share, or to render the
  857. network unusable for others.
  858. First of all, there are several CPU-consuming denial-of-service
  859. attacks wherein an attacker can force an OR to perform expensive
  860. cryptographic operations. For example, an attacker who sends a
  861. \emph{create} cell full of junk bytes can force an OR to perform an RSA
  862. decrypt. Similarly, an attacker can
  863. fake the start of a TLS handshake, forcing the OR to carry out its
  864. (comparatively expensive) half of the handshake at no real computational
  865. cost to the attacker.
  866. Several approaches exist to address these attacks. First, ORs may
  867. require clients to solve a puzzle \cite{puzzles-tls} while beginning new
  868. TLS handshakes or accepting \emph{create} cells. So long as these
  869. tokens are easy to verify and computationally expensive to produce, this
  870. approach limits the attack multiplier. Additionally, ORs may limit
  871. the rate at which they accept create cells and TLS connections, so that
  872. the computational work of processing them does not drown out the (comparatively
  873. inexpensive) work of symmetric cryptography needed to keep cells
  874. flowing. This rate limiting could, however, allow an attacker
  875. to slow down other users when they build new circuits.
  876. % What about link-to-link rate limiting?
  877. Adversaries can also attack the Tor network's hosts and network
  878. links. Disrupting a single circuit or link breaks all streams passing
  879. along that part of the circuit. Indeed, this same loss of service
  880. occurs when a router crashes or its operator restarts it. The current
  881. Tor design treats such attacks as intermittent network failures, and
  882. depends on users and applications to respond or recover as appropriate. A
  883. future design could use an end-to-end TCP-like acknowledgment protocol,
  884. so that no streams are lost unless the entry or exit point itself is
  885. disrupted. This solution would require more buffering at the network
  886. edges, however, and the performance and anonymity implications from this
  887. extra complexity still require investigation.
  888. \SubSection{Exit policies and abuse}
  889. \label{subsec:exitpolicies}
  890. % originally, we planned to put the "users only know the hostname,
  891. % not the IP, but exit policies are by IP" problem here too. Not
  892. % worth putting in the submission, but worth thinking about putting
  893. % in sometime somehow. -RD
  894. Exit abuse is a serious barrier to wide-scale Tor deployment. Anonymity
  895. presents would-be vandals and abusers with an opportunity to hide
  896. the origins of their activities. Attackers can harm the Tor network by
  897. implicating exit servers for their abuse. Also, applications that commonly
  898. use IP-based authentication (such as institutional mail or webservers)
  899. can be fooled by the fact that anonymous connections appear to originate
  900. at the exit OR.
  901. We stress that Tor does not enable any new class of abuse. Spammers
  902. and other attackers already have access to thousands of misconfigured
  903. systems worldwide, and the Tor network is far from the easiest way
  904. to launch antisocial or illegal attacks.
  905. %Indeed, because of its limited
  906. %anonymity, Tor is probably not a good way to commit crimes.
  907. But because the
  908. onion routers can easily be mistaken for the originators of the abuse,
  909. and the volunteers who run them may not want to deal with the hassle of
  910. repeatedly explaining anonymity networks, we must block or limit
  911. the abuse that travels through the Tor network.
  912. To mitigate abuse issues, in Tor, each onion router's \emph{exit policy}
  913. describes to which external addresses and ports the router will
  914. connect. On one end of the spectrum are \emph{open exit}
  915. nodes that will connect anywhere. On the other end are \emph{middleman}
  916. nodes that only relay traffic to other Tor nodes, and \emph{private exit}
  917. nodes that only connect to a local host or network. Using a private
  918. exit (if one exists) is a more secure way for a client to connect to a
  919. given host or network---an external adversary cannot eavesdrop traffic
  920. between the private exit and the final destination, and so is less sure of
  921. Alice's destination and activities. Most onion routers will function as
  922. \emph{restricted exits} that permit connections to the world at large,
  923. but prevent access to certain abuse-prone addresses and services.
  924. Additionally, in some cases the OR can authenticate clients to
  925. prevent exit abuse without harming anonymity \cite{or-discex00}.
  926. %The abuse issues on closed (e.g. military) networks are different
  927. %from the abuse on open networks like the Internet. While these IP-based
  928. %access controls are still commonplace on the Internet, on closed networks,
  929. %nearly all participants will be honest, and end-to-end authentication
  930. %can be assumed for important traffic.
  931. Many administrators will use port restrictions to support only a
  932. limited set of services, such as HTTP, SSH, or AIM.
  933. This is not a complete solution, of course, since abuse opportunities for these
  934. protocols are still well known.
  935. A further solution may be to use proxies to clean traffic for certain
  936. protocols as it leaves the network. For example, much abusive HTTP
  937. behavior (such as exploiting buffer overflows or well-known script
  938. vulnerabilities) can be detected in a straightforward manner.
  939. Similarly, one could run automatic spam filtering software (such as
  940. SpamAssassin) on email exiting the OR network.
  941. ORs may also rewrite exiting traffic to append
  942. headers or other information indicating that the traffic has passed
  943. through an anonymity service. This approach is commonly used
  944. by email-only anonymity systems. ORs can also
  945. run on servers with hostnames like {\tt anonymous} to further
  946. alert abuse targets to the nature of the anonymous traffic.
  947. A mixture of open and restricted exit nodes allows the most
  948. flexibility for volunteers running servers. But while having many
  949. middleman nodes provides a large and robust network,
  950. having only a few exit nodes reduces the number of points
  951. an adversary needs to monitor for traffic analysis, and places a
  952. greater burden on the exit nodes. This tension can be seen in the
  953. Java Anon Proxy
  954. cascade model, wherein only one node in each cascade needs to handle
  955. abuse complaints---but an adversary only needs to observe the entry
  956. and exit of a cascade to perform traffic analysis on all that
  957. cascade's users. The hydra model (many entries, few exits) presents a
  958. different compromise: only a few exit nodes are needed, but an
  959. adversary needs to work harder to watch all the clients; see
  960. Section~\ref{sec:conclusion}.
  961. Finally, we note that exit abuse must not be dismissed as a peripheral
  962. issue: when a system's public image suffers, it can reduce the number
  963. and diversity of that system's users, and thereby reduce the anonymity
  964. of the system itself. Like usability, public perception is a
  965. security parameter. Sadly, preventing abuse of open exit nodes is an
  966. unsolved problem, and will probably remain an arms race for the
  967. forseeable future. The abuse problems faced by Princeton's CoDeeN
  968. project \cite{darkside} give us a glimpse of likely issues.
  969. \SubSection{Directory Servers}
  970. \label{subsec:dirservers}
  971. First-generation Onion Routing designs \cite{freedom2-arch,or-jsac98} used
  972. in-band network status updates: each router flooded a signed statement
  973. to its neighbors, which propagated it onward. But anonymizing networks
  974. have different security goals than typical link-state routing protocols.
  975. For example, delays (accidental or intentional)
  976. that can cause different parts of the network to have different views
  977. of link-state and topology are not only inconvenient: they give
  978. attackers an opportunity to exploit differences in client knowledge.
  979. We also worry about attacks to deceive a
  980. client about the router membership list, topology, or current network
  981. state. Such \emph{partitioning attacks} on client knowledge help an
  982. adversary to efficiently deploy resources
  983. against a target \cite{minion-design}.
  984. Tor uses a small group of redundant, well-known onion routers to
  985. track changes in network topology and node state, including keys and
  986. exit policies. Each such \emph{directory server} acts as an HTTP
  987. server, so participants can fetch current network state and router
  988. lists, and so other ORs can upload
  989. state information. Onion routers periodically publish signed
  990. statements of their state to each directory server. The directory servers
  991. combine this state information with their own views of network liveness,
  992. and generate a signed description (a \emph{directory}) of the entire
  993. network state. Client software is
  994. pre-loaded with a list of the directory servers and their keys,
  995. to bootstrap each client's view of the network.
  996. When a directory server receives a signed statement for an OR, it
  997. checks whether the OR's identity key is recognized. Directory
  998. servers do not automatically advertise unrecognized ORs. (If they did,
  999. an adversary could take over the network by creating many servers
  1000. \cite{sybil}.) Instead, new nodes must be approved by the directory
  1001. server administrator before they are included. Mechanisms for automated
  1002. node approval are an area of active research, and are discussed more
  1003. in Section~\ref{sec:maintaining-anonymity}.
  1004. Of course, a variety of attacks remain. An adversary who controls
  1005. a directory server can track clients by providing them different
  1006. information---perhaps by listing only nodes under its control, or by
  1007. informing only certain clients about a given node. Even an external
  1008. adversary can exploit differences in client knowledge: clients who use
  1009. a node listed on one directory server but not the others are vulnerable.
  1010. Thus these directory servers must be synchronized and redundant, so
  1011. that they can agree on a common directory. Clients should only trust
  1012. this directory if it is signed by a threshold of the directory
  1013. servers.
  1014. The directory servers in Tor are modeled after those in Mixminion
  1015. \cite{minion-design}, but our situation is easier. First, we make the
  1016. simplifying assumption that all participants agree on the set of
  1017. directory servers. Second, while Mixminion needs to predict node
  1018. behavior, Tor only needs a threshold consensus of the current
  1019. state of the network.
  1020. Tor directory servers build a consensus directory through a simple
  1021. four-round broadcast protocol. In round one, each server dates and
  1022. signs its current opinion, and broadcasts it to the other directory
  1023. servers; then in round two, each server rebroadcasts all the signed
  1024. opinions it has received. At this point all directory servers check
  1025. to see whether any server has signed multiple opinions in the same
  1026. period. Such a server is either broken or cheating, so the protocol
  1027. stops and notifies the administrators, who either remove the cheater
  1028. or wait for the broken server to be fixed. If there are no
  1029. discrepancies, each directory server then locally computes an algorithm
  1030. (described below)
  1031. on the set of opinions, resulting in a uniform shared directory. In
  1032. round three servers sign this directory and broadcast it; and finally
  1033. in round four the servers rebroadcast the directory and all the
  1034. signatures. If any directory server drops out of the network, its
  1035. signature is not included on the final directory.
  1036. The rebroadcast steps ensure that a directory server is heard by
  1037. either all of the other servers or none of them, even when some links
  1038. are down (assuming that any two directory servers can talk directly or
  1039. via a third). Broadcasts are feasible because there are relatively few
  1040. directory servers (currently 3, but we expect as many as 9 as the network
  1041. scales). Computing the shared directory locally is a straightforward
  1042. threshold voting process: we include an OR if a majority of directory
  1043. servers believe it to be good.
  1044. To avoid attacks where a router connects to all the directory servers
  1045. but refuses to relay traffic from other routers, the directory servers
  1046. must build circuits and use them to anonymously test router reliability
  1047. \cite{mix-acc}.
  1048. Using directory servers is simpler and more flexible than flooding.
  1049. Flooding is expensive, and complicates the analysis when we
  1050. start experimenting with non-clique network topologies. Signed
  1051. directories are less expensive, because they can be cached by other
  1052. onion routers.
  1053. Thus directory servers are not a performance
  1054. bottleneck when we have many users, and do not aid traffic analysis by
  1055. forcing clients to periodically announce their existence to any
  1056. central point.
  1057. \Section{Rendezvous points and hidden services}
  1058. \label{sec:rendezvous}
  1059. Rendezvous points are a building block for \emph{location-hidden
  1060. services} (also known as \emph{responder anonymity}) in the Tor
  1061. network. Location-hidden services allow Bob to offer a TCP
  1062. service, such as a webserver, without revealing its IP address.
  1063. This type of anonymity protects against distributed DoS attacks:
  1064. attackers are forced to attack the onion routing network as a whole
  1065. rather than just Bob's IP address.
  1066. Our design for location-hidden servers has the following goals.
  1067. \textbf{Access-controlled:} Bob needs a way to filter incoming requests,
  1068. so an attacker cannot flood Bob simply by making many connections to him.
  1069. \textbf{Robust:} Bob should be able to maintain a long-term pseudonymous
  1070. identity even in the presence of router failure. Bob's service must
  1071. not be tied to a single OR, and Bob must be able to tie his service
  1072. to new ORs. \textbf{Smear-resistant:}
  1073. A social attacker who offers an illegal or disreputable location-hidden
  1074. service should not be able to ``frame'' a rendezvous router by
  1075. making observers believe the router created that service.
  1076. %slander-resistant? defamation-resistant?
  1077. \textbf{Application-transparent:} Although we require users
  1078. to run special software to access location-hidden servers, we must not
  1079. require them to modify their applications.
  1080. We provide location-hiding for Bob by allowing him to advertise
  1081. several onion routers (his \emph{introduction points}) as contact
  1082. points. He may do this on any robust efficient
  1083. key-value lookup system with authenticated updates, such as a
  1084. distributed hash table (DHT) like CFS \cite{cfs:sosp01}\footnote{
  1085. Rather than rely on an external infrastructure, the Onion Routing network
  1086. can run the DHT itself. At first, we can run a simple lookup
  1087. system on the
  1088. directory servers.} Alice, the client, chooses an OR as her
  1089. \emph{rendezvous point}. She connects to one of Bob's introduction
  1090. points, informs him of her rendezvous point, and then waits for him
  1091. to connect to the rendezvous point. This extra level of indirection
  1092. helps Bob's introduction points avoid problems associated with serving
  1093. unpopular files directly (for example, if Bob serves
  1094. material that the introduction point's community finds objectionable,
  1095. or if Bob's service tends to get attacked by network vandals).
  1096. The extra level of indirection also allows Bob to respond to some requests
  1097. and ignore others.
  1098. We give an overview of the steps of a rendezvous. These are
  1099. performed on behalf of Alice and Bob by their local OPs;
  1100. application integration is described more fully below.
  1101. \begin{tightlist}
  1102. \item Bob chooses some introduction points, and advertises them on
  1103. the DHT. He can add more later.
  1104. \item Bob builds a circuit to each of his introduction points,
  1105. and waits for requests.
  1106. \item Alice learns about Bob's service out of band (perhaps Bob told her,
  1107. or she found it on a website). She retrieves the details of Bob's
  1108. service from the DHT.
  1109. \item Alice chooses an OR to be the rendezvous point (RP) for this
  1110. transaction. She builds a circuit to RP, and gives it a
  1111. rendezvous cookie that it will use to recognize Bob.
  1112. \item Alice opens an anonymous stream to one of Bob's introduction
  1113. points, and gives it a message (encrypted to Bob's public key)
  1114. which tells him
  1115. about herself, her chosen RP and the rendezvous cookie, and the
  1116. first half of a DH
  1117. handshake. The introduction point sends the message to Bob.
  1118. \item If Bob wants to talk to Alice, he builds a circuit to Alice's
  1119. RP and sends the rendezvous cookie, the second half of the DH
  1120. handshake, and a hash of the session
  1121. key they now share. By the same argument as in
  1122. Section~\ref{subsubsec:constructing-a-circuit}, Alice knows she
  1123. shares the key only with Bob.
  1124. \item The RP connects Alice's circuit to Bob's. Note that RP can't
  1125. recognize Alice, Bob, or the data they transmit.
  1126. \item Alice now sends a \emph{relay begin} cell along the circuit. It
  1127. arrives at Bob's onion proxy. Bob's onion proxy connects to Bob's
  1128. webserver.
  1129. \item An anonymous stream has been established, and Alice and Bob
  1130. communicate as normal.
  1131. \end{tightlist}
  1132. When establishing an introduction point, Bob provides the onion router
  1133. with a public ``introduction'' key. The hash of this public key
  1134. identifies a unique service, and (since Bob is required to sign his
  1135. messages) prevents anybody else from usurping Bob's introduction point
  1136. in the future. Bob uses the same public key when establishing the other
  1137. introduction points for that service. Bob periodically refreshes his
  1138. entry in the DHT.
  1139. The message that Alice gives
  1140. the introduction point includes a hash of Bob's public key to identify
  1141. the service, along with an optional initial authorization token (the
  1142. introduction point can do prescreening, for example to block replays). Her
  1143. message to Bob may include an end-to-end authorization token so Bob
  1144. can choose whether to respond.
  1145. The authorization tokens can be used to provide selective access:
  1146. important users get tokens to ensure uninterrupted access to the
  1147. service. During normal situations, Bob's service might simply be offered
  1148. directly from mirrors, while Bob gives out tokens to high-priority users. If
  1149. the mirrors are knocked down,
  1150. %by distributed DoS attacks or even
  1151. %physical attack,
  1152. those users can switch to accessing Bob's service via
  1153. the Tor rendezvous system.
  1154. Since Bob's introduction points might themselves be subject to DoS he
  1155. could have to choose between keeping many
  1156. introduction connections open or risking such an attack. In this case,
  1157. he can provide selected users
  1158. with a current list and/or future schedule of introduction points that
  1159. are not advertised in the DHT\@. This is most likely to be practical
  1160. if there is a relatively stable and large group of introduction points
  1161. available. Alternatively, Bob could give secret public keys
  1162. to selected users for consulting the DHT\@. All of these approaches
  1163. have the advantage of limiting exposure even when
  1164. some of the selected high-priority users collude in the DoS\@.
  1165. \SubSection{Integration with user applications}
  1166. Bob configures his onion proxy to know the local IP address and port of his
  1167. service, a strategy for authorizing clients, and a public key. Bob
  1168. publishes the public key, an expiration time (``not valid after''), and
  1169. the current introduction points for his service into the DHT, indexed
  1170. by the hash of the public key. Bob's webserver is unmodified,
  1171. and doesn't even know that it's hidden behind the Tor network.
  1172. Alice's applications also work unchanged---her client interface
  1173. remains a SOCKS proxy. We encode all of the necessary information
  1174. into the fully qualified domain name Alice uses when establishing her
  1175. connection. Location-hidden services use a virtual top level domain
  1176. called {\tt .onion}: thus hostnames take the form {\tt x.y.onion} where
  1177. {\tt x} is the authorization cookie, and {\tt y} encodes the hash of
  1178. the public key. Alice's onion proxy
  1179. examines addresses; if they're destined for a hidden server, it decodes
  1180. the key and starts the rendezvous as described above.
  1181. \subsection{Previous rendezvous work}
  1182. Rendezvous points in low-latency anonymity systems were first
  1183. described for use in ISDN telephony \cite{isdn-mixes,jerichow-jsac98}.
  1184. Later low-latency designs used rendezvous points for hiding location
  1185. of mobile phones and low-power location trackers
  1186. \cite{federrath-ih96,reed-protocols97}. Rendezvous for low-latency
  1187. Internet connections was suggested in early Onion Routing work
  1188. \cite{or-ih96}; however, the first published design of rendezvous
  1189. points for low-latency Internet connections was by Ian Goldberg
  1190. \cite{ian-thesis}. His design differs from
  1191. ours in three ways. First, Goldberg suggests that Alice should manually
  1192. hunt down a current location of the service via Gnutella; our approach
  1193. makes lookup transparent to the user, as well as faster and more robust.
  1194. Second, in Tor the client and server negotiate session keys
  1195. via Diffie-Hellman, so plaintext is not exposed even at the rendezvous point. Third,
  1196. our design tries to minimize the exposure associated with running the
  1197. service, to encourage volunteers to offer introduction and rendezvous
  1198. point services. Tor's introduction points do not output any bytes to the
  1199. clients, and the rendezvous points don't know the client or the server,
  1200. and can't read the data being transmitted. The indirection scheme is
  1201. also designed to include authentication/authorization---if Alice doesn't
  1202. include the right cookie with her request for service, Bob need not even
  1203. acknowledge his existence.
  1204. \Section{Attacks and Defenses}
  1205. \label{sec:attacks}
  1206. Below we summarize a variety of attacks, and discuss how well our
  1207. design withstands them.\\
  1208. \noindent{\large\bf Passive attacks}\\
  1209. \emph{Observing user traffic patterns.} Observing a user's connection
  1210. will not reveal her destination or data, but it will
  1211. reveal traffic patterns (both sent and received). Profiling via user
  1212. connection patterns requires further processing, because multiple
  1213. application streams may be operating simultaneously or in series over
  1214. a single circuit.
  1215. \emph{Observing user content.} While content at the user end is encrypted,
  1216. connections to responders may not be (indeed, the responding website
  1217. itself may be hostile). While filtering content is not a primary goal
  1218. of Onion Routing, Tor can directly use Privoxy and related
  1219. filtering services to anonymize application data streams.
  1220. \emph{Option distinguishability.} We allow clients to choose local
  1221. configuration options. For example, clients concerned about request
  1222. linkability should rotate circuits more often than those concerned
  1223. about traceability. There is economic incentive to attract users by
  1224. allowing this choice; but at the same time, a set of clients who are
  1225. in the minority may lose more anonymity by appearing distinct than they
  1226. gain by optimizing their behavior \cite{econymics}.
  1227. \emph{End-to-end timing correlation.} Tor only minimally hides
  1228. such correlations. An attacker watching patterns of
  1229. traffic at the initiator and the responder will be
  1230. able to confirm the correspondence with high probability. The
  1231. greatest protection currently available against such confirmation is to hide
  1232. the connection between the onion proxy and the first Tor node,
  1233. by running the OP on the Tor node or behind a firewall. This approach
  1234. requires an observer to separate traffic originating at the onion
  1235. router from traffic passing through it: a global observer can do this,
  1236. but it might be beyond a limited observer's capabilities.
  1237. \emph{End-to-end size correlation.} Simple packet counting
  1238. will also be effective in confirming
  1239. endpoints of a stream. However, even without padding, we have some
  1240. limited protection: the leaky pipe topology means different numbers
  1241. of packets may enter one end of a circuit than exit at the other.
  1242. \emph{Website fingerprinting.} All the effective passive
  1243. attacks above are traffic confirmation attacks,
  1244. which puts them outside our design goals. There is also
  1245. a passive traffic analysis attack that is potentially effective.
  1246. Rather than searching exit connections for timing and volume
  1247. correlations, the adversary may build up a database of
  1248. ``fingerprints'' containing file sizes and access patterns for
  1249. targeted websites. He can later confirm a user's connection to a given
  1250. site simply by consulting the database. This attack has
  1251. been shown to be effective against SafeWeb \cite{hintz-pet02}.
  1252. It may be less effective against Tor, since
  1253. streams are multiplexed within the same circuit, and
  1254. fingerprinting will be limited to
  1255. the granularity of cells (currently 256 bytes). Additional
  1256. defenses could include
  1257. larger cell sizes, padding schemes to group websites
  1258. into large sets, and link
  1259. padding or long-range dummies.\footnote{Note that this fingerprinting
  1260. attack should not be confused with the much more complicated latency
  1261. attacks of \cite{back01}, which require a fingerprint of the latencies
  1262. of all circuits through the network, combined with those from the
  1263. network edges to the target user and the responder website.}\\
  1264. \noindent{\large\bf Active attacks}\\
  1265. \emph{Compromise keys.} An attacker who learns the TLS session key can
  1266. see control cells and encrypted relay cells on every circuit on that
  1267. connection; learning a circuit
  1268. session key lets him unwrap one layer of the encryption. An attacker
  1269. who learns an OR's TLS private key can impersonate that OR for the TLS
  1270. key's lifetime, but he must
  1271. also learn the onion key to decrypt \emph{create} cells (and because of
  1272. perfect forward secrecy, he cannot hijack already established circuits
  1273. without also compromising their session keys). Periodic key rotation
  1274. limits the window of opportunity for these attacks. On the other hand,
  1275. an attacker who learns a node's identity key can replace that node
  1276. indefinitely by sending new forged descriptors to the directory servers.
  1277. \emph{Iterated compromise.} A roving adversary who can
  1278. compromise ORs (by system intrusion, legal coercion, or extralegal
  1279. coercion) could march down the circuit compromising the
  1280. nodes until he reaches the end. Unless the adversary can complete
  1281. this attack within the lifetime of the circuit, however, the ORs
  1282. will have discarded the necessary information before the attack can
  1283. be completed. (Thanks to the perfect forward secrecy of session
  1284. keys, the attacker cannot force nodes to decrypt recorded
  1285. traffic once the circuits have been closed.) Additionally, building
  1286. circuits that cross jurisdictions can make legal coercion
  1287. harder---this phenomenon is commonly called ``jurisdictional
  1288. arbitrage.'' The Java Anon Proxy project recently experienced the
  1289. need for this approach, when
  1290. a German court forced them to add a backdoor to
  1291. all of their nodes \cite{jap-backdoor}.
  1292. \emph{Run a recipient.} An adversary running a webserver
  1293. trivially learns the timing patterns of users connecting to it, and
  1294. can introduce arbitrary patterns in its responses.
  1295. End-to-end attacks become easier: if the adversary can induce
  1296. users to connect to his webserver (perhaps by advertising
  1297. content targeted to those users), she now holds one end of their
  1298. connection. There is also a danger that application
  1299. protocols and associated programs can be induced to reveal information
  1300. about the initiator. Tor depends on Privoxy and similar protocol cleaners
  1301. to solve this latter problem.
  1302. \emph{Run an onion proxy.} It is expected that end users will
  1303. nearly always run their own local onion proxy. However, in some
  1304. settings, it may be necessary for the proxy to run
  1305. remotely---typically, in institutions that want
  1306. to monitor the activity of those connecting to the proxy.
  1307. Compromising an onion proxy compromises all future connections
  1308. through it.
  1309. \emph{DoS non-observed nodes.} An observer who can only watch some
  1310. of the Tor network can increase the value of this traffic
  1311. by attacking non-observed nodes to shut them down, reduce
  1312. their reliability, or persuade users that they are not trustworthy.
  1313. The best defense here is robustness.
  1314. \emph{Run a hostile OR.} In addition to being a local observer,
  1315. an isolated hostile node can create circuits through itself, or alter
  1316. traffic patterns to affect traffic at other nodes. Nonetheless, a hostile
  1317. node must be immediately adjacent to both endpoints to compromise the
  1318. anonymity of a circuit. If an adversary can
  1319. run multiple ORs, and can persuade the directory servers
  1320. that those ORs are trustworthy and independent, then occasionally
  1321. some user will choose one of those ORs for the start and another
  1322. as the end of a circuit. If an adversary
  1323. controls $m>1$ out of $N$ nodes, he should be able to correlate at most
  1324. $\left(\frac{m}{N}\right)^2$ of the traffic in this way---although an
  1325. adversary
  1326. could possibly attract a disproportionately large amount of traffic
  1327. by running an OR with an unusually permissive exit policy, or by
  1328. degrading the reliability of other routers.
  1329. \emph{Introduce timing into messages.} This is simply a stronger
  1330. version of passive timing attacks already discussed earlier.
  1331. \emph{Tagging attacks.} A hostile node could ``tag'' a
  1332. cell by altering it. If the
  1333. stream were, for example, an unencrypted request to a Web site,
  1334. the garbled content coming out at the appropriate time would confirm
  1335. the association. However, integrity checks on cells prevent
  1336. this attack.
  1337. \emph{Replace contents of unauthenticated protocols.} When
  1338. relaying an unauthenticated protocol like HTTP, a hostile exit node
  1339. can impersonate the target server. Clients
  1340. should prefer protocols with end-to-end authentication.
  1341. \emph{Replay attacks.} Some anonymity protocols are vulnerable
  1342. to replay attacks. Tor is not; replaying one side of a handshake
  1343. will result in a different negotiated session key, and so the rest
  1344. of the recorded session can't be used.
  1345. \emph{Smear attacks.} An attacker could use the Tor network for
  1346. socially disapproved acts, to bring the
  1347. network into disrepute and get its operators to shut it down.
  1348. Exit policies reduce the possibilities for abuse, but
  1349. ultimately the network will require volunteers who can tolerate
  1350. some political heat.
  1351. \emph{Distribute hostile code.} An attacker could trick users
  1352. into running subverted Tor software that did not, in fact, anonymize
  1353. their connections---or worse, could trick ORs into running weakened
  1354. software that provided users with less anonymity. We address this
  1355. problem (but do not solve it completely) by signing all Tor releases
  1356. with an official public key, and including an entry in the directory
  1357. that lists which versions are currently believed to be secure. To
  1358. prevent an attacker from subverting the official release itself
  1359. (through threats, bribery, or insider attacks), we provide all
  1360. releases in source code form, encourage source audits, and
  1361. frequently warn our users never to trust any software (even from
  1362. us) that comes without source.\\
  1363. \noindent{\large\bf Directory attacks}\\
  1364. \emph{Destroy directory servers.} If a few directory
  1365. servers disappear, the others still decide on a valid
  1366. directory. So long as any directory servers remain in operation,
  1367. they will still broadcast their views of the network and generate a
  1368. consensus directory. (If more than half are destroyed, this
  1369. directory will not, however, have enough signatures for clients to
  1370. use it automatically; human intervention will be necessary for
  1371. clients to decide whether to trust the resulting directory.)
  1372. \emph{Subvert a directory server.} By taking over a directory server,
  1373. an attacker can partially influence the final directory. Since ORs
  1374. are included or excluded by majority vote, the corrupt directory can
  1375. at worst cast a tie-breaking vote to decide whether to include
  1376. marginal ORs. It remains to be seen how often such marginal cases
  1377. occur in practice.
  1378. \emph{Subvert a majority of directory servers.} An adversary who controls
  1379. more than half the directory servers can include as many compromised
  1380. ORs in the final directory as he wishes. We must ensure that directory
  1381. server operators are independent and attack-resistant.
  1382. \emph{Encourage directory server dissent.} The directory
  1383. agreement protocol assumes that directory server operators agree on
  1384. the set of directory servers. An adversary who can persuade some
  1385. of the directory server operators to distrust one another could
  1386. split the quorum into mutually hostile camps, thus partitioning
  1387. users based on which directory they use. Tor does not address
  1388. this attack.
  1389. \emph{Trick the directory servers into listing a hostile OR.}
  1390. Our threat model explicitly assumes directory server operators will
  1391. be able to filter out most hostile ORs.
  1392. % If this is not true, an
  1393. % attacker can flood the directory with compromised servers.
  1394. \emph{Convince the directories that a malfunctioning OR is
  1395. working.} In the current Tor implementation, directory servers
  1396. assume that an OR is running correctly if they can start a TLS
  1397. connection to it. A hostile OR could easily subvert this test by
  1398. accepting TLS connections from ORs but ignoring all cells. Directory
  1399. servers must actively test ORs by building circuits and streams as
  1400. appropriate. The tradeoffs of a similar approach are discussed in
  1401. \cite{mix-acc}.\\
  1402. \noindent{\large\bf Attacks against rendezvous points}\\
  1403. \emph{Make many introduction requests.} An attacker could
  1404. try to deny Bob service by flooding his introduction points with
  1405. requests. Because the introduction points can block requests that
  1406. lack authorization tokens, however, Bob can restrict the volume of
  1407. requests he receives, or require a certain amount of computation for
  1408. every request he receives.
  1409. \emph{Attack an introduction point.} An attacker could
  1410. disrupt a location-hidden service by disabling its introduction
  1411. points. But because a service's identity is attached to its public
  1412. key, not its introduction point, the service can simply re-advertise
  1413. itself at a different introduction point. Advertisements can also be
  1414. done secretly so that only high-priority clients know the address of
  1415. Bob's introduction points, forcing the attacker to disable all possible
  1416. introduction points.
  1417. \emph{Compromise an introduction point.} An attacker who controls
  1418. Bob's introduction point can flood Bob with
  1419. introduction requests, or prevent valid introduction requests from
  1420. reaching him. Bob can notice a flood, and close the circuit. To notice
  1421. blocking of valid requests, however, he should periodically test the
  1422. introduction point by sending rendezvous requests and making
  1423. sure he receives them.
  1424. \emph{Compromise a rendezvous point.} A rendezvous
  1425. point is no more sensitive than any other OR on
  1426. a circuit, since all data passing through the rendezvous is encrypted
  1427. with a session key shared by Alice and Bob.
  1428. \Section{Open Questions in Low-latency Anonymity}
  1429. \label{sec:maintaining-anonymity}
  1430. In addition to the non-goals in
  1431. Section~\ref{subsec:non-goals}, many other questions must be solved
  1432. before we can be confident of Tor's security.
  1433. Many of these open issues are questions of balance. For example,
  1434. how often should users rotate to fresh circuits? Frequent rotation
  1435. is inefficient, expensive, and may lead to intersection attacks and
  1436. predecessor attacks \cite{wright03}, but infrequent rotation makes the
  1437. user's traffic linkable. Besides opening fresh circuits, clients can
  1438. also exit from the middle of the circuit,
  1439. or truncate and re-extend the circuit. More analysis is
  1440. needed to determine the proper tradeoff.
  1441. %% Duplicated by 'Better directory distribution' in section 9.
  1442. %
  1443. %A similar question surrounds timing of directory operations: how often
  1444. %should directories be updated? Clients that update infrequently receive
  1445. %an inaccurate picture of the network, but frequent updates can overload
  1446. %the directory servers. More generally, we must find more
  1447. %decentralized yet practical ways to distribute up-to-date snapshots of
  1448. %network status without introducing new attacks.
  1449. How should we choose path lengths? If Alice only ever uses two hops,
  1450. then both ORs can be certain that by colluding they will learn about
  1451. Alice and Bob. In our current approach, Alice always chooses at least
  1452. three nodes unrelated to herself and her destination.
  1453. %% This point is subtle, but not IMO necessary. Anybody who thinks
  1454. %% about it will see that it's implied by the above sentence; anybody
  1455. %% who doesn't think about it is safe in his ignorance.
  1456. %
  1457. %Thus normally she chooses
  1458. %three nodes, but if she is running an OR and her destination is on an OR,
  1459. %she uses five.
  1460. Should Alice choose a nondeterministic path length (say,
  1461. increasing it from a geometric distribution) to foil an attacker who
  1462. uses timing to learn that he is the fifth hop and thus concludes that
  1463. both Alice and the responder are on ORs?
  1464. Throughout this paper, we have assumed that end-to-end traffic
  1465. confirmation will immediately and automatically defeat a low-latency
  1466. anonymity system. Even high-latency anonymity systems can be
  1467. vulnerable to end-to-end traffic confirmation, if the traffic volumes
  1468. are high enough, and if users' habits are sufficiently distinct
  1469. \cite{limits-open,statistical-disclosure}. Can anything be done to
  1470. make low-latency systems resist these attacks as well as high-latency
  1471. systems? Tor already makes some effort to conceal the starts and ends of
  1472. streams by wrapping long-range control commands in identical-looking
  1473. relay cells. Link padding could frustrate passive observers who count
  1474. packets; long-range padding could work against observers who own the
  1475. first hop in a circuit. But more research remains to find an efficient
  1476. and practical approach. Volunteers prefer not to run constant-bandwidth
  1477. padding; but no convincing traffic shaping approach has been
  1478. specified. Recent work on long-range padding \cite{defensive-dropping}
  1479. shows promise. One could also try to reduce correlation in packet timing
  1480. by batching and re-ordering packets, but it is unclear whether this could
  1481. improve anonymity without introducing so much latency as to render the
  1482. network unusable.
  1483. A cascade topology may better defend against traffic confirmation by
  1484. aggregating users, and making padding and
  1485. mixing more affordable. Does the hydra topology (many input nodes,
  1486. few output nodes) work better against some adversaries? Are we going
  1487. to get a hydra anyway because most nodes will be middleman nodes?
  1488. Common wisdom suggests that Alice should run her own OR for best
  1489. anonymity, because traffic coming from her node could plausibly have
  1490. come from elsewhere. How much mixing does this approach need? Is it
  1491. immediately beneficial because of real-world adversaries that can't
  1492. observe Alice's router, but can run routers of their own?
  1493. To scale to many users, and to prevent an attacker from observing the
  1494. whole network at once, it may be necessary
  1495. to support far more servers than Tor currently anticipates.
  1496. This introduces several issues. First, if approval by a centralized set
  1497. of directory servers is no longer feasible, what mechanism should be used
  1498. to prevent adversaries from signing up many colluding servers? Second,
  1499. if clients can no longer have a complete picture of the network at all
  1500. times, how can they perform discovery while preventing attackers from
  1501. manipulating or exploiting gaps in their knowledge? Third, if there
  1502. are too many servers for every server to constantly communicate with
  1503. every other, what kind of non-clique topology should the network use?
  1504. (Restricted-route topologies promise comparable anonymity with better
  1505. scalability \cite{danezis-pets03}, but whatever topology we choose, we
  1506. need some way to keep attackers from manipulating their position within
  1507. it \cite{casc-rep}.) Fourth, since no centralized authority is tracking
  1508. server reliability, how do we prevent unreliable servers from rendering
  1509. the network unusable? Fifth, do clients receive so much anonymity benefit
  1510. from running their own servers that we should expect them all to do so
  1511. \cite{econymics}, or do we need to find another incentive structure to
  1512. motivate them? Tarzan and MorphMix present possible solutions.
  1513. % advogato, captcha
  1514. When a Tor node goes down, all its circuits (and thus streams) must break.
  1515. Will users abandon the system because of this brittleness? How well
  1516. does the method in Section~\ref{subsec:dos} allow streams to survive
  1517. node failure? If affected users rebuild circuits immediately, how much
  1518. anonymity is lost? It seems the problem is even worse in a peer-to-peer
  1519. environment---such systems don't yet provide an incentive for peers to
  1520. stay connected when they're done retrieving content, so we would expect
  1521. a higher churn rate.
  1522. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
  1523. \Section{Future Directions}
  1524. \label{sec:conclusion}
  1525. Tor brings together many innovations into a unified deployable system. The
  1526. next immediate steps include:
  1527. \emph{Scalability:} Tor's emphasis on deployability and design simplicity
  1528. has led us to adopt a clique topology, semi-centralized
  1529. directories, and a full-network-visibility model for client
  1530. knowledge. These properties will not scale past a few hundred servers.
  1531. Section~\ref{sec:maintaining-anonymity} describes some promising
  1532. approaches, but more deployment experience will be helpful in learning
  1533. the relative importance of these bottlenecks.
  1534. \emph{Bandwidth classes:} This paper assumes that all ORs have
  1535. good bandwidth and latency. We should instead adopt the Morphmix model,
  1536. where nodes advertise their bandwidth level (DSL, T1, T3), and
  1537. Alice avoids bottlenecks by choosing nodes that match or
  1538. exceed her bandwidth. In this way DSL users can usefully join the Tor
  1539. network.
  1540. \emph{Incentives:} Volunteers who run nodes are rewarded with publicity
  1541. and possibly better anonymity \cite{econymics}. More nodes means increased
  1542. scalability, and more users can mean more anonymity. We need to continue
  1543. examining the incentive structures for participating in Tor.
  1544. \emph{Cover traffic:} Currently Tor omits cover traffic---its costs
  1545. in performance and bandwidth are clear but its security benefits are
  1546. not well understood. We must pursue more research on link-level cover
  1547. traffic and long-range cover traffic to determine whether some simple padding
  1548. method offers provable protection against our chosen adversary.
  1549. %%\emph{Offer two relay cell sizes:} Traffic on the Internet tends to be
  1550. %%large for bulk transfers and small for interactive traffic. One cell
  1551. %%size cannot be optimal for both types of traffic.
  1552. % This should go in the spec and todo, but not the paper yet. -RD
  1553. \emph{Caching at exit nodes:} Perhaps each exit node should run a
  1554. caching web proxy, to improve anonymity for cached pages (Alice's request never
  1555. leaves the Tor network), to improve speed, and to reduce bandwidth cost.
  1556. On the other hand, forward security is weakened because caches
  1557. constitute a record of retrieved files. We must find the right
  1558. balance between usability and security.
  1559. \emph{Better directory distribution:}
  1560. Clients currently download a description of
  1561. the entire network every 15 minutes. As the state grows larger
  1562. and clients more numerous, we may need a solution in which
  1563. clients receive incremental updates to directory state.
  1564. More generally, we must find more
  1565. scalable yet practical ways to distribute up-to-date snapshots of
  1566. network status without introducing new attacks.
  1567. \emph{Implement location-hidden services:} The design in
  1568. Section~\ref{sec:rendezvous} has not yet been implemented. While doing
  1569. so we are likely to encounter additional issues that must be resolved,
  1570. both in terms of usability and anonymity.
  1571. \emph{Further specification review:} Although have a public
  1572. byte-level specification for the Tor protocols, it needs
  1573. extensive external review. We hope that as Tor
  1574. is more widely deployed, more people will examine its
  1575. specification.
  1576. \emph{Multisystem interoperability:} We are currently working with the
  1577. designer of MorphMix to unify the specification and implementation of
  1578. the common elements of our two systems. So far, this seems
  1579. to be relatively straightforward. Interoperability will allow testing
  1580. and direct comparison of the two designs for trust and scalability.
  1581. \emph{Wider-scale deployment:} The original goal of Tor was to
  1582. gain experience in deploying an anonymizing overlay network, and
  1583. learn from having actual users. We are now at a point in design
  1584. and development where we can start deploying a wider network. Once
  1585. we have many actual users, we will doubtlessly be better
  1586. able to evaluate some of our design decisions, including our
  1587. robustness/latency tradeoffs, our performance tradeoffs (including
  1588. cell size), our abuse-prevention mechanisms, and
  1589. our overall usability.
  1590. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
  1591. %% commented out for anonymous submission
  1592. \section*{Acknowledgments}
  1593. Peter Palfrader, Geoff Goodell, Adam Shostack, Joseph Sokol-Margolis,
  1594. John Bashinski, Zack Brown:
  1595. for editing and comments.
  1596. Matej Pfajfar, Andrei Serjantov, Marc Rennhard: for design discussions.
  1597. Bram Cohen for congestion control discussions.
  1598. Adam Back for suggesting telescoping circuits.
  1599. Cathy Meadows for formal analysis of the extend protocol.
  1600. This work supported by ONR and DARPA.
  1601. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
  1602. \bibliographystyle{latex8}
  1603. \bibliography{tor-design}
  1604. \end{document}
  1605. % Style guide:
  1606. % U.S. spelling
  1607. % avoid contractions (it's, can't, etc.)
  1608. % prefer ``for example'' or ``such as'' to e.g.
  1609. % prefer ``that is'' to i.e.
  1610. % 'mix', 'mixes' (as noun)
  1611. % 'mix-net'
  1612. % 'mix', 'mixing' (as verb)
  1613. % 'middleman' [Not with a hyphen; the hyphen has been optional
  1614. % since Middle English.]
  1615. % 'nymserver'
  1616. % 'Cypherpunk', 'Cypherpunks', 'Cypherpunk remailer'
  1617. % 'Onion Routing design', 'onion router' [note capitalization]
  1618. % 'SOCKS'
  1619. % Try not to use \cite as a noun.
  1620. % 'Authorizating' sounds great, but it isn't a word.
  1621. % 'First, second, third', not 'Firstly, secondly, thirdly'.
  1622. % 'circuit', not 'channel'
  1623. % Typography: no space on either side of an em dash---ever.
  1624. % Hyphens are for multi-part words; en dashs imply movement or
  1625. % opposition (The Alice--Bob connection); and em dashes are
  1626. % for punctuation---like that.
  1627. % A relay cell; a control cell; a \emph{create} cell; a
  1628. % \emph{relay truncated} cell. Never ``a \emph{relay truncated}.''
  1629. %
  1630. % 'Substitute ``Damn'' every time you're inclined to write ``very;'' your
  1631. % editor will delete it and the writing will be just as it should be.'
  1632. % -- Mark Twain