mirror of
https://gitlab.torproject.org/tpo/core/tor.git
synced 2024-11-10 13:13:44 +01:00
More space hacks. No content removal.
svn:r758
This commit is contained in:
parent
e1ac0c03de
commit
7f350d80b1
@ -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
|
adversary. Instead, we assume an adversary who can observe some fraction
|
||||||
of network traffic; who can generate, modify, delete, or delay traffic
|
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
|
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
|
In low-latency anonymity systems that use layered encryption, the
|
||||||
adversary's typical goal is to observe both the initiator and 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;
|
activities from reliable servers and trying to get them taken down;
|
||||||
making the network unreliable flushes users to other less anonymous
|
making the network unreliable flushes users to other less anonymous
|
||||||
systems, where they may be easier to attack.
|
systems, where they may be easier to attack.
|
||||||
|
We summarize
|
||||||
We consider each of these attacks in more detail below, and summarize
|
|
||||||
in Section~\ref{sec:attacks} how well the Tor design defends against
|
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
|
(to tear down only part of the circuit, and to acknowledge), \emph{relay
|
||||||
sendme} (used for congestion control), and \emph{relay drop} (used to
|
sendme} (used for congestion control), and \emph{relay drop} (used to
|
||||||
implement long-range dummies).
|
implement long-range dummies).
|
||||||
|
|
||||||
We describe each of these cell types and commands in more detail below.
|
We describe each of these cell types and commands in more detail below.
|
||||||
|
|
||||||
\SubSection{Circuits and streams}
|
\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
|
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
|
to each other through a given exit node. Also, because circuits are built
|
||||||
in the background, OPs can recover from failed circuit creation
|
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}
|
\label{subsubsec:constructing-a-circuit}
|
||||||
|
%
|
||||||
A user's OP constructs a circuit incrementally, negotiating a
|
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
|
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
|
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
|
hold both a public key and a signature. Preliminary analysis with the
|
||||||
NRL protocol analyzer \cite{meadows96} shows the above protocol to be
|
NRL protocol analyzer \cite{meadows96} shows the above protocol to be
|
||||||
secure (including providing perfect forward secrecy) under the
|
secure (including providing perfect forward secrecy) under the
|
||||||
traditional Dolev-Yao model.
|
traditional Dolev-Yao model.\\
|
||||||
|
|
||||||
\subsubsection{Relay cells}
|
|
||||||
|
|
||||||
|
\noindent {\large Relay cells}\\
|
||||||
|
%\subsubsection{Relay cells}
|
||||||
|
%
|
||||||
Once Alice has established the circuit (so she shares keys with each
|
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
|
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 in the relay header that indicates to which
|
||||||
@ -1382,11 +1382,10 @@ acknowledge his existence.
|
|||||||
\Section{Attacks and Defenses}
|
\Section{Attacks and Defenses}
|
||||||
\label{sec:attacks}
|
\label{sec:attacks}
|
||||||
|
|
||||||
Below we summarize a variety of attacks, and discuss how well our
|
%Below we summarize a variety of attacks, and discuss how well our
|
||||||
design withstands them.
|
%design withstands them.\\
|
||||||
|
|
||||||
\subsubsection*{Passive attacks}
|
|
||||||
|
|
||||||
|
\noindent{\large Passive attacks}\\
|
||||||
\emph{Observing user traffic patterns.} Observing the connection
|
\emph{Observing user traffic patterns.} Observing the connection
|
||||||
from the user will not reveal her destination or data, but it will
|
from the user will not reveal her destination or data, but it will
|
||||||
reveal traffic patterns (both sent and received). Profiling via user
|
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
|
network edges to the targeted user and the responder website. While
|
||||||
these are in principle feasible and surprises are always possible,
|
these are in principle feasible and surprises are always possible,
|
||||||
these constitute a much more complicated attack, and there is no
|
these constitute a much more complicated attack, and there is no
|
||||||
current evidence of their practicality.}
|
current evidence of their practicality.}\\
|
||||||
|
|
||||||
\subsubsection*{Active attacks}
|
|
||||||
|
|
||||||
|
\noindent {\large Active attacks}\\
|
||||||
\emph{Compromise keys.} An attacker who learns the TLS session key can
|
\emph{Compromise keys.} An attacker who learns the TLS session key can
|
||||||
see control cells and encrypted relay cells on every circuit on that
|
see control cells and encrypted relay cells on every circuit on that
|
||||||
connection; learning a circuit
|
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
|
(through threats, bribery, or insider attacks), we provide all
|
||||||
releases in source code form, encourage source audits, and
|
releases in source code form, encourage source audits, and
|
||||||
frequently warn our users never to trust any software (even from
|
frequently warn our users never to trust any software (even from
|
||||||
us!) that comes without source.
|
us!) that comes without source.\\
|
||||||
|
|
||||||
\subsubsection*{Directory attacks}
|
|
||||||
|
|
||||||
|
\noindent{\large Directory attacks}\\
|
||||||
\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
|
servers drop out of operation, the others still arrive at a final
|
||||||
directory. So long as any directory servers remain in operation,
|
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
|
accepting TLS connections from ORs but ignoring all cells. Directory
|
||||||
servers must actively test ORs by building circuits and streams as
|
servers must actively test ORs by building circuits and streams as
|
||||||
appropriate. The tradeoffs of a similar approach are discussed in
|
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
|
\emph{Make many introduction requests.} An attacker could
|
||||||
try to deny Bob service by flooding his Introduction Point with
|
try to deny Bob service by flooding his Introduction Point with
|
||||||
requests. Because the introduction point can block requests that
|
requests. Because the introduction point can block requests that
|
||||||
|
Loading…
Reference in New Issue
Block a user