diff --git a/doc/tor-design.tex b/doc/tor-design.tex index 4b3e9e1564..b9e7a56a45 100644 --- a/doc/tor-design.tex +++ b/doc/tor-design.tex @@ -380,7 +380,7 @@ Eternity and Free~Haven. \Section{Design goals and assumptions} \label{sec:assumptions} -\noindent {\large Goals}\\ +\noindent{\large\bf Goals}\\ Like other low-latency anonymity designs, Tor seeks to frustrate attackers from linking communication partners, or from linking multiple communications to or from a single user. Within this @@ -429,7 +429,7 @@ deployability, readability, and ease of security analysis. Tor aims to deploy a simple and stable system that integrates the best well-understood approaches to protecting anonymity.\\ -\noindent {\large Non-goals}\\ +\noindent{\large\bf Non-goals}\\ \label{subsec:non-goals} In favoring simple, deployable designs, we have explicitly deferred several possible goals, either because they are solved elsewhere, or because @@ -515,11 +515,12 @@ each of these attacks. \Section{The Tor Design} \label{sec:design} -The Tor network is an overlay network; onion routers run as normal -user-level processes without needing any special privileges. +The Tor network is an overlay network; each onion router (OR) +runs as a normal +user-level processes without any special privileges. Each onion router maintains a long-term TLS \cite{TLS} connection to every other onion router. -%(We further discuss this clique-topology assumption in +%(We discuss alternatives to this clique-topology assumption in %Section~\ref{sec:maintaining-anonymity}.) % A subset of the ORs also act as %directory servers, tracking which routers are in the network; @@ -528,42 +529,41 @@ Each user runs local software called an onion proxy (OP) to fetch directories, establish circuits across the network, and handle connections from user applications. These onion proxies accept -TCP streams and multiplex them across the circuit. The onion +TCP streams and multiplex them across the circuits. The onion router on the other side of the circuit connects to the destinations of the TCP streams and relays data. Each onion router uses three public keys: a long-term identity key, a short-term onion key, and a short-term link key. The identity -(signing) key is used to sign TLS certificates, to sign its router -descriptor (a summary of its keys, address, bandwidth, exit policy, -etc), and to sign directories if it is a directory server. Changing +key is used to sign TLS certificates, to sign the OR's \emph{router +descriptor} (a summary of its keys, address, bandwidth, exit policy, +and so on), and (by directory servers) to sign directories. Changing the identity key of a router is considered equivalent to creating a -new router. The onion (decryption) key is used for decrypting requests +new router. The onion key is used to decrypt requests from users to set up a circuit and negotiate ephemeral keys. Finally, link keys are used by the TLS protocol when communicating between onion routers. Each short-term key is rotated periodically and independently, to limit the impact of key compromise. -Section~\ref{subsec:cells} discusses the structure of the fixed-size +Section~\ref{subsec:cells} discusses the fixed-size \emph{cells} that are the unit of communication in Tor. We describe in Section~\ref{subsec:circuits} how circuits are built, extended, truncated, and destroyed. Section~\ref{subsec:tcp} -describes how TCP streams are routed through the network, and finally +describes how TCP streams are routed through the network. We address +integrity checking in Section~\ref{subsec:integrity-checking}, +and resource limiting in Section~\ref{subsec:rate-limit}. +Finally, Section~\ref{subsec:congestion} talks about congestion control and fairness issues. -% NICK -% XXX \ref{subsec:integrity-checking} is missing -% XXX \ref{xubsec:rate-limit is missing. \SubSection{Cells} \label{subsec:cells} -Onion routers communicate with one another, and with users' OPs, via TLS -connections with ephemeral keys. This prevents an attacker from -impersonating an OR, conceals the contents of the connection with -perfect forward secrecy, and prevents an attacker from modifying data -on the wire. +Onion routers communicate with one another, and with users' OPs, via +TLS connections with ephemeral keys. Using TLS conceals the data on +the connection with perfect forward secrecy, and prevents an attacker +from modifying data on the wire or impersonating an OR. Traffic passes along these connections in fixed-size cells. Each cell is 256 bytes (but see Section~\ref{sec:conclusion} for a discussion of @@ -582,7 +582,7 @@ padding); \emph{create} or \emph{created} (used to set up a new circuit); and \emph{destroy} (to tear down a circuit). Relay cells have an additional header (the relay header) after the -cell header, containing the stream identifier (many streams can +cell header, containing a stream identifier (many streams can be multiplexed over a circuit); an end-to-end checksum for integrity checking; the length of the relay payload; and a relay command. The entire contents of the relay header and the relay cell payload @@ -607,7 +607,7 @@ We describe each of these cell types and commands in more detail below. Onion Routing originally built one circuit for each TCP stream. Because building a circuit can take several tenths of a -second (due to public-key cryptography delays and network latency), +second (due to public-key cryptography and network latency), this design imposed high costs on applications like web browsing that open many TCP streams. @@ -617,23 +617,23 @@ among their streams, users' OPs build a new circuit periodically if the previous one has been used, and expire old used circuits that no longer have any open streams. OPs consider making a new circuit once a minute: thus -even heavy users spend a negligible amount of time and CPU in +even heavy users spend a negligible amount of time building circuits, but only a limited number of requests can be linked to each other through a given exit node. Also, because circuits are built in the background, OPs can recover from failed circuit creation without delaying streams and thereby harming user experience.\\ -\noindent {\large Constructing a circuit}\\ +\noindent{\large\bf Constructing a circuit}\\ %\subsubsection{Constructing a circuit} \label{subsubsec:constructing-a-circuit} % -A user's OP constructs a circuit incrementally, negotiating a +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 \emph{create} cell to the first node in her chosen path (call him Bob). (She chooses a new circID $C_{AB}$ not currently used on the connection from her to Bob.) -This cell's +The \emph{create} cell's payload contains the first half of the Diffie-Hellman handshake ($g^x$), encrypted to the onion key of the OR (call him Bob). Bob responds with a \emph{created} cell containing the second half of the @@ -664,44 +664,43 @@ extend one hop further. 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 has no key +the OR doesn't care who is opening the circuit---Alice uses no public key and is trying to remain anonymous) and unilateral key authentication (Alice and the OR agree on a key, and Alice knows the OR is the -only other entity who should know it). It also achieves forward +only other entity who knows it). It also achieves forward secrecy and key freshness. More formally, the protocol is as follows (where $E_{PK_{Bob}}(\cdot)$ is encryption with Bob's public key, $H$ is a secure hash function, and $|$ is concatenation): - -\begin{equation} +\begin{equation*} \begin{aligned} \mathrm{Alice} \rightarrow \mathrm{Bob}&: E_{PK_{Bob}}(g^x) \\ \mathrm{Bob} \rightarrow \mathrm{Alice}&: g^y, H(K | \mathrm{``handshake"}) \\ \end{aligned} -\end{equation} +\end{equation*} -In the second step, Bob proves that it was he who who received $g^x$, -and who came up with $y$. We use PK encryption in the first step +In the second step, Bob proves that it was he who received $g^x$, +and who chose $y$. We use PK encryption in the first step (rather than, say, using the first two steps of STS, which has a signature in the second step) because a single cell is too small to hold both a public key and a signature. Preliminary analysis with the -NRL protocol analyzer \cite{meadows96} shows the above protocol to be -secure (including providing perfect forward secrecy) under the +NRL protocol analyzer \cite{meadows96} shows this protocol to be +secure (including perfect forward secrecy) under the traditional Dolev-Yao model.\\ -\noindent {\large Relay cells}\\ +\noindent{\large\bf Relay cells}\\ %\subsubsection{Relay cells} % Once Alice has established the circuit (so she shares keys with each OR on the circuit), she can send relay cells. Recall that every relay -cell has a streamID in the relay header that indicates to which +cell has a streamID that indicates to which stream the cell belongs. This streamID allows a relay cell to be -addressed to any of the ORs on the circuit. Upon receiving a relay +addressed to any OR on the circuit. Upon receiving a relay cell, an OR looks up the corresponding circuit, and decrypts the relay -header and payload with the appropriate session key for that circuit. -If the cell is headed downstream (away from Alice) it then checks +header and payload with the session key for that circuit. +If the cell is headed downstream (away from Alice) the OR then checks whether the decrypted streamID is recognized---either because it -corresponds to an open stream at this OR for the circuit, or because -it is equal to the control streamID (zero). If the OR recognizes the +corresponds to an open stream at this OR for the given circuit, or because +it is the control streamID (zero). If the OR recognizes the streamID, it accepts the relay cell and processes it as described below. Otherwise, the OR looks up the circID and OR for the @@ -711,7 +710,7 @@ of the circuit receives an unrecognized relay cell, an error has occurred, and the cell is discarded.) OPs treat incoming relay cells similarly: they iteratively unwrap the -relay header and payload with the session key shared with each +relay header and payload with the session keys shared with each OR on the circuit, from the closest to farthest. (Because we use a stream cipher, encryption operations may be inverted in any order.) If at any stage the OP recognizes the streamID, the cell must have @@ -732,11 +731,11 @@ This \emph{leaky pipe} circuit topology allows Alice's streams to exit at different ORs on a single circuit. Alice may choose different exit points because of their exit policies, or to keep the ORs from knowing that two streams -originate at the same person. +originate from the same person. -When an OR later replies to Alice with a relay cell, it only needs to -encrypt the cell's relay header and payload with the single key it -shares with Alice, and send the cell back toward Alice along the +When an OR later replies to Alice with a relay cell, it +encrypts the cell's relay header and payload with the single key it +shares with Alice, and sends the cell back toward Alice along the circuit. Subsequent ORs add further layers of encryption as they relay the cell back to Alice. @@ -744,12 +743,12 @@ To tear down a whole circuit, Alice sends a \emph{destroy} control cell. Each OR in the circuit receives the \emph{destroy} cell, closes all open streams on that circuit, and passes a new \emph{destroy} cell forward. But just as circuits are built incrementally, they can also -be torn down incrementally: Alice can instead send a \emph{relay -truncate} cell to a single OR on the circuit. That node then sends a +be torn down incrementally: Alice can send a \emph{relay +truncate} cell to a single OR on the circuit. That OR then sends a \emph{destroy} cell forward, and acknowledges with a \emph{relay truncated} cell. Alice can then extend the circuit to different nodes, all without signaling to the intermediate nodes (or -somebody observing them) that she has changed her circuit. +an observer) that she has changed her circuit. Similarly, if a node on the circuit goes down, the adjacent node can send a \emph{relay truncated} cell back to Alice. Thus the ``break a node and see which circuits go down'' attack @@ -758,19 +757,19 @@ node can send a \emph{relay truncated} cell back to Alice. Thus the \SubSection{Opening and closing streams} \label{subsec:tcp} -When Alice's application wants to open a TCP connection to a given +When Alice's application wants a TCP connection to a given address and port, it asks the OP (via SOCKS) to make the connection. The OP chooses the newest open circuit (or creates one if -none is available), chooses a suitable OR on that circuit to be the +none is available), and chooses a suitable OR on that circuit to be the exit node (usually the last node, but maybe others due to exit policy -conflicts; see Section~\ref{subsec:exitpolicies}), chooses a new -random streamID for the stream, and sends a \emph{relay begin} cell -to that exit node. The OP uses a streamID of zero for this cell -(so the OR will recognize it), and uses the new streamID, destination -address, and port as the contents of the cell's relay payload. Once the +conflicts; see Section~\ref{subsec:exitpolicies}. The OP then opens +the stream by sending a \emph{relay begin} cell to the exit node, +using a streamID of zero (so the OR will recognize it), containing as +its relay payload a new randomly generated streamID, the destination +address, and the destination port. Once the exit node completes the connection to the remote host, it responds with a \emph{relay connected} cell. Upon receipt, the OP sends a -SOCKS reply to the application notifying it of success. The OP +SOCKS reply to notify the application of its success. The OP now accepts data from the application's TCP stream, packaging it into \emph{relay data} cells and sending those cells along the circuit to the chosen OR. @@ -778,18 +777,18 @@ the chosen OR. There's a catch to using SOCKS, however---some applications pass the alphanumeric hostname to the proxy, while others resolve it into an IP address first and then pass the IP address to the proxy. If the -application does the DNS resolution first, Alice will thereby -broadcast her destination to the DNS server. Common applications +application does DNS resolution first, Alice will thereby +reveal her destination to the DNS server. Common applications like Mozilla and SSH have this flaw. -In the case of Mozilla, the flaw is easy to address: the filtering web +In the case of Mozilla, the flaw is easy to address: the filtering HTTP proxy called Privoxy does the SOCKS call safely, and Mozilla talks to Privoxy safely. But a portable general solution, such as is needed for SSH, is an open problem. Modifying or replacing the local nameserver can be invasive, brittle, and not portable. Forcing the resolver library to do resolution via TCP rather than UDP is -hard, and also has portability problems. We could provide a +hard, and also has portability problems. We could also provide a tool similar to \emph{dig} to perform a private lookup through the Tor network. Our current answer is to encourage the use of privacy-aware proxies like Privoxy wherever possible. @@ -799,28 +798,29 @@ two-step handshake for normal operation, or a one-step handshake for errors. If the stream closes abnormally, the adjacent node simply sends a \emph{relay teardown} cell. If the stream closes normally, the node sends a \emph{relay end} cell down the circuit. When the other side has sent -back its own \emph{relay end}, the stream can be torn down. Because +back its own \emph{relay end} cell, the stream can be torn down. Because all relay cells use layered encryption, only the destination OR knows that a given relay cell is a request to close a stream. This two-step -handshake allows for TCP-based applications that use half-closed -connections, such as broken HTTP clients that close their side of the -stream after writing but are still willing to read. +handshake allows Tor to support TCP-based applications that use half-closed +connections. +% such as broken HTTP clients that close their side of the +%stream after writing but are still willing to read. \SubSection{Integrity checking on streams} \label{subsec:integrity-checking} Because the old Onion Routing design used a stream cipher, traffic was -vulnerable to a malleability attack: even though the attacker could not -decrypt cells, he could make changes to an encrypted -cell to create corresponding changes to the data leaving the network. +vulnerable to a malleability attack: though the attacker could not +decrypt cells, any changes to encrypted data +would create corresponding changes to the data leaving the network. (Even an external adversary could do this, despite link encryption, by inverting bits on the wire.) This weakness allowed an adversary to change a padding cell to a destroy -cell; change the destination address in a relay begin cell to the -adversary's webserver; or change a user on an ftp connection from -typing ``dir'' to typing ``delete~*''. Any node or external adversary -along the circuit could introduce such corruption in a stream---if it +cell; change the destination address in a \emph{relay begin} cell to the +adversary's webserver; or change an FTP command from +{\tt dir} to {\tt rm~*}. Any OR or external adversary +along the circuit could introduce such corruption in a stream, if it knew or could guess the encrypted content. Tor prevents external adversaries from mounting this attack by @@ -841,13 +841,13 @@ is vulnerable to end-to-end timing attacks; tagging attacks performed within the circuit provide no additional information to the attacker. Thus, we check integrity only at the edges of each stream. When Alice -negotiates a key with a new hop, they both initialize a pair of SHA-1 -digests with a derivative of that key, +negotiates a key with a new hop, they each initialize a SHA-1 +digest with a derivative of that key, thus beginning with randomness that only the two of them know. From -then on they each incrementally add to the SHA-1 digests the contents of -all relay cells they create or accept (one digest is for cells -created; one is for cells accepted), and include with each relay cell -the first 4 bytes of the current value of the hash of cells created. +then on they each incrementally add to the SHA-1 digest the contents of +all relay cells they create, and include with each relay cell the +first four bytes of the current digest. Each also keeps a SHA-1 +digest of data received, to verify that the received hashes are correct. To be sure of removing or modifying a cell, the attacker must be able to either deduce the current digest state (which depends on all @@ -858,7 +858,9 @@ end-to-end encrypted across the circuit. The computational overhead of computing the digests is minimal compared to doing the AES encryption performed at each hop of the circuit. We use only four bytes per cell to minimize overhead; the chance that an adversary will -correctly guess a valid hash, plus the payload the current cell, is +correctly guess a valid hash +%, plus the payload the current cell, +is acceptably low, given that Alice or Bob tear down the circuit if they receive a bad hash. @@ -866,7 +868,7 @@ receive a bad hash. \label{subsec:rate-limit} Volunteers are generally more willing to run services that can limit -their bandwidth usage. To accommodate them, Tor servers use a +their own bandwidth usage. To accommodate them, Tor servers use a token bucket approach \cite{tannenbaum96} to enforce a long-term average rate of incoming bytes, while still permitting short-term bursts above the allowed bandwidth. Current bucket @@ -893,9 +895,9 @@ Further, inspired by Rennhard et al's design in \cite{anonnet}, a circuit's edges heuristically distinguish interactive streams from bulk streams by comparing the frequency with which they supply cells. We can provide good latency for interactive streams by giving them preferential -service, while still getting good overall throughput to the bulk +service, while still giving good overall throughput to the bulk streams. Such preferential treatment presents a possible end-to-end -attack, but an adversary who can observe both +attack, but an adversary observing both ends of the stream can already learn this information through timing attacks. @@ -905,13 +907,14 @@ attacks. Even with bandwidth rate limiting, we still need to worry about congestion, either accidental or intentional. If enough users choose the same OR-to-OR connection for their circuits, that connection can become -saturated. For example, an adversary could make a large HTTP PUT request -through the onion routing network to a webserver he runs, and then +saturated. For example, an attacker could send a large file +through the Tor network to a webserver he runs, and then refuse to read any of the bytes at the webserver end of the circuit. Without some congestion control mechanism, these bottlenecks can propagate back through the entire network. We don't need to reimplement full TCP windows (with sequence numbers, -the ability to drop cells when we're full and retransmit later, etc), +the ability to drop cells when we're full and retransmit later, and so +on), because TCP already guarantees in-order delivery of each cell. %But we need to investigate further the effects of the current @@ -922,7 +925,7 @@ We describe our response below. \textbf{Circuit-level throttling:} To control a circuit's bandwidth usage, each OR keeps track of two windows. The \emph{packaging window} tracks how many relay data cells the OR is -allowed to package (from outside TCP streams) for transmission back to the OP, +allowed to package (from incoming TCP streams) for transmission back to the OP, and the \emph{delivery window} tracks how many relay data cells it is willing to deliver to TCP streams outside the network. Each window is initialized (say, to 1000 data cells). When a data cell is packaged or delivered, @@ -960,14 +963,14 @@ can't send a \emph{relay sendme} cell when its packaging window is empty. \SubSection{Resource management and denial-of-service} \label{subsec:dos} -Providing Tor as a public service provides many opportunities for an -attacker to mount denial-of-service attacks against the network. While +Providing Tor as a public service provides many opportunities for +denial-of-service attacks against the network. While flow control and rate limiting (discussed in Section~\ref{subsec:congestion}) prevent users from consuming more bandwidth than routers are willing to provide, opportunities remain for users to consume more network resources than their fair share, or to render the -network unusable for other users. +network unusable for others. First of all, there are several CPU-consuming denial-of-service attacks wherein an attacker can force an OR to perform expensive @@ -1022,18 +1025,18 @@ at the exit OR. We stress that Tor does not enable any new class of abuse. Spammers and other attackers already have access to thousands of misconfigured systems worldwide, and the Tor network is far from the easiest way -to launch these antisocial or illegal attacks. +to launch antisocial or illegal attacks. %Indeed, because of its limited %anonymity, Tor is probably not a good way to commit crimes. But because the onion routers can easily be mistaken for the originators of the abuse, and the volunteers who run them may not want to deal with the hassle of -repeatedly explaining anonymity networks, we must block or limit attacks -and other abuse that travel through the Tor network. +repeatedly explaining anonymity networks, we must block or limit +the abuse that travels through the Tor network. To mitigate abuse issues, in Tor, each onion router's \emph{exit policy} -describes to which external addresses and ports the router will permit -stream connections. On one end of the spectrum are \emph{open exit} +describes to which external addresses and ports the router will +connect. On one end of the spectrum are \emph{open exit} nodes that will connect anywhere. On the other end are \emph{middleman} nodes that only relay traffic to other Tor nodes, and \emph{private exit} nodes that only connect to a local host or network. Using a private @@ -1042,7 +1045,10 @@ given host or network---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 will function as \emph{restricted exits} that permit connections to the world at large, -but prevent access to certain abuse-prone addresses and services. In +but prevent access to certain abuse-prone addresses and services. +% XXX This next sentence makes no sense to me in context; must +% XXX revisit. -NM +In general, nodes can require a variety of forms of traffic authentication \cite{or-discex00}. @@ -1053,7 +1059,7 @@ general, nodes can require a variety of forms of traffic authentication %can be assumed for important traffic. Many administrators will use port restrictions to support only a -limited set of well-known services, such as HTTP, SSH, or AIM. +limited set of services, such as HTTP, SSH, or AIM. This is not a complete solution, of course, since abuse opportunities for these protocols are still well known. @@ -1064,16 +1070,16 @@ vulnerabilities) can be detected in a straightforward manner. Similarly, one could run automatic spam filtering software (such as SpamAssassin) on email exiting the OR network. -ORs may also choose to rewrite exiting traffic in order to append -headers or other information to indicate that the traffic has passed +ORs may also rewrite exiting traffic to append +headers or other information indicating that the traffic has passed through an anonymity service. This approach is commonly used -by email-only anonymity systems. When possible, ORs can also -run on servers with hostnames such as {\it anonymous}, to further +by email-only anonymity systems. ORs can also +run on servers with hostnames like {\tt anonymous} to further alert abuse targets to the nature of the anonymous traffic. -A mixture of open and restricted exit nodes will allow the most -flexibility for volunteers running servers. But while many -middleman nodes help provide a large and robust network, +A mixture of open and restricted exit nodes allows the most +flexibility for volunteers running servers. But while having many +middleman nodes provides a large and robust network, having only a few exit nodes reduces the number of points an adversary needs to monitor for traffic analysis, and places a greater burden on the exit nodes. This tension can be seen in the @@ -1089,7 +1095,7 @@ Section~\ref{sec:conclusion}. Finally, we note that exit abuse must not be dismissed as a peripheral issue: when a system's public image suffers, it can reduce the number and diversity of that system's users, and thereby reduce the anonymity -of the system itself. Like usability, public perception is also a +of the system itself. Like usability, public perception is a security parameter. Sadly, preventing abuse of open exit nodes is an unsolved problem, and will probably remain an arms race for the forseeable future. The abuse problems faced by Princeton's CoDeeN @@ -1103,30 +1109,31 @@ in-band network status updates: each router flooded a signed statement to its neighbors, which propagated it onward. But anonymizing networks have different security goals than typical link-state routing protocols. For example, delays (accidental or intentional) -that can cause different parts of the network to have different pictures -of link-state and topology are not only inconvenient---they give +that can cause different parts of the network to have different views +of link-state and topology are not only inconvenient: they give attackers an opportunity to exploit differences in client knowledge. We also worry about attacks to deceive a client about the router membership list, topology, or current network state. Such \emph{partitioning attacks} on client knowledge help an adversary to efficiently deploy resources -when attacking a target \cite{minion-design}. +against a target \cite{minion-design}. Tor uses a small group of redundant, well-known onion routers to track changes in network topology and node state, including keys and -exit policies. Each such \emph{directory server} also acts as an HTTP +exit policies. Each such \emph{directory server} acts as an HTTP server, so participants can fetch current network state and router -lists (a \emph{directory}), and so other onion routers can upload -their router descriptors. Onion routers periodically publish signed +lists, and so other ORs can upload +state information. Onion routers periodically publish signed statements of their state to each directory server, which combines this state information with its own view of network liveness, and generates -a signed description of the entire network state. Client software is +a signed description (a \emph{directory}) of the entire network +state. Client software is pre-loaded with a list of the directory servers and their keys; it uses this information to bootstrap each client's view of the network. -When a directory server receives a signed statement from an onion -router, it recognizes the onion router by its identity key. Directory +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 automatically advertise unrecognized ORs. (If they did, an adversary could take over the network by creating many servers \cite{sybil}.) Instead, new nodes must be approved by the directory @@ -1135,14 +1142,15 @@ node approval are an area of active research, and are discussed more in Section~\ref{sec:maintaining-anonymity}. Of course, a variety of attacks remain. An adversary who controls -a directory server can track certain clients by providing different +a directory server can track clients by providing them different 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. -Thus these directory servers must be synchronized and redundant. -Directories are valid if they are signed by a threshold of the directory +Thus these directory servers must be synchronized and redundant, so +that they can agree on a common directory. Clients should only trust +this directory if it is signed by a threshold of the directory servers. The directory servers in Tor are modeled after those in Mixminion @@ -1184,9 +1192,10 @@ must build circuits and use them to anonymously test router reliability \cite{mix-acc}. Using directory servers is simpler and more flexible than flooding. -For example, flooding complicates the analysis when we -start experimenting with non-clique network topologies. And because -the directories are signed, they can be cached by other onion routers. +Flooding is expensive, and complicates the analysis when we +start experimenting with non-clique network topologies. Signed +directories are less expensive, because they can be cached by other +onion routers. Thus directory servers are not a performance bottleneck when we have many users, and do not aid traffic analysis by forcing clients to periodically announce their existence to any @@ -1224,44 +1233,46 @@ points. He may do this on any robust efficient key-value lookup system with authenticated updates, such as a distributed hash table (DHT) like CFS \cite{cfs:sosp01}\footnote{ Rather than rely on an external infrastructure, the Onion Routing network -can run the DHT; to begin, we can run a simple lookup system on the +can run the DHT itself. At first, we can simply run a simple lookup +system on the directory servers.} Alice, the client, chooses an OR as her \emph{rendezvous point}. She connects to one of Bob's introduction -points, informs him about her rendezvous point, and then waits for him +points, informs him of her rendezvous point, and then waits for him to connect to the rendezvous point. This extra level of indirection helps Bob's introduction points avoid problems associated with serving -unpopular files directly (for example, if Bob chooses -an introduction point in Texas to serve anti-ranching propaganda, +unpopular files directly (for example, if Bob serves +material that the introduction point's neighbors find objectionable, or if Bob's service tends to get attacked by network vandals). The extra level of indirection also allows Bob to respond to some requests and ignore others. -We give an overview of the steps of a rendezvous. These steps are -performed on behalf of Alice and Bob by their local onion proxies; +We give an overview of the steps of a rendezvous. These are +performed on behalf of Alice and Bob by their local OPs; application integration is described more fully below. \begin{tightlist} \item Bob chooses some introduction points, and advertises them on the DHT. He can add more later. -\item Bob establishes a Tor circuit to each of his introduction points, - and waits. No data is transmitted until a request is received. +\item Bob builds a circuit to each of his introduction points, + and waits. No data is yet transmitted. \item Alice learns about Bob's service out of band (perhaps Bob told her, or she found it on a website). She retrieves the details of Bob's service from the DHT. -\item Alice chooses an OR to serve as the rendezvous point (RP) for this - transaction. She establishes a circuit to RP, and gives it a - rendezvous cookie, which it will use to recognize Bob. +\item Alice chooses an OR to be the rendezvous point (RP) for this + transaction. She builds a circuit to RP, and gives it a + rendezvous cookie that it will use to recognize Bob. \item Alice opens an anonymous stream to one of Bob's introduction - points, and gives it a message (encrypted to Bob's public key) which tells him + points, and gives it a message (encrypted to Bob's public key) + which tells him about herself, her chosen RP and the rendezvous cookie, and the - first half of an ephemeral - key handshake. The introduction point sends the message to Bob. -\item If Bob wants to talk to Alice, he builds a new circuit to Alice's - RP and provides the rendezvous cookie and the second half of the DH - handshake (along with a hash of the session - key they now share---by the same argument as in + first half of a DH + handshake. The introduction point sends the message to Bob. +\item If Bob wants to talk to Alice, he builds a circuit to Alice's + RP and provides the rendezvous cookie, the second half of the DH + handshake, and a hash of the session + key they now share. By the same argument as in Section~\ref{subsubsec:constructing-a-circuit}, Alice knows she - shares the key only with the intended Bob). + shares the key only with Bob. \item The RP connects Alice's circuit to Bob's. Note that RP can't recognize Alice, Bob, or the data they transmit. \item Alice now sends a \emph{relay begin} cell along the circuit. It @@ -1319,9 +1330,11 @@ can choose whether to respond. The authentication tokens can be used to provide selective access: important users get tokens to ensure uninterrupted access to the service. During normal situations, Bob's service might simply be offered -directly from mirrors, and Bob gives out tokens to high-priority users. If -the mirrors are knocked down by distributed DoS attacks or even -physical attack, those users can switch to accessing Bob's service via +directly from mirrors, while Bob gives out tokens to high-priority users. If +the mirrors are knocked down, +%by distributed DoS attacks or even +%physical attack, +those users can switch to accessing Bob's service via the Tor rendezvous system. Since Bob's introduction points might themselves be subject to DoS he @@ -1333,7 +1346,7 @@ are not advertised in the DHT\@. This is most likely to be practical if there is a relatively stable and large group of introduction points generally available. Alternatively, Bob could give secret public keys to selected users for consulting the DHT\@. All of these approaches -have the advantage of limiting the damage that can be done even if +have the advantage of limiting exposure even when some of the selected high-priority users collude in the DoS\@. \SubSection{Integration with user applications} @@ -1341,18 +1354,19 @@ some of the selected high-priority users collude in the DoS\@. Bob configures his onion proxy to know the local IP address and port of his service, a strategy for authorizing clients, and a public key. Bob publishes the public key, an expiration time (``not valid after''), and -the current introduction points for his service into the DHT, all indexed -by the hash of the public key. Note that Bob's webserver is unmodified, +the current introduction points for his service into the DHT, indexed +by the hash of the public key. Bob's webserver is unmodified, and doesn't even know that it's hidden behind the Tor network. 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 Alice uses when establishing her connection. Location-hidden services use a virtual top level domain -called `.onion': thus hostnames take the form x.y.onion where x is the -authentication cookie, and y encodes the hash of PK. Alice's onion proxy +called {\tt .onion}: thus hostnames take the form {\tt x.y.onion} where +{\tt x} is the authentication cookie, and {\tt y} encodes the hash of +the public key. Alice's onion proxy examines addresses; if they're destined for a hidden server, it decodes -the PK and starts the rendezvous as described in the table above. +the key and starts the rendezvous as described above. \subsection{Previous rendezvous work} @@ -1368,8 +1382,8 @@ points for low-latency Internet connections was by Ian Goldberg ours in three ways. First, Goldberg suggests that Alice should manually hunt down a current location of the service via Gnutella; our approach makes lookup transparent to the user, as well as faster and more robust. -Second, in Tor the client and server negotiate ephemeral keys -via Diffie-Hellman, so plaintext is not exposed at any point. Third, +Second, in Tor the client and server negotiate session keys +via Diffie-Hellman, so plaintext is not exposed at the rendezvous point. Third, our design tries to minimize the exposure associated with running the service, to encourage volunteers to offer introduction and rendezvous point services. Tor's introduction points do not output any bytes to the @@ -1385,7 +1399,7 @@ acknowledge his existence. %Below we summarize a variety of attacks, and discuss how well our %design withstands them.\\ -\noindent{\large Passive attacks}\\ +\noindent{\large\bf Passive attacks}\\ \emph{Observing user traffic patterns.} Observing the connection from the user will not reveal her destination or data, but it will reveal traffic patterns (both sent and received). Profiling via user @@ -1453,7 +1467,7 @@ these are in principle feasible and surprises are always possible, these constitute a much more complicated attack, and there is no current evidence of their practicality.}\\ -\noindent {\large Active attacks}\\ +\noindent{\large\bf Active attacks}\\ \emph{Compromise keys.} An attacker who learns the TLS session key can see control cells and encrypted relay cells on every circuit on that connection; learning a circuit @@ -1580,7 +1594,7 @@ releases in source code form, encourage source audits, and frequently warn our users never to trust any software (even from us!) that comes without source.\\ -\noindent{\large Directory attacks}\\ +\noindent{\large\bf Directory attacks}\\ \emph{Destroy directory servers.} If a few directory servers drop out of operation, the others still arrive at a final directory. So long as any directory servers remain in operation, @@ -1628,7 +1642,7 @@ servers must actively test ORs by building circuits and streams as appropriate. The tradeoffs of a similar approach are discussed in \cite{mix-acc}.\\ -\noindent {\large Attacks against rendezvous points}\\ +\noindent{\large\bf Attacks against rendezvous points}\\ \emph{Make many introduction requests.} An attacker could try to deny Bob service by flooding his Introduction Point with requests. Because the introduction point can block requests that