|
|
@@ -474,7 +474,7 @@ low-latency systems, Tor does not protect against such a strong
|
|
|
adversary. Instead, we assume an adversary who can observe some fraction
|
|
|
of network traffic; who can generate, modify, delete, or delay traffic
|
|
|
on the network; who can operate onion routers of its own; and who can
|
|
|
-compromise some fraction of the onion routers on the network.
|
|
|
+compromise some fraction of the onion routers.
|
|
|
|
|
|
In low-latency anonymity systems that use layered encryption, the
|
|
|
adversary's typical goal is to observe both the initiator and the
|
|
|
@@ -506,10 +506,9 @@ the network's reliability by attacking nodes or by performing antisocial
|
|
|
activities from reliable servers and trying to get them taken down;
|
|
|
making the network unreliable flushes users to other less anonymous
|
|
|
systems, where they may be easier to attack.
|
|
|
-
|
|
|
-We consider each of these attacks in more detail below, and summarize
|
|
|
+We summarize
|
|
|
in Section~\ref{sec:attacks} how well the Tor design defends against
|
|
|
-each of them.
|
|
|
+each of these attacks.
|
|
|
|
|
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
|
|
|
|
|
@@ -601,7 +600,6 @@ and to acknowledge), \emph{relay truncate} and \emph{relay truncated}
|
|
|
(to tear down only part of the circuit, and to acknowledge), \emph{relay
|
|
|
sendme} (used for congestion control), and \emph{relay drop} (used to
|
|
|
implement long-range dummies).
|
|
|
-
|
|
|
We describe each of these cell types and commands in more detail below.
|
|
|
|
|
|
\SubSection{Circuits and streams}
|
|
|
@@ -623,11 +621,12 @@ even heavy users spend a negligible amount of time and CPU in
|
|
|
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.
|
|
|
+without delaying streams and thereby harming user experience.\\
|
|
|
|
|
|
-\subsubsection{Constructing a circuit}
|
|
|
+\noindent {\large Constructing a circuit}\\
|
|
|
+%\subsubsection{Constructing a circuit}
|
|
|
\label{subsubsec:constructing-a-circuit}
|
|
|
-
|
|
|
+%
|
|
|
A user's OP constructs a circuit 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
|
|
|
@@ -687,10 +686,11 @@ 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
|
|
|
-traditional Dolev-Yao model.
|
|
|
-
|
|
|
-\subsubsection{Relay cells}
|
|
|
+traditional Dolev-Yao model.\\
|
|
|
|
|
|
+\noindent {\large 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
|
|
|
@@ -1382,11 +1382,10 @@ acknowledge his existence.
|
|
|
\Section{Attacks and Defenses}
|
|
|
\label{sec:attacks}
|
|
|
|
|
|
-Below we summarize a variety of attacks, and discuss how well our
|
|
|
-design withstands them.
|
|
|
-
|
|
|
-\subsubsection*{Passive attacks}
|
|
|
+%Below we summarize a variety of attacks, and discuss how well our
|
|
|
+%design withstands them.\\
|
|
|
|
|
|
+\noindent{\large 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
|
|
|
@@ -1452,10 +1451,9 @@ all circuits through the network, combined with those from the
|
|
|
network edges to the targeted user and the responder website. While
|
|
|
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.}
|
|
|
-
|
|
|
-\subsubsection*{Active attacks}
|
|
|
+current evidence of their practicality.}\\
|
|
|
|
|
|
+\noindent {\large 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,10 +1578,9 @@ 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}
|
|
|
+us!) that comes without source.\\
|
|
|
|
|
|
+\noindent{\large 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,
|
|
|
@@ -1629,10 +1626,9 @@ connection to it. A hostile OR could easily subvert this test by
|
|
|
accepting TLS connections from ORs but ignoring all cells. Directory
|
|
|
servers must actively test ORs by building circuits and streams as
|
|
|
appropriate. The tradeoffs of a similar approach are discussed in
|
|
|
-\cite{mix-acc}.
|
|
|
+\cite{mix-acc}.\\
|
|
|
|
|
|
-\subsubsection*{Attacks against rendezvous points}
|
|
|
-
|
|
|
+\noindent {\large 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
|
Paul Syverson