diff options
Diffstat (limited to 'doc/tor-design.tex')
| -rw-r--r-- | doc/tor-design.tex | 679 |
1 files changed, 335 insertions, 344 deletions
diff --git a/doc/tor-design.tex b/doc/tor-design.tex index 9e87d622c..42712a3d7 100644 --- a/doc/tor-design.tex +++ b/doc/tor-design.tex @@ -1388,324 +1388,311 @@ Below we summarize a variety of attacks, and discuss how well our design withstands them. \subsubsection*{Passive attacks} -\begin{tightlist} -\item \emph{Observing user traffic patterns.} Observations of connection - between a user and her first onion router will not reveal to whom - the user is connecting or what information is being sent. It will - reveal patterns of user traffic (both sent and received). Simple - profiling of user connection patterns is not generally possible, - however, because multiple application streams may be operating - simultaneously or in series over a single circuit. Thus, further - processing is necessary to discern even these usage patterns. + +\emph{Observing user traffic patterns.} Observations of connection +between a user and her first onion router will not reveal to whom +the user is connecting or what information is being sent. It will +reveal patterns of user traffic (both sent and received). Simple +profiling of user connection patterns is not generally possible, +however, because multiple application streams may be operating +simultaneously or in series over a single circuit. Thus, further +processing is necessary to discern even these usage patterns. -\item \emph{Observing user content.} At the user end, content is - encrypted; however, connections from the network to arbitrary - websites may not be. Further, a responding website may itself be - hostile. Filtering content is not a primary goal of - Onion Routing; nonetheless, Tor can directly make use of Privoxy and - related filtering services to anonymize application data streams. - -\item \emph{Option distinguishability.} Configuration options can be a - source of distinguishable patterns. In general there is economic - incentive to allow preferential services \cite{econymics}, and some - degree of configuration choice can attract users, which - provide anonymity. So far, however, we have - not found a compelling use case in Tor for any client-configurable - options. Thus, clients are currently distinguishable only by their - behavior. +\emph{Observing user content.} At the user end, content is +encrypted; however, connections from the network to arbitrary +websites may not be. Further, a responding website may itself be +hostile. Filtering content is not a primary goal of +Onion Routing; nonetheless, Tor can directly make use of Privoxy and +related filtering services to anonymize application data streams. + +\emph{Option distinguishability.} Configuration options can be a +source of distinguishable patterns. In general there is economic +incentive to allow preferential services \cite{econymics}, and some +degree of configuration choice can attract users, which +provide anonymity. So far, however, we have +not found a compelling use case in Tor for any client-configurable +options. Thus, clients are currently distinguishable only by their +behavior. %XXX Actually, circuitrebuildperiod is such an option. -RD -\item \emph{End-to-end Timing correlation.} Tor only minimally hides - end-to-end timing correlations. An attacker watching patterns of - traffic at the initiator and the responder will be - able to confirm the correspondence with high probability. The - greatest protection currently available against such confirmation is to hide - the connection between the onion proxy and the first Tor node, - by running the onion proxy locally or - behind a firewall. This approach - requires an observer to separate traffic originating at the onion - router from traffic passing through it; but because we do not mix - or pad, this does not provide much defense. +\emph{End-to-end Timing correlation.} Tor only minimally hides +end-to-end timing correlations. An attacker watching patterns of +traffic at the initiator and the responder will be +able to confirm the correspondence with high probability. The +greatest protection currently available against such confirmation is to hide +the connection between the onion proxy and the first Tor node, +by running the onion proxy locally or +behind a firewall. This approach +requires an observer to separate traffic originating at the onion +router from traffic passing through it; but because we do not mix +or pad, this does not provide much defense. -\item \emph{End-to-end Size correlation.} Simple packet counting - without timing correlation will also be effective in confirming - endpoints of a stream. However, even without padding, we have some - limited protection: the leaky pipe topology means different numbers - of packets may enter one end of a circuit than exit at the other. +\emph{End-to-end Size correlation.} Simple packet counting +without timing correlation will also be effective in confirming +endpoints of a stream. However, even without padding, we have some +limited protection: the leaky pipe topology means different numbers +of packets may enter one end of a circuit than exit at the other. -\item \emph{Website fingerprinting.} All the above passive - attacks that are at all effective are traffic confirmation attacks. - This puts them outside our general design goals. There is also - a passive traffic analysis attack that is potentially effective. - Rather than searching exit connections for timing and volume - correlations, the adversary may build up a database of - ``fingerprints'' containing file sizes and access patterns for many - interesting websites. He can confirm a user's connection to a given - site simply by consulting the database. This attack has - been shown to be effective against SafeWeb \cite{hintz-pet02}. But - Tor is not as vulnerable as SafeWeb to this attack: there is the - possibility that multiple streams are exiting the circuit at - different places concurrently. Also, fingerprinting will be limited to - the granularity of cells, currently 256 bytes. Other defenses include - larger cell sizes and/or minimal padding schemes that group websites - into large sets. But this remains an open problem. Link - padding or long-range dummies may also make fingerprints harder to - detect.\footnote{Note that - such fingerprinting should not be confused with the latency attacks - of \cite{back01}. Those require a fingerprint of the latencies of - all circuits through the network, combined with those from the - network edges to the targeted user and the responder website. While - these are in principal feasible and surprises are always possible, - these constitute a much more complicated attack, and there is no - current evidence of their practicality.} - -%\item \emph{Content analysis.} Tor explicitly provides no content -% rewriting for any protocol at a higher level than TCP. When -% protocol cleaners are available, however (as Privoxy is for HTTP), -% Tor can integrate them to address these attacks. - -\end{tightlist} +\emph{Website fingerprinting.} All the above passive +attacks that are at all effective are traffic confirmation attacks. +This puts them outside our general design goals. There is also +a passive traffic analysis attack that is potentially effective. +Rather than searching exit connections for timing and volume +correlations, the adversary may build up a database of +``fingerprints'' containing file sizes and access patterns for many +interesting websites. He can confirm a user's connection to a given +site simply by consulting the database. This attack has +been shown to be effective against SafeWeb \cite{hintz-pet02}. But +Tor is not as vulnerable as SafeWeb to this attack: there is the +possibility that multiple streams are exiting the circuit at +different places concurrently. Also, fingerprinting will be limited to +the granularity of cells, currently 256 bytes. Other defenses include +larger cell sizes and/or minimal padding schemes that group websites +into large sets. But this remains an open problem. Link +padding or long-range dummies may also make fingerprints harder to +detect.\footnote{Note that +such fingerprinting should not be confused with the latency attacks +of \cite{back01}. Those require a fingerprint of the latencies of +all circuits through the network, combined with those from the +network edges to the targeted user and the responder website. While +these are in principal feasible and surprises are always possible, +these constitute a much more complicated attack, and there is no +current evidence of their practicality.} \subsubsection*{Active attacks} -\begin{tightlist} -\item \emph{Compromise keys.} - If a TLS session key is compromised, an attacker - can view all the cells on TLS connection until the key is - renegotiated. (These cells are themselves encrypted.) If a TLS - private key is compromised, the attacker can fool others into - thinking that he is the affected OR, but still cannot accept any - connections. \\ - If a circuit session key is compromised, the - attacker can unwrap a single layer of encryption from the relay - cells traveling along that circuit. (Only nodes on the circuit can - see these cells.) If an onion private key is compromised, the attacker - can impersonate the OR in circuits, but only if the attacker has - also compromised the OR's TLS private key, or is running the - previous OR in the circuit. (This compromise affects newly created - circuits, but because of perfect forward secrecy, the attacker - cannot hijack old circuits without compromising their session keys.) - In any case, periodic key rotation limits the window of opportunity - for compromising these keys. \\ - Only by - compromising a node's identity key can an attacker replace that - node indefinitely, by sending new forged descriptors to the - directory servers. Finally, an attacker who can compromise a - directory server's identity key can influence every client's view - of the network---but only to the degree made possible by gaining a - vote with the rest of the the directory servers. - -\item \emph{Iterated compromise.} A roving adversary who can - compromise ORs (by system intrusion, legal coersion, or extralegal - coersion) could march down the circuit compromising the - nodes until he reaches the end. Unless the adversary can complete - this attack within the lifetime of the circuit, however, the ORs - will have discarded the necessary information before the attack can - 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 - arbitrage.'' The Java Anon Proxy project recently experienced the - need for this approach, when - the German government successfully ordered them to add a backdoor to - all of their nodes \cite{jap-backdoor}. - -\item \emph{Run a recipient.} By running a Web server, an adversary - trivially learns the timing patterns of users connecting to it, and - can introduce arbitrary patterns in its responses. This can greatly - facilitate end-to-end attacks: If the adversary can induce certain - users to connect to his webserver (perhaps by advertising - content targeted at those users), she now holds one end of their - connection. Additionally, there is a danger that the application - protocols and associated programs can be induced to reveal - information about the initiator. Tor does not aim to solve this problem; - we depend on Privoxy and similar protocol cleaners. - -\item \emph{Run an onion proxy.} 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 an institutional setting which wants - to monitor the activity of those connecting to the proxy. - Compromising an onion proxy means compromising all future connections - through it. - -\item \emph{DoS non-observed nodes.} An observer who can observe some - of the Tor network can increase the value of this traffic analysis - by attacking non-observed nodes to shut them down, reduce - their reliability, or persuade users that they are not trustworthy. - The best defense here is robustness. + +\emph{Compromise keys.} +If a TLS session key is compromised, an attacker +can view all the cells on TLS connection until the key is +renegotiated. (These cells are themselves encrypted.) If a TLS +private key is compromised, the attacker can fool others into +thinking that he is the affected OR, but still cannot accept any +connections. \\ +If a circuit session key is compromised, the +attacker can unwrap a single layer of encryption from the relay +cells traveling along that circuit. (Only nodes on the circuit can +see these cells.) If an onion private key is compromised, the attacker +can impersonate the OR in circuits, but only if the attacker has +also compromised the OR's TLS private key, or is running the +previous OR in the circuit. (This compromise affects newly created +circuits, but because of perfect forward secrecy, the attacker +cannot hijack old circuits without compromising their session keys.) +In any case, periodic key rotation limits the window of opportunity +for compromising these keys. \\ +Only by +compromising a node's identity key can an attacker replace that +node indefinitely, by sending new forged descriptors to the +directory servers. Finally, an attacker who can compromise a +directory server's identity key can influence every client's view +of the network---but only to the degree made possible by gaining a +vote with the rest of the the directory servers. + +\emph{Iterated compromise.} A roving adversary who can +compromise ORs (by system intrusion, legal coersion, or extralegal +coersion) could march down the circuit compromising the +nodes until he reaches the end. Unless the adversary can complete +this attack within the lifetime of the circuit, however, the ORs +will have discarded the necessary information before the attack can +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 +arbitrage.'' The Java Anon Proxy project recently experienced the +need for this approach, when +the German government successfully ordered them to add a backdoor to +all of their nodes \cite{jap-backdoor}. + +\emph{Run a recipient.} By running a Web server, an adversary +trivially learns the timing patterns of users connecting to it, and +can introduce arbitrary patterns in its responses. This can greatly +facilitate end-to-end attacks: If the adversary can induce certain +users to connect to his webserver (perhaps by advertising +content targeted at those users), she now holds one end of their +connection. Additionally, there is a danger that the application +protocols and associated programs can be induced to reveal +information about the initiator. Tor does not aim to solve this problem; +we depend on Privoxy and similar protocol cleaners. -\item \emph{Run a hostile node.} In addition to the abilities of a - local observer, an isolated hostile node can create circuits through - itself, or alter traffic patterns, to affect traffic at - other nodes. Its ability to directly DoS a neighbor is now limited - by bandwidth throttling. Nonetheless, in order to compromise the - anonymity of the endpoints of a circuit by its observations, a - hostile node must be immediately adjacent to that endpoint. +\emph{Run an onion proxy.} 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 an institutional setting which wants +to monitor the activity of those connecting to the proxy. +Compromising an onion proxy means compromising all future connections +through it. + +\emph{DoS non-observed nodes.} An observer who can observe some +of the Tor network can increase the value of this traffic analysis +by attacking non-observed nodes to shut them down, reduce +their reliability, or persuade users that they are not trustworthy. +The best defense here is robustness. -\item \emph{Run multiple hostile nodes.} If an adversary is able to - run multiple ORs, and is able to persuade the directory servers - that those ORs are trustworthy and independant, then occasionally - some user will choose one of those ORs for the start and another - as the end of a circuit. When this happens, the user's - anonymity is compromised for those streams. If an adversary can - control $m$ out of $N$ nodes, he should be able to correlate at most - $\left(\frac{m}{N}\right)^2$ of the traffic in this way---although an - adversary - could possibly attract a disproportionately large amount of traffic - by running an exit node with an unusually permissive exit policy. - -\item \emph{Compromise entire path.} Anyone compromising both - endpoints of a circuit can confirm this with high probability. If - the entire path is compromised, this becomes a certainty; however, - the added benefit to the adversary of such an attack is small in - relation to the difficulty. +\emph{Run a hostile node.} In addition to the abilities of a +local observer, an isolated hostile node can create circuits through +itself, or alter traffic patterns, to affect traffic at +other nodes. Its ability to directly DoS a neighbor is now limited +by bandwidth throttling. Nonetheless, in order to compromise the +anonymity of the endpoints of a circuit by its observations, a +hostile node must be immediately adjacent to that endpoint. -\item \emph{Run a hostile directory server.} Directory servers control - admission to the network. However, because the network directory - must be signed by a majority of servers, the threat of a single - hostile server is minimized. +\emph{Run multiple hostile nodes.} If an adversary is able to +run multiple ORs, and is able to persuade the directory servers +that those ORs are trustworthy and independant, then occasionally +some user will choose one of those ORs for the start and another +as the end of a circuit. When this happens, the user's +anonymity is compromised for those streams. If an adversary can +control $m$ out of $N$ nodes, he should be able to correlate at most +$\left(\frac{m}{N}\right)^2$ of the traffic in this way---although an +adversary +could possibly attract a disproportionately large amount of traffic +by running an exit node with an unusually permissive exit policy. + +\emph{Compromise entire path.} Anyone compromising both +endpoints of a circuit can confirm this with high probability. If +the entire path is compromised, this becomes a certainty; however, +the added benefit to the adversary of such an attack is small in +relation to the difficulty. + +\emph{Run a hostile directory server.} Directory servers control +admission to the network. However, because the network directory +must be signed by a majority of servers, the threat of a single +hostile server is minimized. -\item \emph{Selectively DoS a Tor node.} As noted, neighbors are - bandwidth limited; however, it is possible to open up sufficient - circuits that converge at a single onion router to - overwhelm its network connection, its ability to process new - circuits, or both. +\emph{Selectively DoS a Tor node.} As noted, neighbors are +bandwidth limited; however, it is possible to open up sufficient +circuits that converge at a single onion router to +overwhelm its network connection, its ability to process new +circuits, or both. % We aim to address something like this attack with our congestion % control algorithm. -\item \emph{Introduce timing into messages.} This is simply a stronger - version of passive timing attacks already discussed above. +\emph{Introduce timing into messages.} This is simply a stronger +version of passive timing attacks already discussed above. -\item \emph{Tagging attacks.} A hostile node could ``tag'' a - cell by altering it. This would render it unreadable, but if the - stream is, for example, an unencrypted request to a Web site, - the garbled content coming out at the appropriate time could confirm - the association. However, integrity checks on cells prevent - this attack. - -\item \emph{Replace contents of unauthenticated protocols.} When - relaying an unauthenticated protocol like HTTP, a hostile exit node - can impersonate the target server. Thus, whenever possible, clients - should prefer protocols with end-to-end authentication. - -\item \emph{Replay attacks.} Some anonymity protocols are vulnerable - to replay attacks. Tor is not; replaying one side of a handshake - will result in a different negotiated session key, and so the rest - of the recorded session can't be used. - % ``NonSSL Anonymizer''? - -\item \emph{Smear attacks.} An attacker could use the Tor network to - engage in socially dissapproved acts, so as to try to bring the - entire network into disrepute and get its operators to shut it down. - Exit policies can help reduce the possibilities for abuse, but - ultimately, the network will require volunteers who can tolerate - some political heat. - -\item \emph{Distribute hostile code.} An attacker could trick users - into running subverted Tor software that did not, in fact, anonymize - their connections---or worse, 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 - describing which versions are currently believed to be secure. To - prevent an attacker from subverting the official release itself - (through threats, bribery, or insider attacks), we provide all - 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. -\end{tightlist} +\emph{Tagging attacks.} A hostile node could ``tag'' a +cell by altering it. This would render it unreadable, but if the +stream is, for example, an unencrypted request to a Web site, +the garbled content coming out at the appropriate time could confirm +the association. However, integrity checks on cells prevent +this attack. + +\emph{Replace contents of unauthenticated protocols.} When +relaying an unauthenticated protocol like HTTP, a hostile exit node +can impersonate the target server. Thus, whenever possible, clients +should prefer protocols with end-to-end authentication. + +\emph{Replay attacks.} Some anonymity protocols are vulnerable +to replay attacks. Tor is not; replaying one side of a handshake +will result in a different negotiated session key, and so the rest +of the recorded session can't be used. + +\emph{Smear attacks.} An attacker could use the Tor network to +engage in socially dissapproved acts, so as to try to bring the +entire network into disrepute and get its operators to shut it down. +Exit policies can help reduce the possibilities for abuse, but +ultimately, the network will require volunteers who can tolerate +some political heat. + +\emph{Distribute hostile code.} An attacker could trick users +into running subverted Tor software that did not, in fact, anonymize +their connections---or worse, 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 +describing which versions are currently believed to be secure. To +prevent an attacker from subverting the official release itself +(through threats, bribery, or insider attacks), we provide all +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. \subsubsection*{Directory attacks} -\begin{tightlist} -\item \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, - they will still broadcast their views of the network and generate a - consensus directory. (If more than half are destroyed, this - directory will not, however, have enough signatures for clients to - use it automatically; human intervention will be necessary for - clients to decide whether to trust the resulting directory, or continue - to use the old valid one.) - -\item \emph{Subvert a directory server.} By taking over a directory - server, an attacker can influence (but not control) the final - directory. Since ORs are included or excluded by majority vote, - the corrupt directory can at worst cast a tie-breaking vote to - decide whether to include marginal ORs. How often such marginal - cases will occur in practice, however, remains to be seen. - -\item \emph{Subvert a majority of directory servers.} If the - adversary controls more than half of the directory servers, he can - decide on a final directory, and thus can include as many - compromised ORs in the final directory as he wishes. Other than - trying to ensure that directory server operators are truly - independent and resistant to attack, Tor does not address this - possibility. - -\item \emph{Encourage directory server dissent.} The directory - agreement protocol requires that directory server operators agree on - the list of directory servers. An adversary who can persuade some - of the directory server operators to distrust one another could - split the quorum into mutually hostile camps, thus partitioning - users based on which directory they used. Tor does not address - this attack. - -\item \emph{Trick the directory servers into listing a hostile OR.} - Our threat model explicitly assumes directory server operators will - be able to filter out most hostile ORs. If this is not true, an - attacker can flood the directory with compromised servers. - -\item \emph{Convince the directories that a malfunctioning OR is - working.} In the current Tor implementation, directory servers - assume that if they can start a TLS connection to an an OR, that OR - must be running correctly. It would be easy for a hostile OR to - subvert this test by only accepting TLS connections from ORs, and - ignoring all cells. Thus, directory servers must actively test ORs - by building circuits and streams as appropriate. The benefits and - hazards of a similar approach are discussed in \cite{mix-acc}. - -\end{tightlist} -\subsubsection*{Attacks against rendezvous points} -\begin{tightlist} -\item \emph{Make many introduction requests.} An attacker could - attempt to deny Bob service by flooding his Introduction Point with - requests. Because the introduction point can block requests that - lack authentication tokens, however, Bob can restrict the volume of - requests he receives, or require a certain amount of computation for - every request he receives. +\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, +they will still broadcast their views of the network and generate a +consensus directory. (If more than half are destroyed, this +directory will not, however, have enough signatures for clients to +use it automatically; human intervention will be necessary for +clients to decide whether to trust the resulting directory, or continue +to use the old valid one.) + +\emph{Subvert a directory server.} By taking over a directory +server, an attacker can influence (but not control) the final +directory. Since ORs are included or excluded by majority vote, +the corrupt directory can at worst cast a tie-breaking vote to +decide whether to include marginal ORs. How often such marginal +cases will occur in practice, however, remains to be seen. + +\emph{Subvert a majority of directory servers.} If the +adversary controls more than half of the directory servers, he can +decide on a final directory, and thus can include as many +compromised ORs in the final directory as he wishes. Other than +trying to ensure that directory server operators are truly +independent and resistant to attack, Tor does not address this +possibility. + +\emph{Encourage directory server dissent.} The directory +agreement protocol requires that directory server operators agree on +the list of directory servers. An adversary who can persuade some +of the directory server operators to distrust one another could +split the quorum into mutually hostile camps, thus partitioning +users based on which directory they used. Tor does not address +this attack. + +\emph{Trick the directory servers into listing a hostile OR.} +Our threat model explicitly assumes directory server operators will +be able to filter out most hostile ORs. If this is not true, an +attacker can flood the directory with compromised servers. + +\emph{Convince the directories that a malfunctioning OR is +working.} In the current Tor implementation, directory servers +assume that if they can start a TLS connection to an an OR, that OR +must be running correctly. It would be easy for a hostile OR to +subvert this test by only accepting TLS connections from ORs, and +ignoring all cells. Thus, directory servers must actively test ORs +by building circuits and streams as appropriate. The benefits and +hazards of a similar approach are discussed in \cite{mix-acc}. -\item \emph{Attack an introduction point.} An attacker could try to - disrupt a location-hidden service by disabling its introduction - point. But because a service's identity is attached to its public - key, not its introduction point, the service can simply re-advertise - itself at a different introduction point. - -\item \emph{Attack multiple introduction points.} If an attacker is - able to disable all of the introduction points for a given service, - he can block access to the service. However, re-advertisement of - introduction points can still be done secretly so that only - high-priority clients know the address of the service's introduction - points. These selective secret authorizations can also be issued - during normal operation. Thus an attacker must disable - all possible introduction points. - -\item \emph{Compromise an introduction point.} If an attacker controls - an introduction point for a service, it can flood the service with - introduction requests, or prevent valid introduction requests from - reaching the hidden server. The server will notice a flooding - attempt if it receives many introduction requests. To notice - blocking of valid requests, however, the hidden server should - periodically test the introduction point by sending its introduction - requests, and making sure it receives them. - -\item \emph{Compromise a rendezvous point.} Controlling a rendezvous - point gains an attacker no more than controlling any other OR along - a circuit, since all data passing along the rendezvous is protected - by the session key shared by the client and server. +\subsubsection*{Attacks against rendezvous points} -\end{tightlist} +\emph{Make many introduction requests.} An attacker could +attempt to deny Bob service by flooding his Introduction Point with +requests. Because the introduction point can block requests that +lack authentication tokens, however, Bob can restrict the volume of +requests he receives, or require a certain amount of computation for +every request he receives. + +\emph{Attack an introduction point.} An attacker could try to +disrupt a location-hidden service by disabling its introduction +point. But because a service's identity is attached to its public +key, not its introduction point, the service can simply re-advertise +itself at a different introduction point. + +\emph{Attack multiple introduction points.} If an attacker is +able to disable all of the introduction points for a given service, +he can block access to the service. However, re-advertisement of +introduction points can still be done secretly so that only +high-priority clients know the address of the service's introduction +points. These selective secret authorizations can also be issued +during normal operation. Thus an attacker must disable +all possible introduction points. + +\emph{Compromise an introduction point.} If an attacker controls +an introduction point for a service, it can flood the service with +introduction requests, or prevent valid introduction requests from +reaching the hidden server. The server will notice a flooding +attempt if it receives many introduction requests. To notice +blocking of valid requests, however, the hidden server should +periodically test the introduction point by sending its introduction +requests, and making sure it receives them. + +\emph{Compromise a rendezvous point.} Controlling a rendezvous +point gains an attacker no more than controlling any other OR along +a circuit, since all data passing along the rendezvous is protected +by the session key shared by the client and server. \Section{Open Questions in Low-latency Anonymity} \label{sec:maintaining-anonymity} @@ -1901,57 +1888,61 @@ issues remaining to be ironed out. In particular: % Many of these (Scalability, cover traffic, morphmix) % are duplicates from open problems. % -\begin{tightlist} -\item \emph{Scalability:} Tor's emphasis on design simplicity and - deployability has led us to adopt a clique topology, a - semi-centralized model for directories and trusts, and a - full-network-visibility model for client knowledge. None of these - properties will scale to more than a few hundred servers, at most. - Promising approaches to better scalability exist (see - Section~\ref{sec:maintaining-anonymity}), but more deployment - experience would be helpful in learning the relative importance of - these bottlenecks. -\item \emph{Cover traffic:} Currently we avoid cover traffic because - of its clear costs in performance and bandwidth, and because its - security benefits are not well understood. With more research - \cite{SS03,defensive-dropping}, the price/value ratio may change, - both for link-level cover traffic and also long-range cover traffic. -\item \emph{Better directory distribution:} Even with the threshold - directory agreement algorithm described in Section~\ref{subsec:dirservers}, - the directory servers are still trust bottlenecks. We must find more - decentralized yet practical ways to distribute up-to-date snapshots of - network status without introducing new attacks. Also, directory - retrieval presents a scaling problem, since clients currently - download a description of the entire network state every 15 - minutes. As the state grows larger and clients more numerous, we - may need to move to a solution in which clients only receive - incremental updates to directory state, or where directories are - cached at the ORs to avoid high loads on the directory servers. + +\emph{Scalability:} Tor's emphasis on design simplicity and +deployability has led us to adopt a clique topology, a +semi-centralized model for directories and trusts, and a +full-network-visibility model for client knowledge. None of these +properties will scale to more than a few hundred servers, at most. +Promising approaches to better scalability exist (see +Section~\ref{sec:maintaining-anonymity}), but more deployment +experience would be helpful in learning the relative importance of +these bottlenecks. + +\emph{Cover traffic:} Currently we avoid cover traffic because +of its clear costs in performance and bandwidth, and because its +security benefits are not well understood. With more research +\cite{SS03,defensive-dropping}, the price/value ratio may change, +both for link-level cover traffic and also long-range cover traffic. + +\emph{Better directory distribution:} Even with the threshold +directory agreement algorithm described in Section~\ref{subsec:dirservers}, +the directory servers are still trust bottlenecks. We must find more +decentralized yet practical ways to distribute up-to-date snapshots of +network status without introducing new attacks. Also, directory +retrieval presents a scaling problem, since clients currently +download a description of the entire network state every 15 +minutes. As the state grows larger and clients more numerous, we +may need to move to a solution in which clients only receive +incremental updates to directory state, or where directories are +cached at the ORs to avoid high loads on the directory servers. % XXX this is a design paper, not an implementation paper. the design % says that they're already cached at the ORs. Agree/disagree? % XXX Agree. -NM -\item \emph{Implementing location-hidden servers:} While - Section~\ref{sec:rendezvous} describes a design for rendezvous - points and location-hidden servers, these features have not yet been - implemented. While doing so we are likely to encounter additional - issues that must be resolved, both in terms of usability and anonymity. -\item \emph{Further specification review:} Although we have a public, - byte-level specification for the Tor protocols, this protocol has - not received extensive external review. We hope that as Tor - becomes more widely deployed, more people will become interested in - examining our specification. -\item \emph{Wider-scale deployment:} The original goal of Tor was to - gain experience in deploying an anonymizing overlay network, and - learn from having actual users. We are now at the point in design - and development where we can start deploying a wider network. Once - we have many actual users, we will doubtlessly be better - able to evaluate some of our design decisions, including our - robustness/latency trade-offs, our performance trade-offs (including - cell size), our abuse-prevention mechanisms, and - our overall usability. + +\emph{Implementing location-hidden servers:} While +Section~\ref{sec:rendezvous} describes a design for rendezvous +points and location-hidden servers, these features have not yet been +implemented. While doing so we are likely to encounter additional +issues that must be resolved, both in terms of usability and anonymity. + +\emph{Further specification review:} Although we have a public, +byte-level specification for the Tor protocols, this protocol has +not received extensive external review. We hope that as Tor +becomes more widely deployed, more people will become interested in +examining our specification. + +\emph{Wider-scale deployment:} The original goal of Tor was to +gain experience in deploying an anonymizing overlay network, and +learn from having actual users. We are now at the point in design +and development where we can start deploying a wider network. Once +we have many actual users, we will doubtlessly be better +able to evaluate some of our design decisions, including our +robustness/latency trade-offs, our performance trade-offs (including +cell size), our abuse-prevention mechanisms, and +our overall usability. % XXX large and small cells on same network. % XXX work with morphmix spec -\end{tightlist} %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% |