| blob | 66d464dc289e36843f12d88f2d6c16d0fdb81e2c |
4 <head>
18 </head>
19 <body>
34 We present Tor, a circuit-based low-latency anonymous communication
35 service. This second-generation Onion Routing system addresses limitations
36 in the original design by adding perfect forward secrecy, congestion
37 control, directory servers, integrity checking, configurable exit policies,
38 and a practical design for location-hidden services via rendezvous
39 points. Tor works on the real-world
40 Internet, requires no special privileges or kernel modifications, requires
41 little synchronization or coordination between nodes, and provides a
42 reasonable tradeoff between anonymity, usability, and efficiency.
43 We briefly describe our experiences with an international network of
44 more than 30 nodes. We close with a list of open problems in anonymous communication.
54 </a>
57 Onion Routing is a distributed overlay network designed to anonymize
58 TCP-based applications like web browsing, secure shell,
59 and instant messaging. Clients choose a path through the network and
61 in the path knows its predecessor and successor, but no other nodes in
62 the circuit. Traffic flows down the circuit in fixed-size
64 (like the layers of an onion) and relayed downstream. The
65 Onion Routing project published several design and analysis
66 papers [<a href="#or-ih96" name="CITEor-ih96">27</a>,<a href="#or-jsac98" name="CITEor-jsac98">41</a>,<a href="#or-discex00" name="CITEor-discex00">48</a>,<a href="#or-pet00" name="CITEor-pet00">49</a>]. While a wide area Onion
67 Routing network was deployed briefly, the only long-running
68 public implementation was a fragile
69 proof-of-concept that ran on a single machine. Even this simple deployment
70 processed connections from over sixty thousand distinct IP addresses from
71 all over the world at a rate of about fifty thousand per day.
72 But many critical design and deployment issues were never
73 resolved, and the design has not been updated in years. Here
74 we describe Tor, a protocol for asynchronous, loosely federated onion
75 routers that provides the following improvements over the old Onion
76 Routing design:
80 a single hostile node could record traffic and
81 later compromise successive nodes in the circuit and force them
82 to decrypt it. Rather than using a single multiply encrypted data
85 where the initiator negotiates session keys with each successive hop in
86 the circuit. Once these keys are deleted, subsequently compromised nodes
87 cannot decrypt old traffic. As a side benefit, onion replay detection
88 is no longer necessary, and the process of building circuits is more
89 reliable, since the initiator knows when a hop fails and can then try
90 extending to a new node.
94 Onion Routing originally required a separate "application
95 proxy" for each supported application protocol-most of which were
96 never written, so many applications were never supported. Tor uses the
97 standard and near-ubiquitous SOCKS [<a href="#socks4" name="CITEsocks4">32</a>] proxy interface, allowing
98 us to support most TCP-based programs without modification. Tor now
99 relies on the filtering features of privacy-enhancing
100 application-level proxies such as Privoxy [<a href="#privoxy" name="CITEprivoxy">39</a>], without trying
101 to duplicate those features itself.
105 Routing originally called for batching and reordering cells as they arrived,
106 assumed padding between ORs, and in
107 later designs added padding between onion proxies (users) and
108 ORs [<a href="#or-ih96" name="CITEor-ih96">27</a>,<a href="#or-jsac98" name="CITEor-jsac98">41</a>]. Tradeoffs between padding protection
110 theorized [<a href="#or-pet00" name="CITEor-pet00">49</a>] to provide good security without expensive
111 padding, but no concrete padding scheme was suggested.
113 and deployment experience [<a href="#freedom21-security" name="CITEfreedom21-security">4</a>] suggest that this
114 level of resource use is not practical or economical; and even full
115 link padding is still vulnerable [<a href="#defensive-dropping" name="CITEdefensive-dropping">33</a>]. Thus,
116 until we have a proven and convenient design for traffic shaping or
117 low-latency mixing that improves anonymity against a realistic
118 adversary, we leave these strategies out.
122 built a separate circuit for each
123 application-level request, but this required
124 multiple public key operations for every request, and also presented
125 a threat to anonymity from building so many circuits; see
127 streams along each circuit to improve efficiency and anonymity.
131 within the circuit, Tor initiators can direct traffic to nodes partway
132 down the circuit. This novel approach
133 allows traffic to exit the circuit from the middle-possibly
134 frustrating traffic shape and volume attacks based on observing the end
135 of the circuit. (It also allows for long-range padding if
136 future research shows this to be worthwhile.)
140 address traffic bottlenecks. Unfortunately, typical approaches to
141 load balancing and flow control in overlay networks involve inter-node
142 control communication and global views of traffic. Tor's decentralized
143 congestion control uses end-to-end acks to maintain anonymity
144 while allowing nodes at the edges of the network to detect congestion
145 or flooding and send less data until the congestion subsides.
149 planned to flood state information through the network-an approach
150 that can be unreliable and complex. Tor takes a simplified view toward distributing this
151 information. Certain more trusted nodes act as <em>directory
152 servers</em>: they provide signed directories describing known
153 routers and their current state. Users periodically download them
154 via HTTP.
158 for each node to advertise a policy describing the hosts
159 and ports to which it will connect. These exit policies are critical
160 in a volunteer-based distributed infrastructure, because each operator
161 is comfortable with allowing different types of traffic to exit
162 from his node.
166 design did no integrity checking on data. Any node on the
167 circuit could change the contents of data cells as they passed by-for
168 example, to alter a connection request so it would connect
169 to a different webserver, or to `tag' encrypted traffic and look for
170 corresponding corrupted traffic at the network edges [<a href="#minion-design" name="CITEminion-design">15</a>].
171 Tor hampers these attacks by verifying data integrity before it leaves
172 the network.
178 Tor provides an integrated mechanism for responder anonymity via
179 location-protected servers. Previous Onion Routing designs included
180 long-lived "reply onions" that could be used to build circuits
181 to a hidden server, but these reply onions did not provide forward
182 security, and became useless if any node in the path went down
184 to connect with hidden servers; reply onions are no longer required.
187 Unlike Freedom [<a href="#freedom2-arch" name="CITEfreedom2-arch">8</a>], Tor does not require OS kernel
188 patches or network stack support. This prevents us from anonymizing
189 non-TCP protocols, but has greatly helped our portability and
190 deployability.
195 We have implemented all of the above features, including rendezvous
196 points. Our source code is
197 available under a free license, and Tor
198 is not covered by the patent that affected distribution and use of
199 earlier versions of Onion Routing.
200 We have deployed a wide-area alpha network
201 to test the design, to get more experience with usability
202 and users, and to provide a research platform for experimentation.
203 As of this writing, the network stands at 32 nodes spread over two continents.
208 and then address the above list of improvements in
209 Sections <a href="#sec:design">4</a>, <a href="#sec:rendezvous">5</a>, and <a href="#sec:other-design">6</a>.
210 We summarize
212 known attacks, and talk about our early deployment experiences in
223 </a>
228 proposed hiding the correspondence between sender and recipient by
229 wrapping messages in layers of public-key cryptography, and relaying them
230 through a path composed of "mixes." Each mix in turn
231 decrypts, delays, and re-orders messages before relaying them
232 onward.
235 Subsequent relay-based anonymity designs have diverged in two
239 to maximize anonymity at the cost of introducing comparatively large and
241 networks resist strong global adversaries,
242 but introduce too much lag for interactive tasks like web browsing,
243 Internet chat, or SSH connections.
247 try to anonymize interactive network traffic. These systems handle
248 a variety of bidirectional protocols. They also provide more convenient
249 mail delivery than the high-latency anonymous email
250 networks, because the remote mail server provides explicit and timely
251 delivery confirmation. But because these designs typically
252 involve many packets that must be delivered quickly, it is
253 difficult for them to prevent an attacker who can eavesdrop both ends of the
254 communication from correlating the timing and volume
255 of traffic entering the anonymity network with traffic leaving it [<a href="#SS03" name="CITESS03">45</a>].
256 These
257 protocols are similarly vulnerable to an active adversary who introduces
258 timing patterns into traffic entering the network and looks
259 for correlated patterns among exiting traffic.
260 Although some work has been done to frustrate these attacks, most designs
261 protect primarily against traffic analysis rather than traffic
265 The simplest low-latency designs are single-hop proxies such as the
266 <b>Anonymizer</b> [<a href="#anonymizer" name="CITEanonymizer">3</a>]: a single trusted server strips the
267 data's origin before relaying it. These designs are easy to
268 analyze, but users must trust the anonymizing proxy.
269 Concentrating the traffic to this single point increases the anonymity set
270 (the people a given user is hiding among), but it is vulnerable if the
271 adversary can observe all traffic entering and leaving the proxy.
274 More complex are distributed-trust, circuit-based anonymizing systems.
275 In these designs, a user establishes one or more medium-term bidirectional
276 end-to-end circuits, and tunnels data in fixed-size cells.
277 Establishing circuits is computationally expensive and typically
278 requires public-key
279 cryptography, whereas relaying cells is comparatively inexpensive and
280 typically requires only symmetric encryption.
281 Because a circuit crosses several servers, and each server only knows
282 the adjacent servers in the circuit, no single server can link a
283 user to her communication partners.
288 approach aggregates users into larger anonymity sets, but again an
289 attacker only needs to observe both ends of the cascade to bridge all
290 the system's traffic. The Java Anon Proxy's design
291 calls for padding between end users and the head of the
292 cascade [<a href="#web-mix" name="CITEweb-mix">7</a>]. However, it is not demonstrated whether the current
293 implementation's padding policy improves anonymity.
296 <b>PipeNet</b> [<a href="#back01" name="CITEback01">5</a>,<a href="#pipenet" name="CITEpipenet">12</a>], another low-latency design proposed
297 around the same time as Onion Routing, gave
298 stronger anonymity but allowed a single user to shut
299 down the network by not sending. Systems like <b>ISDN
300 mixes</b> [<a href="#isdn-mixes" name="CITEisdn-mixes">38</a>] were designed for other environments with
301 different assumptions.
304 In P2P designs like <b>Tarzan</b> [<a href="#tarzan:ccs02" name="CITEtarzan:ccs02">24</a>] and
305 <b>MorphMix</b> [<a href="#morphmix:fc04" name="CITEmorphmix:fc04">43</a>], all participants both generate
306 traffic and relay traffic for others. These systems aim to conceal
307 whether a given peer originated a request
308 or just relayed it from another peer. While Tarzan and MorphMix use
309 layered encryption as above, <b>Crowds</b> [<a href="#crowds-tissec" name="CITEcrowds-tissec">42</a>] simply assumes
310 an adversary who cannot observe the initiator: it uses no public-key
311 encryption, so any node on a circuit can read users' traffic.
314 <b>Hordes</b> [<a href="#hordes-jcs" name="CITEhordes-jcs">34</a>] is based on Crowds but also uses multicast
315 responses to hide the initiator. <b>Herbivore</b> [<a href="#herbivore" name="CITEherbivore">25</a>] and
316 <b>P</b><sup><b>5</b></sup> [<a href="#p5" name="CITEp5">46</a>] go even further, requiring broadcast.
317 These systems are designed primarily for communication among peers,
318 although Herbivore users can make external connections by
319 requesting a peer to serve as a proxy.
323 all at once, using a layered "onion" of public-key encrypted messages,
324 each layer of which provides session keys and the address of the
325 next server in the circuit. Tor as described herein, Tarzan, MorphMix,
326 <b>Cebolla</b> [<a href="#cebolla" name="CITEcebolla">9</a>], and Rennhard's <b>Anonymity Network</b> [<a href="#anonnet" name="CITEanonnet">44</a>]
327 build circuits
328 in stages, extending them one hop at a time.
330 approach enables perfect forward secrecy.
333 Circuit-based designs must choose which protocol layer
334 to anonymize. They may intercept IP packets directly, and
335 relay them whole (stripping the source address) along the
336 circuit [<a href="#freedom2-arch" name="CITEfreedom2-arch">8</a>,<a href="#tarzan:ccs02" name="CITEtarzan:ccs02">24</a>]. Like
337 Tor, they may accept TCP streams and relay the data in those streams,
338 ignoring the breakdown of that data into TCP
339 segments [<a href="#morphmix:fc04" name="CITEmorphmix:fc04">43</a>,<a href="#anonnet" name="CITEanonnet">44</a>]. Finally, like Crowds, they may accept
340 application-level protocols such as HTTP and relay the application
341 requests themselves.
342 Making this protocol-layer decision requires a compromise between flexibility
343 and anonymity. For example, a system that understands HTTP
344 can strip
345 identifying information from requests, can take advantage of caching
346 to limit the number of requests that leave the network, and can batch
347 or encode requests to minimize the number of connections.
348 On the other hand, an IP-level anonymizer can handle nearly any protocol,
349 even ones unforeseen by its designers (though these systems require
350 kernel-level modifications to some operating systems, and so are more
351 complex and less portable). TCP-level anonymity networks like Tor present
352 a middle approach: they are application neutral (so long as the
353 application supports, or can be tunneled across, TCP), but by treating
354 application connections as data streams rather than raw TCP packets,
355 they avoid the inefficiencies of tunneling TCP over
356 TCP.
359 Distributed-trust anonymizing systems need to prevent attackers from
360 adding too many servers and thus compromising user paths.
361 Tor relies on a small set of well-known directory servers, run by
362 independent parties, to decide which nodes can
363 join. Tarzan and MorphMix allow unknown users to run servers, and use
364 a limited resource (like IP addresses) to prevent an attacker from
365 controlling too much of the network. Crowds suggests requiring
366 written, notarized requests from potential crowd members.
369 Anonymous communication is essential for censorship-resistant
370 systems like Eternity [<a href="#eternity" name="CITEeternity">2</a>], Free Haven [<a href="#freehaven-berk" name="CITEfreehaven-berk">19</a>],
371 Publius [<a href="#publius" name="CITEpublius">53</a>], and Tangler [<a href="#tangler" name="CITEtangler">52</a>]. Tor's rendezvous
372 points enable connections between mutually anonymous entities; they
373 are a building block for location-hidden servers, which are needed by
374 Eternity and Free Haven.
382 </a>
386 Like other low-latency anonymity designs, Tor seeks to frustrate
387 attackers from linking communication partners, or from linking
388 multiple communications to or from a single user. Within this
389 main goal, however, several considerations have directed
390 Tor's evolution.
394 real world. Thus it
395 must not be expensive to run (for example, by requiring more bandwidth
396 than volunteers are willing to provide); must not place a heavy
397 liability burden on operators (for example, by allowing attackers to
398 implicate onion routers in illegal activities); and must not be
399 difficult or expensive to implement (for example, by requiring kernel
400 patches, or separate proxies for every protocol). We also cannot
401 require non-anonymous parties (such as websites)
402 to run our software. (Our rendezvous point design does not meet
403 this goal for non-anonymous users talking to hidden servers,
408 anonymity systems hide users among users, a system with fewer users
409 provides less anonymity. Usability is thus not only a convenience:
410 it is a security requirement [<a href="#econymics" name="CITEeconymics">1</a>,<a href="#back01" name="CITEback01">5</a>]. Tor should
411 therefore not
412 require modifying familiar applications; should not introduce prohibitive
413 delays;
414 and should require as few configuration decisions
415 as possible. Finally, Tor should be easily implementable on all common
416 platforms; we cannot require users to change their operating system
417 to be anonymous. (Tor currently runs on Win32, Linux,
418 Solaris, BSD-style Unix, MacOS X, and probably others.)
422 so Tor can serve as a test-bed for future research.
423 Many of the open problems in low-latency anonymity
424 networks, such as generating dummy traffic or preventing Sybil
425 attacks [<a href="#sybil" name="CITEsybil">22</a>], may be solvable independently from the issues
426 solved by
427 Tor. Hopefully future systems will not need to reinvent Tor's design.
431 parameters must be well-understood. Additional features impose implementation
432 and complexity costs; adding unproven techniques to the design threatens
433 deployability, readability, and ease of security analysis. Tor aims to
434 deploy a simple and stable system that integrates the best accepted
435 approaches to protecting anonymity.<br />
439 </a><br />
440 In favoring simple, deployable designs, we have explicitly deferred
441 several possible goals, either because they are solved elsewhere, or because
442 they are not yet solved.
446 decentralized peer-to-peer environments with thousands of short-lived
447 servers, many of which may be controlled by an adversary. This approach
448 is appealing, but still has many open
449 problems [<a href="#tarzan:ccs02" name="CITEtarzan:ccs02">24</a>,<a href="#morphmix:fc04" name="CITEmorphmix:fc04">43</a>].
453 to completely solve end-to-end timing or intersection
454 attacks. Some approaches, such as having users run their own onion routers,
455 may help;
460 normalization</em> like Privoxy or the Anonymizer. If senders want anonymity from
461 responders while using complex and variable
462 protocols like HTTP, Tor must be layered with a filtering proxy such
463 as Privoxy to hide differences between clients, and expunge protocol
464 features that leak identity.
465 Note that by this separation Tor can also provide services that
466 are anonymous to the network yet authenticated to the responder, like
467 SSH. Similarly, Tor does not integrate
468 tunneling for non-stream-based protocols like UDP; this must be
469 provided by an external service if appropriate.
473 to the network.
479 </a>
482 A global passive adversary is the most commonly assumed threat when
483 analyzing theoretical anonymity designs. But like all practical
484 low-latency systems, Tor does not protect against such a strong
485 adversary. Instead, we assume an adversary who can observe some fraction
486 of network traffic; who can generate, modify, delete, or delay
487 traffic; who can operate onion routers of his own; and who can
488 compromise some fraction of the onion routers.
491 In low-latency anonymity systems that use layered encryption, the
492 adversary's typical goal is to observe both the initiator and the
493 responder. By observing both ends, passive attackers can confirm a
494 suspicion that Alice is
495 talking to Bob if the timing and volume patterns of the traffic on the
496 connection are distinct enough; active attackers can induce timing
497 signatures on the traffic to force distinct patterns. Rather
499 we aim to prevent <em>traffic
500 analysis</em> attacks, where the adversary uses traffic patterns to learn
501 which points in the network he should attack.
504 Our adversary might try to link an initiator Alice with her
505 communication partners, or try to build a profile of Alice's
506 behavior. He might mount passive attacks by observing the network edges
507 and correlating traffic entering and leaving the network-by
508 relationships in packet timing, volume, or externally visible
509 user-selected
510 options. The adversary can also mount active attacks by compromising
511 routers or keys; by replaying traffic; by selectively denying service
512 to trustworthy routers to move users to
513 compromised routers, or denying service to users to see if traffic
514 elsewhere in the
515 network stops; or by introducing patterns into traffic that can later be
516 detected. The adversary might subvert the directory servers to give users
517 differing views of network state. Additionally, he can try to decrease
518 the network's reliability by attacking nodes or by performing antisocial
519 activities from reliable nodes and trying to get them taken down-making
520 the network unreliable flushes users to other less anonymous
521 systems, where they may be easier to attack. We summarize
523 each of these attacks.
531 </a>
534 The Tor network is an overlay network; each onion router (OR)
535 runs as a normal
536 user-level process without any special privileges.
538 connection to every other onion router.
539 Each user
540 runs local software called an onion proxy (OP) to fetch directories,
541 establish circuits across the network,
542 and handle connections from user applications. These onion proxies accept
543 TCP streams and multiplex them across the circuits. The onion
544 router on the other side
545 of the circuit connects to the requested destinations
546 and relays data.
549 Each onion router maintains a long-term identity key and a short-term
550 onion key. The identity
551 key is used to sign TLS certificates, to sign the OR's <em>router
552 descriptor</em> (a summary of its keys, address, bandwidth, exit policy,
553 and so on), and (by directory servers) to sign directories. The onion key is used to decrypt requests
554 from users to set up a circuit and negotiate ephemeral keys.
555 The TLS protocol also establishes a short-term link key when communicating
556 between ORs. Short-term keys are rotated periodically and
557 independently, to limit the impact of key compromise.
564 describes how TCP streams are routed through the network. We address
567 Finally,
569 fairness issues.
575 </a>
578 Onion routers communicate with one another, and with users' OPs, via
579 TLS connections with ephemeral keys. Using TLS conceals the data on
580 the connection with perfect forward secrecy, and prevents an attacker
581 from modifying data on the wire or impersonating an OR.
584 Traffic passes along these connections in fixed-size cells. Each cell
585 is 512 bytes, and consists of a header and a payload. The header includes a circuit
586 identifier (circID) that specifies which circuit the cell refers to
587 (many circuits can be multiplexed over the single TLS connection), and
588 a command to describe what to do with the cell's payload. (Circuit
589 identifiers are connection-specific: each circuit has a different
590 circID on each OP/OR or OR/OR connection it traverses.)
593 which carry end-to-end stream data. The control cell commands are:
599 Relay cells have an additional header (the relay header) at the front
600 of the payload, containing a streamID (stream identifier: many streams can
601 be multiplexed over a circuit); an end-to-end checksum for integrity
602 checking; the length of the relay payload; and a relay command.
603 The entire contents of the relay header and the relay cell payload
604 are encrypted or decrypted together as the relay cell moves along the
605 circuit, using the 128-bit AES cipher in counter mode to generate a
606 cipher stream. The relay commands are: <em>relay
610 (to notify the OP that a relay begin has succeeded), <em>relay
613 (to tear down only part of the circuit, and to acknowledge), <em>relay
615 implement long-range dummies).
616 We give a visual overview of cell structure plus the details of relay
617 cell structure, and then describe each of these cell types and commands
618 in more detail below.
627 </center>
632 </a>
635 Onion Routing originally built one circuit for each
636 TCP stream. Because building a circuit can take several tenths of a
637 second (due to public-key cryptography and network latency),
638 this design imposed high costs on applications like web browsing that
639 open many TCP streams.
642 In Tor, each circuit can be shared by many TCP streams. To avoid
643 delays, users construct circuits preemptively. To limit linkability
644 among their streams, users' OPs build a new circuit
645 periodically if the previous ones have been used,
646 and expire old used circuits that no longer have any open streams.
647 OPs consider rotating to a new circuit once a minute: thus
648 even heavy users spend negligible time
649 building circuits, but a limited number of requests can be linked
650 to each other through a given exit node. Also, because circuits are built
651 in the background, OPs can recover from failed circuit creation
652 without harming user experience.<br />
662 </a>
663 </center>
666 </a><br />
667 A user's OP constructs circuits incrementally, negotiating a
668 symmetric key with each OR on the circuit, one hop at a time. To begin
669 creating a new circuit, the OP (call her Alice) sends a
671 (She chooses a new
674 payload contains the first half of the Diffie-Hellman handshake
680 Once the circuit has been established, Alice and Bob can send one
681 another relay cells encrypted with the negotiated
683 the next section.
687 to Bob, specifying the address of the next OR (call her Carol), and
691 between him and Carol. Alice never needs to know this circID; only Bob
693 his connection with Carol.)
696 the circuit is extended to Carol, and Alice and Carol share a common key
700 To extend the circuit to a third node or beyond, Alice
701 proceeds as above, always telling the last node in the circuit to
702 extend one hop further.
705 This circuit-level handshake protocol achieves unilateral entity
706 authentication (Alice knows she's handshaking with the OR, but
707 the OR doesn't care who is opening the circuit-Alice uses no public key
708 and remains anonymous) and unilateral key authentication
709 (Alice and the OR agree on a key, and Alice knows only the OR learns
710 it). It also achieves forward
711 secrecy and key freshness. More formally, the protocol is as follows
714 > is concatenation):
718 </a>
719 <table>
720 <tr><td align="right">Alice </td><td align="center">-> </td><td align="center">Bob </td><td>: E<sub>PK<sub>Bob</sub></sub>(g<sup>x</sup>) </td></tr>
721 <tr><td align="right">Bob </td><td align="center">-> </td><td align="center">Alice </td><td>: g<sup>y</sup>, H(K <font face="symbol">|</font
723 </td></tr></table>
728 and who chose y. We use PK encryption in the first step
729 (rather than, say, using the first two steps of STS, which has a
730 signature in the second step) because a single cell is too small to
731 hold both a public key and a signature. Preliminary analysis with the
732 NRL protocol analyzer [<a href="#meadows96" name="CITEmeadows96">35</a>] shows this protocol to be
733 secure (including perfect forward secrecy) under the
734 traditional Dolev-Yao model.<br />
738 Once Alice has established the circuit (so she shares keys with each
739 OR on the circuit), she can send relay cells.
740 Upon receiving a relay
741 cell, an OR looks up the corresponding circuit, and decrypts the relay
742 header and payload with the session key for that circuit.
743 If the cell is headed away from Alice the OR then checks whether the
744 decrypted cell has a valid digest (as an optimization, the first
745 two bytes of the integrity check are zero, so in most cases we can avoid
746 computing the hash).
747 If valid, it accepts the relay cell and processes it as described
748 below. Otherwise,
749 the OR looks up the circID and OR for the
750 next step in the circuit, replaces the circID as appropriate, and
751 sends the decrypted relay cell to the next OR. (If the OR at the end
752 of the circuit receives an unrecognized relay cell, an error has
753 occurred, and the circuit is torn down.)
756 OPs treat incoming relay cells similarly: they iteratively unwrap the
757 relay header and payload with the session keys shared with each
758 OR on the circuit, from the closest to farthest.
759 If at any stage the digest is valid, the cell must have
760 originated at the OR whose encryption has just been removed.
763 To construct a relay cell addressed to a given OR, Alice assigns the
764 digest, and then iteratively
765 encrypts the cell payload (that is, the relay header and payload) with
766 the symmetric key of each hop up to that OR. Because the digest is
767 encrypted to a different value at each step, only at the targeted OR
770 allows Alice's streams to exit at different ORs on a single circuit.
771 Alice may choose different exit points because of their exit policies,
772 or to keep the ORs from knowing that two streams
773 originate from the same person.
776 When an OR later replies to Alice with a relay cell, it
777 encrypts the cell's relay header and payload with the single key it
778 shares with Alice, and sends the cell back toward Alice along the
779 circuit. Subsequent ORs add further layers of encryption as they
780 relay the cell back to Alice.
786 forward. But just as circuits are built incrementally, they can also
787 be torn down incrementally: Alice can send a <em>relay
788 truncate</em> cell to a single OR on a circuit. That OR then sends a
791 different nodes, without signaling to the intermediate nodes (or
792 a limited observer) that she has changed her circuit.
793 Similarly, if a node on the circuit goes down, the adjacent
795 "break a node and see which circuits go down"
802 </a>
805 When Alice's application wants a TCP connection to a given
806 address and port, it asks the OP (via SOCKS) to make the
807 connection. The OP chooses the newest open circuit (or creates one if
808 needed), and chooses a suitable OR on that circuit to be the
809 exit node (usually the last node, but maybe others due to exit policy
812 using a new random streamID. Once the
813 exit node connects to the remote host, it responds
815 SOCKS reply to notify the application of its success. The OP
816 now accepts data from the application's TCP stream, packaging it into
818 the chosen OR.
821 There's a catch to using SOCKS, however-some applications pass the
822 alphanumeric hostname to the Tor client, while others resolve it into
823 an IP address first and then pass the IP address to the Tor client. If
824 the application does DNS resolution first, Alice thereby reveals her
825 destination to the remote DNS server, rather than sending the hostname
826 through the Tor network to be resolved at the far end. Common applications
827 like Mozilla and SSH have this flaw.
830 With Mozilla, the flaw is easy to address: the filtering HTTP
831 proxy called Privoxy gives a hostname to the Tor client, so Alice's
832 computer never does DNS resolution.
833 But a portable general solution, such as is needed for
834 SSH, is
835 an open problem. Modifying or replacing the local nameserver
836 can be invasive, brittle, and unportable. Forcing the resolver
837 library to prefer TCP rather than UDP is hard, and also has
838 portability problems. Dynamically intercepting system calls to the
839 resolver library seems a promising direction. We could also provide
841 Tor network. Currently, we encourage the use of privacy-aware proxies
842 like Privoxy wherever possible.
845 Closing a Tor stream is analogous to closing a TCP stream: it uses a
846 two-step handshake for normal operation, or a one-step handshake for
847 errors. If the stream closes abnormally, the adjacent node simply sends a
851 all relay cells use layered encryption, only the destination OR knows
852 that a given relay cell is a request to close a stream. This two-step
853 handshake allows Tor to support TCP-based applications that use half-closed
854 connections.
860 </a>
863 Because the old Onion Routing design used a stream cipher without integrity
864 checking, traffic was
865 vulnerable to a malleability attack: though the attacker could not
866 decrypt cells, any changes to encrypted data
867 would create corresponding changes to the data leaving the network.
868 This weakness allowed an adversary who could guess the encrypted content
869 to change a padding cell to a destroy
871 adversary's webserver; or change an FTP command from
873 adversary could do this, because the link encryption similarly used a
874 stream cipher.)
877 Because Tor uses TLS on its links, external adversaries cannot modify
878 data. Addressing the insider malleability attack, however, is
879 more complex.
882 We could do integrity checking of the relay cells at each hop, either
883 by including hashes or by using an authenticating cipher mode like
884 EAX [<a href="#eax" name="CITEeax">6</a>], but there are some problems. First, these approaches
885 impose a message-expansion overhead at each hop, and so we would have to
886 either leak the path length or waste bytes by padding to a maximum
887 path length. Second, these solutions can only verify traffic coming
888 from Alice: ORs would not be able to produce suitable hashes for
889 the intermediate hops, since the ORs on a circuit do not know the
890 other ORs' session keys. Third, we have already accepted that our design
891 is vulnerable to end-to-end timing attacks; so tagging attacks performed
892 within the circuit provide no additional information to the attacker.
895 Thus, we check integrity only at the edges of each stream. (Remember that
896 in our leaky-pipe circuit topology, a stream's edge could be any hop
897 in the circuit.) When Alice
898 negotiates a key with a new hop, they each initialize a SHA-1
899 digest with a derivative of that key,
900 thus beginning with randomness that only the two of them know.
901 Then they each incrementally add to the SHA-1 digest the contents of
902 all relay cells they create, and include with each relay cell the
903 first four bytes of the current digest. Each also keeps a SHA-1
904 digest of data received, to verify that the received hashes are correct.
907 To be sure of removing or modifying a cell, the attacker must be able
908 to deduce the current digest state (which depends on all
909 traffic between Alice and Bob, starting with their negotiated key).
910 Attacks on SHA-1 where the adversary can incrementally add to a hash
911 to produce a new valid hash don't work, because all hashes are
912 end-to-end encrypted across the circuit. The computational overhead
913 of computing the digests is minimal compared to doing the AES
914 encryption performed at each hop of the circuit. We use only four
915 bytes per cell to minimize overhead; the chance that an adversary will
916 correctly guess a valid hash
917 is
918 acceptably low, given that the OP or OR tear down the circuit if they
919 receive a bad hash.
925 </a>
928 Volunteers are more willing to run services that can limit
929 their bandwidth usage. To accommodate them, Tor servers use a
931 enforce a long-term average rate of incoming bytes, while still
932 permitting short-term bursts above the allowed bandwidth.
937 Because the Tor protocol outputs about the same number of bytes as it
938 takes in, it is sufficient in practice to limit only incoming bytes.
939 With TCP streams, however, the correspondence is not one-to-one:
940 relaying a single incoming byte can require an entire 512-byte cell.
941 (We can't just wait for more bytes, because the local application may
942 be awaiting a reply.) Therefore, we treat this case as if the entire
943 cell size had been read, regardless of the cell's fullness.
946 Further, inspired by Rennhard et al's design in [<a href="#anonnet" name="CITEanonnet">44</a>], a
947 circuit's edges can heuristically distinguish interactive streams from bulk
948 streams by comparing the frequency with which they supply cells. We can
949 provide good latency for interactive streams by giving them preferential
950 service, while still giving good overall throughput to the bulk
951 streams. Such preferential treatment presents a possible end-to-end
952 attack, but an adversary observing both
953 ends of the stream can already learn this information through timing
954 attacks.
960 </a>
963 Even with bandwidth rate limiting, we still need to worry about
964 congestion, either accidental or intentional. If enough users choose the
965 same OR-to-OR connection for their circuits, that connection can become
966 saturated. For example, an attacker could send a large file
967 through the Tor network to a webserver he runs, and then
968 refuse to read any of the bytes at the webserver end of the
969 circuit. Without some congestion control mechanism, these bottlenecks
970 can propagate back through the entire network. We don't need to
971 reimplement full TCP windows (with sequence numbers,
972 the ability to drop cells when we're full and retransmit later, and so
973 on),
974 because TCP already guarantees in-order delivery of each
975 cell.
976 We describe our response below.
980 To control a circuit's bandwidth usage, each OR keeps track of two
982 allowed to package (from incoming TCP streams) for transmission back to the OP,
984 to deliver to TCP streams outside the network. Each window is initialized
985 (say, to 1000 data cells). When a data cell is packaged or delivered,
986 the appropriate window is decremented. When an OR has received enough
989 streamID zero, it increments its packaging window. Either of these cells
990 increments the corresponding window by 100. If the packaging window
991 reaches 0, the OR stops reading from TCP connections for all streams
992 on the corresponding circuit, and sends no more relay data cells until
996 The OP behaves identically, except that it must track a packaging window
997 and a delivery window for every OR in the circuit. If a packaging window
998 reaches 0, it stops reading from streams destined for that OR.
1002 The stream-level congestion control mechanism is similar to the
1004 to implement end-to-end flow control for individual streams across
1005 circuits. Each stream begins with a packaging window (currently 500 cells),
1008 as enough cells have arrived, the stream-level congestion control also
1009 has to check whether data has been successfully flushed onto the TCP
1011 to be flushed is under some threshold (currently 10 cells' worth).
1016 These arbitrarily chosen parameters seem to give tolerable throughput
1023 </a>
1026 Rendezvous points are a building block for <em>location-hidden
1028 network. Location-hidden services allow Bob to offer a TCP
1029 service, such as a webserver, without revealing his IP address.
1030 This type of anonymity protects against distributed DoS attacks:
1031 attackers are forced to attack the onion routing network
1032 because they do not know Bob's IP address.
1035 Our design for location-hidden servers has the following goals.
1037 so an attacker cannot flood Bob simply by making many connections to him.
1039 identity even in the presence of router failure. Bob's service must
1040 not be tied to a single OR, and Bob must be able to migrate his service
1042 A social attacker
1043 should not be able to "frame" a rendezvous router by
1044 offering an illegal or disreputable location-hidden service and
1045 making observers believe the router created that service.
1047 to run special software to access location-hidden servers, we must not
1048 require them to modify their applications.
1051 We provide location-hiding for Bob by allowing him to advertise
1053 points. He may do this on any robust efficient
1054 key-value lookup system with authenticated updates, such as a
1055 distributed hash table (DHT) like CFS [<a href="#cfs:sosp01" name="CITEcfs:sosp01">11</a>].<a href="#tthFtNtAAD" name="tthFrefAAD"><sup>3</sup></a> Alice, the client, chooses an OR as her
1057 points, informs him of her rendezvous point, and then waits for him
1058 to connect to the rendezvous point. This extra level of indirection
1059 helps Bob's introduction points avoid problems associated with serving
1060 unpopular files directly (for example, if Bob serves
1061 material that the introduction point's community finds objectionable,
1062 or if Bob's service tends to get attacked by network vandals).
1063 The extra level of indirection also allows Bob to respond to some requests
1064 and ignore others.
1071 The following steps are
1072 performed on behalf of Alice and Bob by their local OPs;
1073 application integration is described more fully below.
1079 <dt><b></b></dt>
1081 <dt><b></b></dt>
1082 <dd><li>Bob chooses some introduction points, and advertises them on
1083 the lookup service, signing the advertisement with his public key. He
1084 can add more later.</dd>
1085 <dt><b></b></dt>
1086 <dd><li>Bob builds a circuit to each of his introduction points, and tells
1087 them to wait for requests.</dd>
1088 <dt><b></b></dt>
1089 <dd><li>Alice learns about Bob's service out of band (perhaps Bob told her,
1090 or she found it on a website). She retrieves the details of Bob's
1091 service from the lookup service. If Alice wants to access Bob's
1092 service anonymously, she must connect to the lookup service via Tor.</dd>
1093 <dt><b></b></dt>
1094 <dd><li>Alice chooses an OR as the rendezvous point (RP) for her connection to
1095 Bob's service. She builds a circuit to the RP, and gives it a
1097 <dt><b></b></dt>
1098 <dd><li>Alice opens an anonymous stream to one of Bob's introduction
1099 points, and gives it a message (encrypted with Bob's public key)
1100 telling it about herself,
1101 her RP and rendezvous cookie, and the
1102 start of a DH
1103 handshake. The introduction point sends the message to Bob.</dd>
1104 <dt><b></b></dt>
1105 <dd><li>If Bob wants to talk to Alice, he builds a circuit to Alice's
1106 RP and sends the rendezvous cookie, the second half of the DH
1107 handshake, and a hash of the session
1108 key they now share. By the same argument as in
1110 shares the key only with Bob.</dd>
1111 <dt><b></b></dt>
1112 <dd><li>The RP connects Alice's circuit to Bob's. Note that RP can't
1113 recognize Alice, Bob, or the data they transmit.</dd>
1114 <dt><b></b></dt>
1116 arrives at Bob's OP, which connects to Bob's
1117 webserver.</dd>
1118 <dt><b></b></dt>
1119 <dd><li>An anonymous stream has been established, and Alice and Bob
1120 communicate as normal.
1121 </dd>
1122 </dl>
1125 When establishing an introduction point, Bob provides the onion router
1126 with the public key identifying his service. Bob signs his
1127 messages, so others cannot usurp his introduction point
1128 in the future. He uses the same public key to establish the other
1129 introduction points for his service, and periodically refreshes his
1130 entry in the lookup service.
1133 The message that Alice gives
1134 the introduction point includes a hash of Bob's public key and an optional initial authorization token (the
1135 introduction point can do prescreening, for example to block replays). Her
1136 message to Bob may include an end-to-end authorization token so Bob
1137 can choose whether to respond.
1138 The authorization tokens can be used to provide selective access:
1139 important users can get uninterrupted access.
1140 During normal situations, Bob's service might simply be offered
1141 directly from mirrors, while Bob gives out tokens to high-priority users. If
1142 the mirrors are knocked down,
1143 those users can switch to accessing Bob's service via
1144 the Tor rendezvous system.
1147 Bob's introduction points are themselves subject to DoS-he must
1148 open many introduction points or risk such an attack.
1149 He can provide selected users with a current list or future schedule of
1150 unadvertised introduction points;
1151 this is most practical
1152 if there is a stable and large group of introduction points
1153 available. Bob could also give secret public keys
1154 for consulting the lookup service. All of these approaches
1155 limit exposure even when
1156 some selected users collude in the DoS.
1163 Bob configures his onion proxy to know the local IP address and port of his
1164 service, a strategy for authorizing clients, and his public key. The onion
1165 proxy anonymously publishes a signed statement of Bob's
1166 public key, an expiration time, and
1167 the current introduction points for his service onto the lookup service,
1168 indexed
1169 by the hash of his public key. Bob's webserver is unmodified,
1170 and doesn't even know that it's hidden behind the Tor network.
1173 Alice's applications also work unchanged-her client interface
1174 remains a SOCKS proxy. We encode all of the necessary information
1175 into the fully qualified domain name (FQDN) Alice uses when establishing her
1176 connection. Location-hidden services use a virtual top level domain
1179 the public key. Alice's onion proxy
1180 examines addresses; if they're destined for a hidden server, it decodes
1181 the key and starts the rendezvous as described above.
1188 Rendezvous points in low-latency anonymity systems were first
1189 described for use in ISDN telephony [<a href="#jerichow-jsac98" name="CITEjerichow-jsac98">30</a>,<a href="#isdn-mixes" name="CITEisdn-mixes">38</a>].
1190 Later low-latency designs used rendezvous points for hiding location
1191 of mobile phones and low-power location
1192 trackers [<a href="#federrath-ih96" name="CITEfederrath-ih96">23</a>,<a href="#reed-protocols97" name="CITEreed-protocols97">40</a>]. Rendezvous for
1193 anonymizing low-latency
1194 Internet connections was suggested in early Onion Routing
1195 work [<a href="#or-ih96" name="CITEor-ih96">27</a>], but the first published design was by Ian
1197 ours in three ways. First, Goldberg suggests that Alice should manually
1198 hunt down a current location of the service via Gnutella; our approach
1199 makes lookup transparent to the user, as well as faster and more robust.
1200 Second, in Tor the client and server negotiate session keys
1201 with Diffie-Hellman, so plaintext is not exposed even at the rendezvous
1202 point. Third,
1203 our design minimizes the exposure from running the
1204 service, to encourage volunteers to offer introduction and rendezvous
1205 services. Tor's introduction points do not output any bytes to the
1206 clients; the rendezvous points don't know the client or the server,
1207 and can't read the data being transmitted. The indirection scheme is
1208 also designed to include authentication/authorization-if Alice doesn't
1209 include the right cookie with her request for service, Bob need not even
1210 acknowledge his existence.
1216 </a>
1222 </a>
1225 Providing Tor as a public service creates many opportunities for
1226 denial-of-service attacks against the network. While
1227 flow control and rate limiting (discussed in
1229 bandwidth than routers are willing to provide, opportunities remain for
1230 users to
1231 consume more network resources than their fair share, or to render the
1232 network unusable for others.
1235 First of all, there are several CPU-consuming denial-of-service
1236 attacks wherein an attacker can force an OR to perform expensive
1237 cryptographic operations. For example, an attacker can
1238 fake the start of a TLS handshake, forcing the OR to carry out its
1239 (comparatively expensive) half of the handshake at no real computational
1240 cost to the attacker.
1243 We have not yet implemented any defenses for these attacks, but several
1244 approaches are possible. First, ORs can
1245 require clients to solve a puzzle [<a href="#puzzles-tls" name="CITEpuzzles-tls">16</a>] while beginning new
1247 tokens are easy to verify and computationally expensive to produce, this
1248 approach limits the attack multiplier. Additionally, ORs can limit
1250 so that
1251 the computational work of processing them does not drown out the
1252 symmetric cryptography operations that keep cells
1253 flowing. This rate limiting could, however, allow an attacker
1254 to slow down other users when they build new circuits.
1259 Adversaries can also attack the Tor network's hosts and network
1260 links. Disrupting a single circuit or link breaks all streams passing
1261 along that part of the circuit. Users similarly lose service
1262 when a router crashes or its operator restarts it. The current
1263 Tor design treats such attacks as intermittent network failures, and
1264 depends on users and applications to respond or recover as appropriate. A
1265 future design could use an end-to-end TCP-like acknowledgment protocol,
1266 so no streams are lost unless the entry or exit point is
1267 disrupted. This solution would require more buffering at the network
1268 edges, however, and the performance and anonymity implications from this
1269 extra complexity still require investigation.
1275 </a>
1280 Exit abuse is a serious barrier to wide-scale Tor deployment. Anonymity
1281 presents would-be vandals and abusers with an opportunity to hide
1282 the origins of their activities. Attackers can harm the Tor network by
1283 implicating exit servers for their abuse. Also, applications that commonly
1284 use IP-based authentication (such as institutional mail or webservers)
1285 can be fooled by the fact that anonymous connections appear to originate
1286 at the exit OR.
1289 We stress that Tor does not enable any new class of abuse. Spammers
1290 and other attackers already have access to thousands of misconfigured
1291 systems worldwide, and the Tor network is far from the easiest way
1292 to launch attacks.
1293 But because the
1294 onion routers can be mistaken for the originators of the abuse,
1295 and the volunteers who run them may not want to deal with the hassle of
1296 explaining anonymity networks to irate administrators, we must block or limit
1297 abuse through the Tor network.
1301 describes to which external addresses and ports the router will
1305 nodes that only connect to a local host or network. A private
1306 exit can allow a client to connect to a given host or
1307 network more securely-an external adversary cannot eavesdrop traffic
1308 between the private exit and the final destination, and so is less sure of
1309 Alice's destination and activities. Most onion routers in the current
1310 network function as
1312 but prevent access to certain abuse-prone addresses and services such
1313 as SMTP.
1314 The OR might also be able to authenticate clients to
1315 prevent exit abuse without harming anonymity [<a href="#or-discex00" name="CITEor-discex00">48</a>].
1320 Many administrators use port restrictions to support only a
1321 limited set of services, such as HTTP, SSH, or AIM.
1322 This is not a complete solution, of course, since abuse opportunities for these
1323 protocols are still well known.
1326 We have not yet encountered any abuse in the deployed network, but if
1327 we do we should consider using proxies to clean traffic for certain
1328 protocols as it leaves the network. For example, much abusive HTTP
1329 behavior (such as exploiting buffer overflows or well-known script
1330 vulnerabilities) can be detected in a straightforward manner.
1331 Similarly, one could run automatic spam filtering software (such as
1332 SpamAssassin) on email exiting the OR network.
1335 ORs may also rewrite exiting traffic to append
1336 headers or other information indicating that the traffic has passed
1337 through an anonymity service. This approach is commonly used
1338 by email-only anonymity systems. ORs can also
1340 alert abuse targets to the nature of the anonymous traffic.
1343 A mixture of open and restricted exit nodes allows the most
1344 flexibility for volunteers running servers. But while having many
1345 middleman nodes provides a large and robust network,
1346 having only a few exit nodes reduces the number of points
1347 an adversary needs to monitor for traffic analysis, and places a
1348 greater burden on the exit nodes. This tension can be seen in the
1349 Java Anon Proxy
1350 cascade model, wherein only one node in each cascade needs to handle
1351 abuse complaints-but an adversary only needs to observe the entry
1352 and exit of a cascade to perform traffic analysis on all that
1353 cascade's users. The hydra model (many entries, few exits) presents a
1354 different compromise: only a few exit nodes are needed, but an
1355 adversary needs to work harder to watch all the clients; see
1359 Finally, we note that exit abuse must not be dismissed as a peripheral
1360 issue: when a system's public image suffers, it can reduce the number
1361 and diversity of that system's users, and thereby reduce the anonymity
1362 of the system itself. Like usability, public perception is a
1363 security parameter. Sadly, preventing abuse of open exit nodes is an
1364 unsolved problem, and will probably remain an arms race for the
1365 foreseeable future. The abuse problems faced by Princeton's CoDeeN
1366 project [<a href="#darkside" name="CITEdarkside">37</a>] give us a glimpse of likely issues.
1372 </a>
1375 First-generation Onion Routing designs [<a href="#freedom2-arch" name="CITEfreedom2-arch">8</a>,<a href="#or-jsac98" name="CITEor-jsac98">41</a>] used
1376 in-band network status updates: each router flooded a signed statement
1377 to its neighbors, which propagated it onward. But anonymizing networks
1378 have different security goals than typical link-state routing protocols.
1379 For example, delays (accidental or intentional)
1380 that can cause different parts of the network to have different views
1381 of link-state and topology are not only inconvenient: they give
1382 attackers an opportunity to exploit differences in client knowledge.
1383 We also worry about attacks to deceive a
1384 client about the router membership list, topology, or current network
1386 adversary to efficiently deploy resources
1390 Tor uses a small group of redundant, well-known onion routers to
1391 track changes in network topology and node state, including keys and
1393 server, so clients can fetch current network state
1394 and router lists, and so other ORs can upload
1395 state information. Onion routers periodically publish signed
1396 statements of their state to each directory server. The directory servers
1397 combine this information with their own views of network liveness,
1399 network state. Client software is
1400 pre-loaded with a list of the directory servers and their keys,
1401 to bootstrap each client's view of the network.
1404 When a directory server receives a signed statement for an OR, it
1405 checks whether the OR's identity key is recognized. Directory
1406 servers do not advertise unrecognized ORs-if they did,
1407 an adversary could take over the network by creating many
1408 servers [<a href="#sybil" name="CITEsybil">22</a>]. Instead, new nodes must be approved by the
1409 directory
1410 server administrator before they are included. Mechanisms for automated
1411 node approval are an area of active research, and are discussed more
1415 Of course, a variety of attacks remain. An adversary who controls
1416 a directory server can track clients by providing them different
1417 information-perhaps by listing only nodes under its control, or by
1418 informing only certain clients about a given node. Even an external
1419 adversary can exploit differences in client knowledge: clients who use
1420 a node listed on one directory server but not the others are vulnerable.
1423 Thus these directory servers must be synchronized and redundant, so
1424 that they can agree on a common directory. Clients should only trust
1425 this directory if it is signed by a threshold of the directory
1426 servers.
1429 The directory servers in Tor are modeled after those in
1430 Mixminion [<a href="#minion-design" name="CITEminion-design">15</a>], but our situation is easier. First,
1431 we make the
1432 simplifying assumption that all participants agree on the set of
1433 directory servers. Second, while Mixminion needs to predict node
1434 behavior, Tor only needs a threshold consensus of the current
1435 state of the network. Third, we assume that we can fall back to the
1436 human administrators to discover and resolve problems when a consensus
1437 directory cannot be reached. Since there are relatively few directory
1439 we can afford operations like broadcast to simplify the consensus-building
1440 protocol.
1443 To avoid attacks where a router connects to all the directory servers
1444 but refuses to relay traffic from other routers, the directory servers
1445 must also build circuits and use them to anonymously test router
1446 reliability [<a href="#mix-acc" name="CITEmix-acc">18</a>]. Unfortunately, this defense is not yet
1447 designed or
1448 implemented.
1451 Using directory servers is simpler and more flexible than flooding.
1452 Flooding is expensive, and complicates the analysis when we
1453 start experimenting with non-clique network topologies. Signed
1454 directories can be cached by other
1455 onion routers,
1456 so directory servers are not a performance
1457 bottleneck when we have many users, and do not aid traffic analysis by
1458 forcing clients to announce their existence to any
1459 central point.
1465 </a>
1468 Below we summarize a variety of attacks, and discuss how well our
1469 design withstands them.<br />
1474 will not reveal her destination or data, but it will
1475 reveal traffic patterns (both sent and received). Profiling via user
1476 connection patterns requires further processing, because multiple
1477 application streams may be operating simultaneously or in series over
1478 a single circuit.
1482 connections to responders may not be (indeed, the responding website
1483 itself may be hostile). While filtering content is not a primary goal
1484 of Onion Routing, Tor can directly use Privoxy and related
1485 filtering services to anonymize application data streams.
1489 configuration options. For example, clients concerned about request
1490 linkability should rotate circuits more often than those concerned
1491 about traceability. Allowing choice may attract users with different
1492 needs; but clients who are
1493 in the minority may lose more anonymity by appearing distinct than they
1498 such correlations. An attacker watching patterns of
1499 traffic at the initiator and the responder will be
1500 able to confirm the correspondence with high probability. The
1501 greatest protection currently available against such confirmation is to hide
1502 the connection between the onion proxy and the first Tor node,
1503 by running the OP on the Tor node or behind a firewall. This approach
1504 requires an observer to separate traffic originating at the onion
1505 router from traffic passing through it: a global observer can do this,
1506 but it might be beyond a limited observer's capabilities.
1510 will also be effective in confirming
1511 endpoints of a stream. However, even without padding, we may have some
1512 limited protection: the leaky pipe topology means different numbers
1513 of packets may enter one end of a circuit than exit at the other.
1517 attacks above are traffic confirmation attacks,
1518 which puts them outside our design goals. There is also
1519 a passive traffic analysis attack that is potentially effective.
1520 Rather than searching exit connections for timing and volume
1521 correlations, the adversary may build up a database of
1522 "fingerprints" containing file sizes and access patterns for
1523 targeted websites. He can later confirm a user's connection to a given
1524 site simply by consulting the database. This attack has
1525 been shown to be effective against SafeWeb [<a href="#hintz-pet02" name="CITEhintz-pet02">29</a>].
1526 It may be less effective against Tor, since
1527 streams are multiplexed within the same circuit, and
1528 fingerprinting will be limited to
1529 the granularity of cells (currently 512 bytes). Additional
1530 defenses could include
1531 larger cell sizes, padding schemes to group websites
1532 into large sets, and link
1538 see control cells and encrypted relay cells on every circuit on that
1539 connection; learning a circuit
1540 session key lets him unwrap one layer of the encryption. An attacker
1541 who learns an OR's TLS private key can impersonate that OR for the TLS
1542 key's lifetime, but he must
1544 perfect forward secrecy, he cannot hijack already established circuits
1545 without also compromising their session keys). Periodic key rotation
1546 limits the window of opportunity for these attacks. On the other hand,
1547 an attacker who learns a node's identity key can replace that node
1548 indefinitely by sending new forged descriptors to the directory servers.
1552 compromise ORs (by system intrusion, legal coercion, or extralegal
1553 coercion) could march down the circuit compromising the
1554 nodes until he reaches the end. Unless the adversary can complete
1555 this attack within the lifetime of the circuit, however, the ORs
1556 will have discarded the necessary information before the attack can
1557 be completed. (Thanks to the perfect forward secrecy of session
1558 keys, the attacker cannot force nodes to decrypt recorded
1559 traffic once the circuits have been closed.) Additionally, building
1560 circuits that cross jurisdictions can make legal coercion
1561 harder-this phenomenon is commonly called "jurisdictional
1562 arbitrage." The Java Anon Proxy project recently experienced the
1563 need for this approach, when
1564 a German court forced them to add a backdoor to
1569 trivially learns the timing patterns of users connecting to it, and
1570 can introduce arbitrary patterns in its responses.
1571 End-to-end attacks become easier: if the adversary can induce
1572 users to connect to his webserver (perhaps by advertising
1573 content targeted to those users), he now holds one end of their
1574 connection. There is also a danger that application
1575 protocols and associated programs can be induced to reveal information
1576 about the initiator. Tor depends on Privoxy and similar protocol cleaners
1577 to solve this latter problem.
1581 nearly always run their own local onion proxy. However, in some
1582 settings, it may be necessary for the proxy to run
1583 remotely-typically, in institutions that want
1584 to monitor the activity of those connecting to the proxy.
1585 Compromising an onion proxy compromises all future connections
1586 through it.
1590 of the Tor network can increase the value of this traffic
1591 by attacking non-observed nodes to shut them down, reduce
1592 their reliability, or persuade users that they are not trustworthy.
1593 The best defense here is robustness.
1597 an isolated hostile node can create circuits through itself, or alter
1598 traffic patterns to affect traffic at other nodes. Nonetheless, a hostile
1599 node must be immediately adjacent to both endpoints to compromise the
1600 anonymity of a circuit. If an adversary can
1601 run multiple ORs, and can persuade the directory servers
1602 that those ORs are trustworthy and independent, then occasionally
1603 some user will choose one of those ORs for the start and another
1604 as the end of a circuit. If an adversary
1607 adversary
1608 could still attract a disproportionately large amount of traffic
1609 by running an OR with a permissive exit policy, or by
1610 degrading the reliability of other routers.
1614 version of passive timing attacks already discussed earlier.
1618 cell by altering it. If the
1619 stream were, for example, an unencrypted request to a Web site,
1620 the garbled content coming out at the appropriate time would confirm
1621 the association. However, integrity checks on cells prevent
1622 this attack.
1626 relaying an unauthenticated protocol like HTTP, a hostile exit node
1627 can impersonate the target server. Clients
1628 should prefer protocols with end-to-end authentication.
1632 to replay attacks. Tor is not; replaying one side of a handshake
1633 will result in a different negotiated session key, and so the rest
1634 of the recorded session can't be used.
1638 socially disapproved acts, to bring the
1639 network into disrepute and get its operators to shut it down.
1640 Exit policies reduce the possibilities for abuse, but
1641 ultimately the network requires volunteers who can tolerate
1642 some political heat.
1646 into running subverted Tor software that did not, in fact, anonymize
1647 their connections-or worse, could trick ORs into running weakened
1648 software that provided users with less anonymity. We address this
1649 problem (but do not solve it completely) by signing all Tor releases
1650 with an official public key, and including an entry in the directory
1651 that lists which versions are currently believed to be secure. To
1652 prevent an attacker from subverting the official release itself
1653 (through threats, bribery, or insider attacks), we provide all
1654 releases in source code form, encourage source audits, and
1655 frequently warn our users never to trust any software (even from
1656 us) that comes without source.<br />
1661 servers disappear, the others still decide on a valid
1662 directory. So long as any directory servers remain in operation,
1663 they will still broadcast their views of the network and generate a
1664 consensus directory. (If more than half are destroyed, this
1665 directory will not, however, have enough signatures for clients to
1666 use it automatically; human intervention will be necessary for
1667 clients to decide whether to trust the resulting directory.)
1671 an attacker can partially influence the final directory. Since ORs
1672 are included or excluded by majority vote, the corrupt directory can
1673 at worst cast a tie-breaking vote to decide whether to include
1674 marginal ORs. It remains to be seen how often such marginal cases
1675 occur in practice.
1679 more than half the directory servers can include as many compromised
1680 ORs in the final directory as he wishes. We must ensure that directory
1681 server operators are independent and attack-resistant.
1685 agreement protocol assumes that directory server operators agree on
1686 the set of directory servers. An adversary who can persuade some
1687 of the directory server operators to distrust one another could
1688 split the quorum into mutually hostile camps, thus partitioning
1689 users based on which directory they use. Tor does not address
1690 this attack.
1694 Our threat model explicitly assumes directory server operators will
1695 be able to filter out most hostile ORs.
1698 <em>Convince the directories that a malfunctioning OR is
1699 working.</em> In the current Tor implementation, directory servers
1700 assume that an OR is running correctly if they can start a TLS
1701 connection to it. A hostile OR could easily subvert this test by
1702 accepting TLS connections from ORs but ignoring all cells. Directory
1703 servers must actively test ORs by building circuits and streams as
1704 appropriate. The tradeoffs of a similar approach are discussed
1710 try to deny Bob service by flooding his introduction points with
1711 requests. Because the introduction points can block requests that
1712 lack authorization tokens, however, Bob can restrict the volume of
1713 requests he receives, or require a certain amount of computation for
1714 every request he receives.
1718 disrupt a location-hidden service by disabling its introduction
1719 points. But because a service's identity is attached to its public
1720 key, the service can simply re-advertise
1721 itself at a different introduction point. Advertisements can also be
1722 done secretly so that only high-priority clients know the address of
1723 Bob's introduction points or so that different clients know of different
1724 introduction points. This forces the attacker to disable all possible
1725 introduction points.
1729 Bob's introduction point can flood Bob with
1730 introduction requests, or prevent valid introduction requests from
1731 reaching him. Bob can notice a flood, and close the circuit. To notice
1732 blocking of valid requests, however, he should periodically test the
1733 introduction point by sending rendezvous requests and making
1734 sure he receives them.
1738 point is no more sensitive than any other OR on
1739 a circuit, since all data passing through the rendezvous is encrypted
1740 with a session key shared by Alice and Bob.
1746 </a>
1751 matures. (For comparison, the current remailer network
1753 many have 10Mb. The number of users varies (and of course, it's hard to
1754 tell for sure), but we sometimes have several hundred users-administrators at
1755 several companies have begun sending their entire departments' web
1756 traffic through Tor, to block other divisions of
1757 their company from reading their traffic. Tor users have reported using
1758 the network for web browsing, FTP, IRC, AIM, Kazaa, SSH, and
1759 recipient-anonymous email via rendezvous points. One user has anonymously
1760 set up a Wiki as a hidden service, where other users anonymously publish
1761 the addresses of their hidden services.
1765 cells (a bit under half a gigabyte) per week. On average, about 80%
1766 of each 498-byte payload is full for cells going back to the client,
1767 whereas about 40% is full for cells coming from the client. (The difference
1768 arises because most of the network's traffic is web browsing.) Interactive
1769 traffic like SSH brings down the average a lot-once we have more
1770 experience, and assuming we can resolve the anonymity issues, we may
1771 partition traffic into two relay cell sizes: one to handle
1772 bulk traffic and one for interactive traffic.
1775 Based in part on our restrictive default exit policy (we
1776 reject SMTP requests) and our low profile, we have had no abuse
1777 issues since the network was deployed in October
1778 2003. Our slow growth rate gives us time to add features,
1779 resolve bugs, and get a feel for what users actually want from an
1780 anonymity system. Even though having more users would bolster our
1781 anonymity sets, we are not eager to attract the Kazaa or warez
1782 communities-we feel that we must build a reputation for privacy, human
1783 rights, research, and other socially laudable activities.
1786 As for performance, profiling shows that Tor spends almost
1787 all its CPU time in AES, which is fast. Current latency is attributable
1788 to two factors. First, network latency is critical: we are
1789 intentionally bouncing traffic around the world several times. Second,
1790 our end-to-end congestion control algorithm focuses on protecting
1791 volunteer servers from accidental DoS rather than on optimizing
1792 performance. To quantify these effects, we did some informal tests using a network of 4
1796 direct download. We ran a similar test on the production Tor network,
1798 while a direct
1799 download consistently took about 0.3s, the performance through Tor varied.
1802 of building a slow circuit (one that includes a slow or heavily loaded node
1803 or link) is increasing. On the other hand, as our users remain satisfied
1804 with this increased latency, we can address our performance incrementally as we
1805 proceed with development.
1811 Although Tor's clique topology and full-visibility directories present
1812 scaling problems, we still expect the network to support a few hundred
1814 more distributed. With luck, the experience we gain running the current
1815 topology will help us choose among alternatives when the time comes.
1821 </a>
1824 In addition to the non-goals in
1826 before we can be confident of Tor's security.
1829 Many of these open issues are questions of balance. For example,
1830 how often should users rotate to fresh circuits? Frequent rotation
1831 is inefficient, expensive, and may lead to intersection attacks and
1832 predecessor attacks [<a href="#wright03" name="CITEwright03">54</a>], but infrequent rotation makes the
1833 user's traffic linkable. Besides opening fresh circuits, clients can
1834 also exit from the middle of the circuit,
1835 or truncate and re-extend the circuit. More analysis is
1836 needed to determine the proper tradeoff.
1841 How should we choose path lengths? If Alice always uses two hops,
1842 then both ORs can be certain that by colluding they will learn about
1843 Alice and Bob. In our current approach, Alice always chooses at least
1844 three nodes unrelated to herself and her destination.
1845 Should Alice choose a random path length (e.g. from a geometric
1846 distribution) to foil an attacker who
1847 uses timing to learn that he is the fifth hop and thus concludes that
1848 both Alice and the responder are running ORs?
1851 Throughout this paper, we have assumed that end-to-end traffic
1852 confirmation will immediately and automatically defeat a low-latency
1853 anonymity system. Even high-latency anonymity systems can be
1854 vulnerable to end-to-end traffic confirmation, if the traffic volumes
1855 are high enough, and if users' habits are sufficiently
1856 distinct [<a href="#statistical-disclosure" name="CITEstatistical-disclosure">14</a>,<a href="#limits-open" name="CITElimits-open">31</a>]. Can anything be
1857 done to
1858 make low-latency systems resist these attacks as well as high-latency
1859 systems? Tor already makes some effort to conceal the starts and ends of
1860 streams by wrapping long-range control commands in identical-looking
1861 relay cells. Link padding could frustrate passive observers who count
1862 packets; long-range padding could work against observers who own the
1863 first hop in a circuit. But more research remains to find an efficient
1864 and practical approach. Volunteers prefer not to run constant-bandwidth
1865 padding; but no convincing traffic shaping approach has been
1866 specified. Recent work on long-range padding [<a href="#defensive-dropping" name="CITEdefensive-dropping">33</a>]
1867 shows promise. One could also try to reduce correlation in packet timing
1868 by batching and re-ordering packets, but it is unclear whether this could
1869 improve anonymity without introducing so much latency as to render the
1870 network unusable.
1873 A cascade topology may better defend against traffic confirmation by
1874 aggregating users, and making padding and
1875 mixing more affordable. Does the hydra topology (many input nodes,
1876 few output nodes) work better against some adversaries? Are we going
1877 to get a hydra anyway because most nodes will be middleman nodes?
1880 Common wisdom suggests that Alice should run her own OR for best
1881 anonymity, because traffic coming from her node could plausibly have
1882 come from elsewhere. How much mixing does this approach need? Is it
1883 immediately beneficial because of real-world adversaries that can't
1884 observe Alice's router, but can run routers of their own?
1887 To scale to many users, and to prevent an attacker from observing the
1888 whole network, it may be necessary
1889 to support far more servers than Tor currently anticipates.
1890 This introduces several issues. First, if approval by a central set
1891 of directory servers is no longer feasible, what mechanism should be used
1892 to prevent adversaries from signing up many colluding servers? Second,
1893 if clients can no longer have a complete picture of the network,
1894 how can they perform discovery while preventing attackers from
1895 manipulating or exploiting gaps in their knowledge? Third, if there
1896 are too many servers for every server to constantly communicate with
1897 every other, which non-clique topology should the network use?
1898 (Restricted-route topologies promise comparable anonymity with better
1899 scalability [<a href="#danezis-pets03" name="CITEdanezis-pets03">13</a>], but whatever topology we choose, we
1900 need some way to keep attackers from manipulating their position within
1901 it [<a href="#casc-rep" name="CITEcasc-rep">21</a>].) Fourth, if no central authority is tracking
1902 server reliability, how do we stop unreliable servers from making
1903 the network unusable? Fifth, do clients receive so much anonymity
1904 from running their own ORs that we should expect them all to do
1905 so [<a href="#econymics" name="CITEeconymics">1</a>], or do we need another incentive structure to
1906 motivate them? Tarzan and MorphMix present possible solutions.
1911 When a Tor node goes down, all its circuits (and thus streams) must break.
1912 Will users abandon the system because of this brittleness? How well
1914 node failure? If affected users rebuild circuits immediately, how much
1915 anonymity is lost? It seems the problem is even worse in a peer-to-peer
1916 environment-such systems don't yet provide an incentive for peers to
1917 stay connected when they're done retrieving content, so we would expect
1918 a higher churn rate.
1926 </a>
1929 Tor brings together many innovations into a unified deployable system. The
1930 next immediate steps include:
1934 has led us to adopt a clique topology, semi-centralized
1935 directories, and a full-network-visibility model for client
1936 knowledge. These properties will not scale past a few hundred servers.
1938 approaches, but more deployment experience will be helpful in learning
1939 the relative importance of these bottlenecks.
1943 good bandwidth and latency. We should instead adopt the MorphMix model,
1944 where nodes advertise their bandwidth level (DSL, T1, T3), and
1945 Alice avoids bottlenecks by choosing nodes that match or
1946 exceed her bandwidth. In this way DSL users can usefully join the Tor
1947 network.
1951 and possibly better anonymity [<a href="#econymics" name="CITEeconymics">1</a>]. More nodes means increased
1952 scalability, and more users can mean more anonymity. We need to continue
1953 examining the incentive structures for participating in Tor. Further,
1954 we need to explore more approaches to limiting abuse, and understand
1955 why most people don't bother using privacy systems.
1959 in performance and bandwidth are clear but its security benefits are
1960 not well understood. We must pursue more research on link-level cover
1961 traffic and long-range cover traffic to determine whether some simple padding
1962 method offers provable protection against our chosen adversary.
1968 caching web proxy [<a href="#shsm03" name="CITEshsm03">47</a>], to improve anonymity for cached pages
1969 (Alice's request never
1970 leaves the Tor network), to improve speed, and to reduce bandwidth cost.
1971 On the other hand, forward security is weakened because caches
1972 constitute a record of retrieved files. We must find the right
1973 balance between usability and security.
1977 Clients currently download a description of
1978 the entire network every 15 minutes. As the state grows larger
1979 and clients more numerous, we may need a solution in which
1980 clients receive incremental updates to directory state.
1981 More generally, we must find more
1982 scalable yet practical ways to distribute up-to-date snapshots of
1983 network status without introducing new attacks.
1988 external review. We hope that as Tor
1989 is deployed, more people will examine its
1990 specification.
1994 designer of MorphMix to unify the specification and implementation of
1995 the common elements of our two systems. So far, this seems
1996 to be relatively straightforward. Interoperability will allow testing
1997 and direct comparison of the two designs for trust and scalability.
2001 gain experience in deploying an anonymizing overlay network, and
2002 learn from having actual users. We are now at a point in design
2003 and development where we can start deploying a wider network. Once
2004 we have many actual users, we will doubtlessly be better
2005 able to evaluate some of our design decisions, including our
2006 robustness/latency tradeoffs, our performance tradeoffs (including
2007 cell size), our abuse-prevention mechanisms, and
2008 our overall usability.
2015 We thank Peter Palfrader, Geoff Goodell, Adam Shostack, Joseph Sokol-Margolis,
2016 John Bashinski, and Zack Brown
2017 for editing and comments;
2018 Matej Pfajfar, Andrei Serjantov, Marc Rennhard for design discussions;
2019 Bram Cohen for congestion control discussions;
2020 Adam Back for suggesting telescoping circuits; and
2022 This work has been supported by ONR and DARPA.
2034 On the economics of anonymity.
2039 </dd>
2041 R. Anderson.
2042 The eternity service.
2046 </dd>
2048 The Anonymizer.
2052 </tt></dd>
2055 Freedom systems 2.1 security issues and analysis.
2056 White paper, Zero Knowledge Systems, Inc., May 2001.
2059 </dd>
2062 Traffic analysis attacks and trade-offs in anonymity providing
2063 systems.
2068 </dd>
2071 The EAX mode of operation: A two-pass authenticated-encryption
2072 scheme optimized for simplicity and efficiency.
2076 </dd>
2079 Web MIXes: A system for anonymous and unobservable Internet
2080 access.
2082 Technologies: Workshop on Design Issue in Anonymity and Unobservability</em>.
2086 </dd>
2089 Freedom systems 2.0 architecture.
2090 White paper, Zero Knowledge Systems, Inc., December 2000.
2093 </dd>
2095 Z. Brown.
2096 Cebolla: Pragmatic IP Anonymity.
2100 </dd>
2102 D. Chaum.
2103 Untraceable electronic mail, return addresses, and digital
2104 pseudo-nyms.
2108 </dd>
2111 Wide-area cooperative storage with CFS.
2116 </dd>
2118 W. Dai.
2119 Pipenet 1.1.
2120 Usenet post, August 1996.
2125 </tt></dd>
2127 G. Danezis.
2128 Mix-networks with restricted routes.
2133 </dd>
2135 G. Danezis.
2136 Statistical disclosure attacks.
2141 </dd>
2144 Mixminion: Design of a type III anonymous remailer protocol.
2146 IEEE CS, May 2003.
2149 </dd>
2152 Using Client Puzzles to Protect TLS.
2154 Aug. 2001.
2157 </dd>
2160 The TLS Protocol - Version 1.0.
2164 </dd>
2167 A Reputation System to Increase MIX-net Reliability.
2172 </dd>
2175 The free haven project: Distributed anonymous storage service.
2177 Technologies: Workshop on Design Issue in Anonymity and Unobservability</em>.
2181 </dd>
2184 Tor protocol specifications.
2188 </tt></dd>
2191 Reliable MIX Cascade Networks through Reputation.
2196 </dd>
2198 J. Douceur.
2199 The Sybil Attack.
2204 </dd>
2207 MIXes in mobile communication systems: Location management with
2208 privacy.
2213 </dd>
2216 Tarzan: A peer-to-peer anonymizing network layer.
2221 </dd>
2224 Herbivore: A scalable and efficient protocol for anonymous
2225 communication.
2226 Technical Report TR2003-1890, Cornell University Computing and
2227 Information Science, February 2003.
2230 </dd>
2232 I. Goldberg.
2234 PhD thesis, UC Berkeley, Dec 2000.
2237 </dd>
2240 Hiding routing information.
2245 </dd>
2248 Mixing E-mail with Babel.
2253 </dd>
2255 A. Hintz.
2256 Fingerprinting websites using traffic analysis.
2261 </dd>
2263 A. Jerichow, J. Müller, A. Pfitzmann, B. Pfitzmann, and M. Waidner.
2264 Real-time mixes: A bandwidth-efficient anonymity protocol.
2269 </dd>
2272 Limits of anonymity in open environments.
2277 </dd>
2280 SOCKS.
2285 </dd>
2288 Timing analysis in low-latency mix-based systems.
2290 LNCS (forthcoming), 2004.
2293 </dd>
2296 Hordes: A multicast-based protocol for anonymity.
2300 </dd>
2302 C. Meadows.
2303 The NRL protocol analyzer: An overview.
2307 </dd>
2310 Mixmaster Protocol - Version 2.
2311 Draft, July 2003.
2315 </tt></dd>
2318 The Dark Side of the Web: An Open Proxy's View.
2322 </tt></dd>
2325 ISDN-mixes: Untraceable communication with very small bandwidth
2326 overhead.
2331 </dd>
2333 Privoxy.
2337 </tt></dd>
2340 Protocols using anonymous connections: Mobile applications.
2346 </dd>
2349 Anonymous connections and onion routing.
2354 </dd>
2357 Crowds: Anonymity for web transactions.
2361 </dd>
2364 Practical anonymity for the masses with morphmix.
2366 LNCS (forthcoming), 2004.
2369 </dd>
2372 Analysis of an Anonymity Network for Web Browsing.
2377 </dd>
2380 Passive attack analysis for connection-based anonymity systems.
2385 </dd>
2390 CS, 2002.
2393 </dd>
2396 Using caching for browsing anonymity.
2400 </dd>
2403 Onion Routing access configurations.
2404 In <em>DARPA Information Survivability Conference and Exposition
2408 </dd>
2411 Towards an Analysis of Onion Routing Security.
2413 Technologies: Workshop on Design Issue in Anonymity and Unobservability</em>,
2417 </dd>
2419 A. Tannenbaum.
2420 Computer networks, 1996.
2423 </dd>
2425 The AN.ON Project.
2426 German police proceeds against anonymity service.
2427 Press release, September 2003.
2432 </tt></dd>
2435 Tangler: A censorship-resistant publishing system based on document
2436 entanglements.
2441 </dd>
2444 Publius: A robust, tamper-evident, censorship-resistant and
2445 source-anonymous web publishing system.
2447 2000.
2450 </dd>
2453 Defending anonymous communication against passive logging attacks.
2456 </dl>
2463 <a name="tthFtNtAAB"></a><a href="#tthFrefAAB"><sup>1</sup></a>Actually, the negotiated key is used to derive two
2464 symmetric keys: one for each direction.
2467 With 48 bits of digest per cell, the probability of an accidental
2468 collision is far lower than the chance of hardware failure.
2471 Rather than rely on an external infrastructure, the Onion Routing network
2472 can run the lookup service itself. Our current implementation provides a
2473 simple lookup system on the
2474 directory servers.
2477 attack should not be confused with the much more complicated latency
2478 attacks of [<a href="#back01" name="CITEback01">5</a>], which require a fingerprint of the latencies
2479 of all circuits through the network, combined with those from the
2480 network edges to the target user and the responder website.
2481 <br /><br /><hr /><small>File translated from
2486 </body></html>