diff options
| author | Roger Dingledine <arma@torproject.org> | 2007-05-12 02:29:10 +0000 |
|---|---|---|
| committer | Roger Dingledine <arma@torproject.org> | 2007-05-12 02:29:10 +0000 |
| commit | 6c7ae20ca8f04a9a8377cb799afd59044be16dff (patch) | |
| tree | adff49bd0efdf9b1bd684403eb75734a7913476d /doc/design-paper/tor-design.html | |
| parent | 7218188157864f1a433f8d28ee3360a3d84fd6eb (diff) | |
| download | tor-6c7ae20ca8f04a9a8377cb799afd59044be16dff.tar tor-6c7ae20ca8f04a9a8377cb799afd59044be16dff.tar.gz | |
a bit of that manual hacking for tor-design.html too
svn:r10169
Diffstat (limited to 'doc/design-paper/tor-design.html')
| -rw-r--r-- | doc/design-paper/tor-design.html | 96 |
1 files changed, 49 insertions, 47 deletions
diff --git a/doc/design-paper/tor-design.html b/doc/design-paper/tor-design.html index 66d464dc2..5fac644e6 100644 --- a/doc/design-paper/tor-design.html +++ b/doc/design-paper/tor-design.html @@ -49,8 +49,8 @@ more than 30 nodes. We close with a list of open problems in anonymous communica <div class="p"><!----></div> <h2><a name="tth_sEc1"> -1</a> Overview</h2> <a name="sec:intro"> +1</a> Overview</h2> </a> <div class="p"><!----></div> @@ -92,7 +92,7 @@ extending to a new node. <div class="p"><!----></div> <b>Separation of "protocol cleaning" from anonymity:</b> Onion Routing originally required a separate "application -proxy" for each supported application protocol-most of which were +proxy" for each supported application protocol — most of which were never written, so many applications were never supported. Tor uses the standard and near-ubiquitous SOCKS [<a href="#socks4" name="CITEsocks4">32</a>] proxy interface, allowing us to support most TCP-based programs without modification. Tor now @@ -130,7 +130,7 @@ streams along each circuit to improve efficiency and anonymity. <b>Leaky-pipe circuit topology:</b> Through in-band signaling within the circuit, Tor initiators can direct traffic to nodes partway down the circuit. This novel approach -allows traffic to exit the circuit from the middle-possibly +allows traffic to exit the circuit from the middle — possibly frustrating traffic shape and volume attacks based on observing the end of the circuit. (It also allows for long-range padding if future research shows this to be worthwhile.) @@ -146,7 +146,7 @@ or flooding and send less data until the congestion subsides. <div class="p"><!----></div> <b>Directory servers:</b> The earlier Onion Routing design -planned to flood state information through the network-an approach +planned to flood state information through the network — an approach that can be unreliable and complex. Tor takes a simplified view toward distributing this information. Certain more trusted nodes act as <em>directory servers</em>: they provide signed directories describing known @@ -164,7 +164,7 @@ from his node. <div class="p"><!----></div> <b>End-to-end integrity checking:</b> The original Onion Routing design did no integrity checking on data. Any node on the -circuit could change the contents of data cells as they passed by-for +circuit could change the contents of data cells as they passed by — for example, to alter a connection request so it would connect to a different webserver, or to `tag' encrypted traffic and look for corresponding corrupted traffic at the network edges [<a href="#minion-design" name="CITEminion-design">15</a>]. @@ -218,8 +218,8 @@ Routing project in Section <a href="#sec:conclusion">10</a>. <div class="p"><!----></div> <h2><a name="tth_sEc2"> -2</a> Related work</h2> <a name="sec:related-work"> +2</a> Related work</h2> </a> <div class="p"><!----></div> @@ -377,8 +377,8 @@ Eternity and Free Haven. <div class="p"><!----></div> <h2><a name="tth_sEc3"> -3</a> Design goals and assumptions</h2> <a name="sec:assumptions"> +3</a> Design goals and assumptions</h2> </a> <div class="p"><!----></div> @@ -404,7 +404,7 @@ this goal for non-anonymous users talking to hidden servers, however; see Section <a href="#sec:rendezvous">5</a>.) <div class="p"><!----></div> -<b>Usability:</b> A hard-to-use system has fewer users-and because +<b>Usability:</b> A hard-to-use system has fewer users — and because anonymity systems hide users among users, a system with fewer users provides less anonymity. Usability is thus not only a convenience: it is a security requirement [<a href="#econymics" name="CITEeconymics">1</a>,<a href="#back01" name="CITEback01">5</a>]. Tor should @@ -474,8 +474,8 @@ to the network. <div class="p"><!----></div> <h3><a name="tth_sEc3.1"> -3.1</a> Threat Model</h3> <a name="subsec:threat-model"> +3.1</a> Threat Model</h3> </a> <div class="p"><!----></div> @@ -504,7 +504,7 @@ which points in the network he should attack. Our adversary might try to link an initiator Alice with her communication partners, or try to build a profile of Alice's behavior. He might mount passive attacks by observing the network edges -and correlating traffic entering and leaving the network-by +and correlating traffic entering and leaving the network — by relationships in packet timing, volume, or externally visible user-selected options. The adversary can also mount active attacks by compromising @@ -516,7 +516,7 @@ network stops; or by introducing patterns into traffic that can later be detected. The adversary might subvert the directory servers to give users differing views of network state. Additionally, he can try to decrease the network's reliability by attacking nodes or by performing antisocial -activities from reliable nodes and trying to get them taken down-making +activities from reliable nodes and trying to get them taken down — making the network unreliable flushes users to other less anonymous systems, where they may be easier to attack. We summarize in Section <a href="#sec:attacks">7</a> how well the Tor design defends against @@ -526,8 +526,8 @@ each of these attacks. <div class="p"><!----></div> <h2><a name="tth_sEc4"> -4</a> The Tor Design</h2> <a name="sec:design"> +4</a> The Tor Design</h2> </a> <div class="p"><!----></div> @@ -570,8 +570,8 @@ fairness issues. <div class="p"><!----></div> <h3><a name="tth_sEc4.1"> -4.1</a> Cells</h3> <a name="subsec:cells"> +4.1</a> Cells</h3> </a> <div class="p"><!----></div> @@ -627,8 +627,8 @@ in more detail below. </center> <div class="p"><!----></div> <h3><a name="tth_sEc4.2"> -4.2</a> Circuits and streams</h3> <a name="subsec:circuits"> +4.2</a> Circuits and streams</h3> </a> <div class="p"><!----></div> @@ -662,8 +662,9 @@ without harming user experience.<br /> </a> </center> <div class="p"><!----></div> -<font size="+1"><b>Constructing a circuit</b></font><a name="subsubsec:constructing-a-circuit"> -</a><br /> +<a name="subsubsec:constructing-a-circuit"></a> +<font size="+1"><b>Constructing a circuit</b></font> +<br /> A user's OP constructs circuits incrementally, negotiating a symmetric key with each OR on the circuit, one hop at a time. To begin creating a new circuit, the OP (call her Alice) sends a @@ -704,7 +705,7 @@ extend one hop further. <div class="p"><!----></div> This circuit-level handshake protocol achieves unilateral entity authentication (Alice knows she's handshaking with the OR, but -the OR doesn't care who is opening the circuit-Alice uses no public key +the OR doesn't care who is opening the circuit — Alice uses no public key and remains anonymous) and unilateral key authentication (Alice and the OR agree on a key, and Alice knows only the OR learns it). It also achieves forward @@ -797,8 +798,8 @@ attack [<a href="#freedom21-security" name="CITEfreedom21-security">4</a>] <div class="p"><!----></div> <h3><a name="tth_sEc4.3"> -4.3</a> Opening and closing streams</h3> <a name="subsec:tcp"> +4.3</a> Opening and closing streams</h3> </a> <div class="p"><!----></div> @@ -818,7 +819,7 @@ now accepts data from the application's TCP stream, packaging it into the chosen OR. <div class="p"><!----></div> -There's a catch to using SOCKS, however-some applications pass the +There's a catch to using SOCKS, however — some applications pass the alphanumeric hostname to the Tor client, while others resolve it into an IP address first and then pass the IP address to the Tor client. If the application does DNS resolution first, Alice thereby reveals her @@ -855,8 +856,8 @@ connections. <div class="p"><!----></div> <h3><a name="tth_sEc4.4"> -4.4</a> Integrity checking on streams</h3> <a name="subsec:integrity-checking"> +4.4</a> Integrity checking on streams</h3> </a> <div class="p"><!----></div> @@ -920,8 +921,8 @@ receive a bad hash. <div class="p"><!----></div> <h3><a name="tth_sEc4.5"> -4.5</a> Rate limiting and fairness</h3> <a name="subsec:rate-limit"> +4.5</a> Rate limiting and fairness</h3> </a> <div class="p"><!----></div> @@ -955,8 +956,8 @@ attacks. <div class="p"><!----></div> <h3><a name="tth_sEc4.6"> -4.6</a> Congestion control</h3> <a name="subsec:congestion"> +4.6</a> Congestion control</h3> </a> <div class="p"><!----></div> @@ -1018,8 +1019,8 @@ and delay; see Section <a href="#sec:in-the-wild">8</a>. <div class="p"><!----></div> <h2><a name="tth_sEc5"> -5</a> Rendezvous Points and hidden services</h2> <a name="sec:rendezvous"> +5</a> Rendezvous Points and hidden services</h2> </a> <div class="p"><!----></div> @@ -1144,7 +1145,7 @@ those users can switch to accessing Bob's service via the Tor rendezvous system. <div class="p"><!----></div> -Bob's introduction points are themselves subject to DoS-he must +Bob's introduction points are themselves subject to DoS — he must open many introduction points or risk such an attack. He can provide selected users with a current list or future schedule of unadvertised introduction points; @@ -1170,7 +1171,7 @@ by the hash of his public key. Bob's webserver is unmodified, and doesn't even know that it's hidden behind the Tor network. <div class="p"><!----></div> -Alice's applications also work unchanged-her client interface +Alice's applications also work unchanged — her client interface remains a SOCKS proxy. We encode all of the necessary information into the fully qualified domain name (FQDN) Alice uses when establishing her connection. Location-hidden services use a virtual top level domain @@ -1205,20 +1206,20 @@ service, to encourage volunteers to offer introduction and rendezvous services. Tor's introduction points do not output any bytes to the clients; the rendezvous points don't know the client or the server, and can't read the data being transmitted. The indirection scheme is -also designed to include authentication/authorization-if Alice doesn't +also designed to include authentication/authorization — if Alice doesn't include the right cookie with her request for service, Bob need not even acknowledge his existence. <div class="p"><!----></div> <h2><a name="tth_sEc6"> -6</a> Other design decisions</h2> <a name="sec:other-design"> +6</a> Other design decisions</h2> </a> <div class="p"><!----></div> <h3><a name="tth_sEc6.1"> -6.1</a> Denial of service</h3> <a name="subsec:dos"> +6.1</a> Denial of service</h3> </a> <div class="p"><!----></div> @@ -1270,8 +1271,8 @@ extra complexity still require investigation. <div class="p"><!----></div> <h3><a name="tth_sEc6.2"> -6.2</a> Exit policies and abuse</h3> <a name="subsec:exitpolicies"> +6.2</a> Exit policies and abuse</h3> </a> <div class="p"><!----></div> @@ -1304,7 +1305,7 @@ nodes that will connect anywhere. On the other end are <em>middleman</em> nodes that only relay traffic to other Tor nodes, and <em>private exit</em> nodes that only connect to a local host or network. A private exit can allow a client to connect to a given host or -network more securely-an external adversary cannot eavesdrop traffic +network more securely — an external adversary cannot eavesdrop traffic between the private exit and the final destination, and so is less sure of Alice's destination and activities. Most onion routers in the current network function as @@ -1348,7 +1349,7 @@ an adversary needs to monitor for traffic analysis, and places a greater burden on the exit nodes. This tension can be seen in the Java Anon Proxy cascade model, wherein only one node in each cascade needs to handle -abuse complaints-but an adversary only needs to observe the entry +abuse complaints — but an adversary only needs to observe the entry and exit of a cascade to perform traffic analysis on all that cascade's users. The hydra model (many entries, few exits) presents a different compromise: only a few exit nodes are needed, but an @@ -1367,8 +1368,8 @@ project [<a href="#darkside" name="CITEdarkside">37</a>] give us a glimpse <div class="p"><!----></div> <h3><a name="tth_sEc6.3"> -6.3</a> Directory Servers</h3> <a name="subsec:dirservers"> +6.3</a> Directory Servers</h3> </a> <div class="p"><!----></div> @@ -1403,7 +1404,7 @@ to bootstrap each client's view of the network. <div class="p"><!----></div> When a directory server receives a signed statement for an OR, it checks whether the OR's identity key is recognized. Directory -servers do not advertise unrecognized ORs-if they did, +servers do not advertise unrecognized ORs — if they did, an adversary could take over the network by creating many servers [<a href="#sybil" name="CITEsybil">22</a>]. Instead, new nodes must be approved by the directory @@ -1414,7 +1415,7 @@ in Section <a href="#sec:maintaining-anonymity">9</a>. <div class="p"><!----></div> Of course, a variety of attacks remain. An adversary who controls a directory server can track clients by providing them different -information-perhaps by listing only nodes under its control, or by +information — perhaps by listing only nodes under its control, or by informing only certain clients about a given node. Even an external adversary can exploit differences in client knowledge: clients who use a node listed on one directory server but not the others are vulnerable. @@ -1460,8 +1461,8 @@ central point. <div class="p"><!----></div> <h2><a name="tth_sEc7"> -7</a> Attacks and Defenses</h2> <a name="sec:attacks"> +7</a> Attacks and Defenses</h2> </a> <div class="p"><!----></div> @@ -1558,7 +1559,7 @@ be completed. (Thanks to the perfect forward secrecy of session keys, the attacker cannot force nodes to decrypt recorded traffic once the circuits have been closed.) Additionally, building circuits that cross jurisdictions can make legal coercion -harder-this phenomenon is commonly called "jurisdictional +harder — this phenomenon is commonly called "jurisdictional arbitrage." The Java Anon Proxy project recently experienced the need for this approach, when a German court forced them to add a backdoor to @@ -1580,7 +1581,7 @@ to solve this latter problem. <em>Run an onion proxy.</em> It is expected that end users will nearly always run their own local onion proxy. However, in some settings, it may be necessary for the proxy to run -remotely-typically, in institutions that want +remotely — typically, in institutions that want to monitor the activity of those connecting to the proxy. Compromising an onion proxy compromises all future connections through it. @@ -1603,7 +1604,7 @@ that those ORs are trustworthy and independent, then occasionally some user will choose one of those ORs for the start and another as the end of a circuit. If an adversary controls m > 1 of N nodes, he can correlate at most -([m/N])<sup>2</sup> of the traffic-although an +([m/N])<sup>2</sup> of the traffic — although an adversary could still attract a disproportionately large amount of traffic by running an OR with a permissive exit policy, or by @@ -1644,7 +1645,7 @@ some political heat. <div class="p"><!----></div> <em>Distribute hostile code.</em> An attacker could trick users into running subverted Tor software that did not, in fact, anonymize -their connections-or worse, could trick ORs into running weakened +their connections — or worse, could trick ORs into running weakened software that provided users with less anonymity. We address this problem (but do not solve it completely) by signing all Tor releases with an official public key, and including an entry in the directory @@ -1741,8 +1742,8 @@ with a session key shared by Alice and Bob. <div class="p"><!----></div> <h2><a name="tth_sEc8"> -8</a> Early experiences: Tor in the Wild</h2> <a name="sec:in-the-wild"> +8</a> Early experiences: Tor in the Wild</h2> </a> <div class="p"><!----></div> @@ -1751,7 +1752,7 @@ As of mid-May 2004, the Tor network consists of 32 nodes matures. (For comparison, the current remailer network has about 40 nodes.) Each node has at least a 768Kb/768Kb connection, and many have 10Mb. The number of users varies (and of course, it's hard to -tell for sure), but we sometimes have several hundred users-administrators at +tell for sure), but we sometimes have several hundred users — administrators at several companies have begun sending their entire departments' web traffic through Tor, to block other divisions of their company from reading their traffic. Tor users have reported using @@ -1766,7 +1767,7 @@ cells (a bit under half a gigabyte) per week. On average, about 80% of each 498-byte payload is full for cells going back to the client, whereas about 40% is full for cells coming from the client. (The difference arises because most of the network's traffic is web browsing.) Interactive -traffic like SSH brings down the average a lot-once we have more +traffic like SSH brings down the average a lot — once we have more experience, and assuming we can resolve the anonymity issues, we may partition traffic into two relay cell sizes: one to handle bulk traffic and one for interactive traffic. @@ -1779,7 +1780,7 @@ issues since the network was deployed in October resolve bugs, and get a feel for what users actually want from an anonymity system. Even though having more users would bolster our anonymity sets, we are not eager to attract the Kazaa or warez -communities-we feel that we must build a reputation for privacy, human +communities — we feel that we must build a reputation for privacy, human rights, research, and other socially laudable activities. <div class="p"><!----></div> @@ -1816,8 +1817,8 @@ topology will help us choose among alternatives when the time comes. <div class="p"><!----></div> <h2><a name="tth_sEc9"> -9</a> Open Questions in Low-latency Anonymity</h2> <a name="sec:maintaining-anonymity"> +9</a> Open Questions in Low-latency Anonymity</h2> </a> <div class="p"><!----></div> @@ -1913,7 +1914,7 @@ Will users abandon the system because of this brittleness? How well does the method in Section <a href="#subsec:dos">6.1</a> allow streams to survive node failure? If affected users rebuild circuits immediately, how much anonymity is lost? It seems the problem is even worse in a peer-to-peer -environment-such systems don't yet provide an incentive for peers to +environment — such systems don't yet provide an incentive for peers to stay connected when they're done retrieving content, so we would expect a higher churn rate. @@ -1921,8 +1922,8 @@ a higher churn rate. <div class="p"><!----></div> <h2><a name="tth_sEc10"> -10</a> Future Directions</h2> <a name="sec:conclusion"> +10</a> Future Directions</h2> </a> <div class="p"><!----></div> @@ -1955,7 +1956,7 @@ we need to explore more approaches to limiting abuse, and understand why most people don't bother using privacy systems. <div class="p"><!----></div> -<em>Cover traffic:</em> Currently Tor omits cover traffic-its costs +<em>Cover traffic:</em> Currently Tor omits cover traffic — its costs in performance and bandwidth are clear but its security benefits are not well understood. We must pursue more research on link-level cover traffic and long-range cover traffic to determine whether some simple padding @@ -2484,3 +2485,4 @@ by <a href="http://hutchinson.belmont.ma.us/tth/"> T<sub><font size="-1">T</font></sub>H</a>, version 3.59.<br />On 18 May 2004, 10:45.</small> </body></html> + |