mirror of
https://gitlab.torproject.org/tpo/core/tor.git
synced 2024-11-13 06:33:44 +01:00
you guessed it, more edits
svn:r753
This commit is contained in:
parent
f081a7a41f
commit
9944853468
@ -116,24 +116,8 @@ relies on the filtering features of privacy-enhancing
|
|||||||
application-level proxies such as Privoxy \cite{privoxy}, without trying
|
application-level proxies such as Privoxy \cite{privoxy}, without trying
|
||||||
to duplicate those features itself.
|
to duplicate those features itself.
|
||||||
|
|
||||||
\item \textbf{Many TCP streams can share one circuit:} The
|
\item \textbf{No mixing, padding, or traffic shaping yet:} The original
|
||||||
original Onion Routing design built a separate circuit for each
|
Onion
|
||||||
application-level request. This hurt performance by requiring
|
|
||||||
multiple public key operations for every request, and also presented
|
|
||||||
a threat to anonymity from building so many different circuits; see
|
|
||||||
Section~\ref{sec:maintaining-anonymity}. Tor multiplexes multiple TCP
|
|
||||||
streams along each virtual circuit to improve efficiency and anonymity.
|
|
||||||
|
|
||||||
\item \textbf{Leaky-pipe circuit topology:} Through in-band signaling
|
|
||||||
within the circuit, Tor initiators can direct traffic to nodes partway
|
|
||||||
down the circuit. This novel approach allows for long-range
|
|
||||||
padding to frustrate traffic shape and volume attacks at the initiator
|
|
||||||
\cite{defensive-dropping}, and
|
|
||||||
also allows traffic to exit the circuit from the middle---thus
|
|
||||||
frustrating traffic shape and volume attacks based on observing the end
|
|
||||||
of the circuit.
|
|
||||||
|
|
||||||
\item \textbf{No mixing, padding, or traffic shaping:} The original Onion
|
|
||||||
Routing design called for batching and reordering the cells arriving from
|
Routing design called for batching and reordering the cells arriving from
|
||||||
each source. It also included padding between onion routers and, in a
|
each source. It also included padding between onion routers and, in a
|
||||||
later design, between onion proxies (that is, users) and onion routers
|
later design, between onion proxies (that is, users) and onion routers
|
||||||
@ -148,6 +132,23 @@ have a proven and convenient design for traffic shaping or low-latency
|
|||||||
mixing that will improve anonymity against a realistic adversary, we
|
mixing that will improve anonymity against a realistic adversary, we
|
||||||
leave these strategies out.
|
leave these strategies out.
|
||||||
|
|
||||||
|
\item \textbf{Many TCP streams can share one circuit:} The
|
||||||
|
original Onion Routing design built a separate circuit for each
|
||||||
|
application-level request. This hurt performance by requiring
|
||||||
|
multiple public key operations for every request, and also presented
|
||||||
|
a threat to anonymity from building so many different circuits; see
|
||||||
|
Section~\ref{sec:maintaining-anonymity}. Tor multiplexes multiple TCP
|
||||||
|
streams along each virtual circuit to improve efficiency and anonymity.
|
||||||
|
|
||||||
|
\item \textbf{Leaky-pipe circuit topology:} Through in-band signaling
|
||||||
|
within the circuit, Tor initiators can direct traffic to nodes partway
|
||||||
|
down the circuit. This novel approach allows for long-range padding if
|
||||||
|
future research indicates that it can frustrate traffic shape and volume
|
||||||
|
attacks at the initiator \cite{defensive-dropping}, and
|
||||||
|
also allows traffic to exit the circuit from the middle---again possibly
|
||||||
|
frustrating traffic shape and volume attacks based on observing the end
|
||||||
|
of the circuit.
|
||||||
|
|
||||||
\item \textbf{Congestion control:} Earlier anonymity designs do not
|
\item \textbf{Congestion control:} Earlier anonymity designs do not
|
||||||
address traffic bottlenecks. Unfortunately, typical approaches to
|
address traffic bottlenecks. Unfortunately, typical approaches to
|
||||||
load balancing and flow control in overlay networks involve inter-node
|
load balancing and flow control in overlay networks involve inter-node
|
||||||
@ -237,16 +238,19 @@ the cost of introducing comparatively large and variable latencies,
|
|||||||
including {\bf Babel} \cite{babel}, {\bf Mixmaster}
|
including {\bf Babel} \cite{babel}, {\bf Mixmaster}
|
||||||
\cite{mixmaster-spec}, and
|
\cite{mixmaster-spec}, and
|
||||||
{\bf Mixminion} \cite{minion-design}. Because of this
|
{\bf Mixminion} \cite{minion-design}. Because of this
|
||||||
decision, these \emph{high-latency} networks are well-suited for anonymous
|
decision, these \emph{high-latency} networks resist strong global
|
||||||
email, but introduce too much lag for interactive tasks like web browsing,
|
adversaries,
|
||||||
|
but introduce too much lag for interactive tasks like web browsing,
|
||||||
internet chat, or SSH connections.
|
internet chat, or SSH connections.
|
||||||
|
|
||||||
Tor belongs to the second category: \emph{low-latency} designs that
|
Tor belongs to the second category: \emph{low-latency} designs that
|
||||||
attempt to anonymize interactive network traffic. These systems handle
|
attempt to anonymize interactive network traffic. These systems handle
|
||||||
a variety of bidirectional protocols. They also provide more convenient
|
a variety of bidirectional protocols.
|
||||||
mail delivery than the high-latency fire-and-forget anonymous email
|
% They also provide more convenient
|
||||||
networks, because the remote mail server provides explicit delivery
|
%mail delivery than the high-latency fire-and-forget anonymous email
|
||||||
confirmation. But because these designs typically
|
%networks, because the remote mail server provides explicit delivery
|
||||||
|
%confirmation.
|
||||||
|
But because these designs typically
|
||||||
involve many packets that must be delivered quickly, it is
|
involve many packets that must be delivered quickly, it is
|
||||||
difficult for them to prevent an attacker who can eavesdrop both ends of the
|
difficult for them to prevent an attacker who can eavesdrop both ends of the
|
||||||
communication from correlating the timing and volume
|
communication from correlating the timing and volume
|
||||||
@ -482,7 +486,7 @@ suspicion that Alice is
|
|||||||
talking to Bob if the timing and volume patterns of the traffic on the
|
talking to Bob if the timing and volume patterns of the traffic on the
|
||||||
connection are distinct enough; active attackers can induce timing
|
connection are distinct enough; active attackers can induce timing
|
||||||
signatures on the traffic to \emph{force} distinct patterns. Tor
|
signatures on the traffic to \emph{force} distinct patterns. Tor
|
||||||
does not address these \emph{traffic confirmation} attacks.
|
does not yet address these \emph{traffic confirmation} attacks.
|
||||||
Rather, we aim to prevent \emph{traffic
|
Rather, we aim to prevent \emph{traffic
|
||||||
analysis} attacks, where the adversary uses traffic patterns to learn
|
analysis} attacks, where the adversary uses traffic patterns to learn
|
||||||
which points in the network he should attack.
|
which points in the network he should attack.
|
||||||
@ -793,8 +797,8 @@ Privoxy safely. But a portable general solution, such as is needed for
|
|||||||
SSH, is
|
SSH, is
|
||||||
an open problem. Modifying or replacing the local nameserver
|
an open problem. Modifying or replacing the local nameserver
|
||||||
can be invasive, brittle, and not portable. Forcing the resolver
|
can be invasive, brittle, and not portable. Forcing the resolver
|
||||||
library to do its resolution via TCP rather than UDP is
|
library to do resolution via TCP rather than UDP is
|
||||||
hard to do right, and also has portability problems. We could provide a
|
hard, and also has portability problems. We could provide a
|
||||||
tool similar to \emph{dig} to perform a private lookup through the
|
tool similar to \emph{dig} to perform a private lookup through the
|
||||||
Tor network. Our current answer is to encourage the use of
|
Tor network. Our current answer is to encourage the use of
|
||||||
privacy-aware proxies like Privoxy wherever possible.
|
privacy-aware proxies like Privoxy wherever possible.
|
||||||
@ -1370,7 +1374,7 @@ acknowledge his existence.
|
|||||||
\Section{Attacks and Defenses}
|
\Section{Attacks and Defenses}
|
||||||
\label{sec:attacks}
|
\label{sec:attacks}
|
||||||
|
|
||||||
% XXX In sec4 we should talk about bandwidth classes, which will
|
% XXX In sec9 we should talk about bandwidth classes, which will
|
||||||
% enable us to accept a lot more ORs than if we continue to
|
% enable us to accept a lot more ORs than if we continue to
|
||||||
% require 10mbit connections for all ORs. -RD
|
% require 10mbit connections for all ORs. -RD
|
||||||
|
|
||||||
@ -1380,21 +1384,18 @@ design withstands them.
|
|||||||
|
|
||||||
\subsubsection*{Passive attacks}
|
\subsubsection*{Passive attacks}
|
||||||
|
|
||||||
\emph{Observing user traffic patterns.} Observations of connection
|
\emph{Observing user traffic patterns.} Observing the connection
|
||||||
between a user and her first onion router will not reveal to whom
|
from the user will not reveal her destination or data, but it will
|
||||||
the user is connecting or what information is being sent. It will
|
reveal traffic patterns (both sent and received). Profiling via user
|
||||||
reveal patterns of user traffic (both sent and received). Simple
|
connection patterns is hampered because multiple application streams may
|
||||||
profiling of user connection patterns is not generally possible,
|
be operating simultaneously or in series over a single circuit. Thus,
|
||||||
however, because multiple application streams may be operating
|
further processing is necessary to discern even these usage patterns.
|
||||||
simultaneously or in series over a single circuit. Thus, further
|
|
||||||
processing is necessary to discern even these usage patterns.
|
|
||||||
|
|
||||||
\emph{Observing user content.} At the user end, content is
|
\emph{Observing user content.} While content at the user end is encrypted,
|
||||||
encrypted; however, connections from the network to arbitrary
|
connections to responders may not be (further, the responding website
|
||||||
websites may not be. Further, a responding website may itself be
|
itself may be hostile). Filtering content is not a primary goal of Onion
|
||||||
hostile. Filtering content is not a primary goal of
|
Routing; nonetheless, Tor can directly use Privoxy and related
|
||||||
Onion Routing; nonetheless, Tor can directly make use of Privoxy and
|
filtering services to anonymize application data streams.
|
||||||
related filtering services to anonymize application data streams.
|
|
||||||
|
|
||||||
\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
|
source of distinguishable patterns. In general there is economic
|
||||||
@ -1524,12 +1525,6 @@ adversary
|
|||||||
could possibly attract a disproportionately large amount of traffic
|
could possibly attract a disproportionately large amount of traffic
|
||||||
by running an exit node with an unusually permissive exit policy.
|
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
|
\emph{Run a hostile directory server.} Directory servers control
|
||||||
admission to the network. However, because the network directory
|
admission to the network. However, because the network directory
|
||||||
must be signed by a majority of servers, the threat of a single
|
must be signed by a majority of servers, the threat of a single
|
||||||
@ -1676,18 +1671,17 @@ by the session key shared by the client and server.
|
|||||||
% There must be a better intro than this! -NM
|
% There must be a better intro than this! -NM
|
||||||
In addition to the open problems discussed in
|
In addition to the open problems discussed in
|
||||||
Section~\ref{subsec:non-goals}, many other questions remain to be
|
Section~\ref{subsec:non-goals}, many other questions remain to be
|
||||||
solved by future research before we can be confident that we
|
solved by future research before we can be confident of our security.
|
||||||
have built a secure low-latency anonymity service.
|
|
||||||
|
|
||||||
Many of these open issues are questions of balance. For example,
|
Many of these open issues are questions of balance. For example,
|
||||||
how often should users rotate to fresh circuits? Too-frequent
|
how often should users rotate to fresh circuits? Too-frequent
|
||||||
rotation is inefficient, expensive, and may lead to intersection attacks,
|
rotation is inefficient, expensive, and may lead to intersection attacks
|
||||||
|
and predecessor attacks \cite{wright03},
|
||||||
but too-infrequent rotation
|
but too-infrequent rotation
|
||||||
makes the user's traffic linkable. Instead of opening a fresh
|
makes the user's traffic linkable. Along with opening a fresh
|
||||||
circuit; clients can also limit linkability by exiting from a middle point
|
circuit, clients can also limit linkability by exiting from a middle point
|
||||||
of the circuit, or by truncating and re-extending the circuit, but
|
of the circuit, or by truncating and re-extending the circuit; but
|
||||||
more analysis is needed to determine the proper trade-off.
|
more analysis is needed to determine the proper trade-off.
|
||||||
%[XXX mention predecessor attacks?]
|
|
||||||
|
|
||||||
A similar question surrounds timing of directory operations:
|
A similar question surrounds timing of directory operations:
|
||||||
how often should directories be updated? With too-infrequent
|
how often should directories be updated? With too-infrequent
|
||||||
@ -1696,7 +1690,6 @@ too-frequent updates the directory servers are overloaded.
|
|||||||
|
|
||||||
%do different exit policies at different exit nodes trash anonymity sets,
|
%do different exit policies at different exit nodes trash anonymity sets,
|
||||||
%or not mess with them much?
|
%or not mess with them much?
|
||||||
%
|
|
||||||
%% Why would they? By routing traffic to certain nodes preferentially?
|
%% Why would they? By routing traffic to certain nodes preferentially?
|
||||||
|
|
||||||
%[XXX Choosing paths and path lengths: I'm not writing this bit till
|
%[XXX Choosing paths and path lengths: I'm not writing this bit till
|
||||||
|
Loading…
Reference in New Issue
Block a user