formatting changes, no edits

design withstands them.

\subsubsection*{Passive attacks}

\begin{tightlist}

\item \emph{Observing user traffic patterns.} Observations of connection

\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

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

\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

\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

behavior.

%XXX Actually, circuitrebuildperiod is such an option. -RD

\item \emph{End-to-end Timing correlation.}  Tor only minimally hides

\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

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

\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

\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.

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}

\subsubsection*{Active attacks}

\begin{tightlist}

\item \emph{Compromise keys.}

\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

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

\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

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

\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

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

\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

Compromising an onion proxy means compromising all future connections

through it.

\item \emph{DoS non-observed nodes.} An observer who can observe some

\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 a hostile node.}  In addition to the abilities of a

\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

anonymity of the endpoints of a circuit by its observations, a

hostile node must be immediately adjacent to that endpoint. 

\item \emph{Run multiple hostile nodes.}  If an adversary is able to

\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

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

\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.

\item \emph{Run a hostile directory server.} Directory servers control

\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

\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

% We aim to address something like this attack with our congestion

% control algorithm.

\item \emph{Introduce timing into messages.} This is simply a stronger

\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

\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

\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

\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

\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

\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

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}

\subsubsection*{Directory attacks}

\begin{tightlist}

\item \emph{Destroy directory servers.}  If a few directory

\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

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

\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

\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

independent and resistant to attack, Tor does not address this

possibility.

\item \emph{Encourage directory server dissent.}  The directory

\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

users based on which directory they used.  Tor does not address

this attack.

\item \emph{Trick the directory servers into listing a hostile OR.}

\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

\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

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

\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.

\item \emph{Attack an introduction point.} An attacker could try to

\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

\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

during normal operation. Thus an attacker must disable

all possible introduction points.

\item \emph{Compromise an introduction point.} If an attacker controls

\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

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

\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.

\end{tightlist}

\Section{Open Questions in Low-latency Anonymity}

\label{sec:maintaining-anonymity}

% Many of these (Scalability, cover traffic, morphmix) 

% are duplicates from open problems.

%

\begin{tightlist}

\item \emph{Scalability:} Tor's emphasis on design simplicity and

\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

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

\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

\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

% 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

\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,

\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

\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

our overall usability.

% XXX large and small cells on same network.

% XXX work with morphmix spec

\end{tightlist}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%