mirror of
https://gitlab.torproject.org/tpo/core/tor.git
synced 2024-11-24 04:13:28 +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
|
||||
to duplicate those features itself.
|
||||
|
||||
\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 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
|
||||
\item \textbf{No mixing, padding, or traffic shaping yet:} The original
|
||||
Onion
|
||||
Routing design called for batching and reordering the cells arriving from
|
||||
each source. It also included padding between onion routers and, in a
|
||||
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
|
||||
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
|
||||
address traffic bottlenecks. Unfortunately, typical approaches to
|
||||
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}
|
||||
\cite{mixmaster-spec}, and
|
||||
{\bf Mixminion} \cite{minion-design}. Because of this
|
||||
decision, these \emph{high-latency} networks are well-suited for anonymous
|
||||
email, but introduce too much lag for interactive tasks like web browsing,
|
||||
decision, these \emph{high-latency} networks resist strong global
|
||||
adversaries,
|
||||
but introduce too much lag for interactive tasks like web browsing,
|
||||
internet chat, or SSH connections.
|
||||
|
||||
Tor belongs to the second category: \emph{low-latency} designs that
|
||||
attempt to anonymize interactive network traffic. These systems handle
|
||||
a variety of bidirectional protocols. They also provide more convenient
|
||||
mail delivery than the high-latency fire-and-forget anonymous email
|
||||
networks, because the remote mail server provides explicit delivery
|
||||
confirmation. But because these designs typically
|
||||
a variety of bidirectional protocols.
|
||||
% They also provide more convenient
|
||||
%mail delivery than the high-latency fire-and-forget anonymous email
|
||||
%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
|
||||
difficult for them to prevent an attacker who can eavesdrop both ends of the
|
||||
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
|
||||
connection are distinct enough; active attackers can induce timing
|
||||
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
|
||||
analysis} attacks, where the adversary uses traffic patterns to learn
|
||||
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
|
||||
an open problem. Modifying or replacing the local nameserver
|
||||
can be invasive, brittle, and not portable. Forcing the resolver
|
||||
library to do its resolution via TCP rather than UDP is
|
||||
hard to do right, and also has portability problems. We could provide a
|
||||
library to do resolution via TCP rather than UDP is
|
||||
hard, and also has portability problems. We could provide a
|
||||
tool similar to \emph{dig} to perform a private lookup through the
|
||||
Tor network. Our current answer is to encourage the use of
|
||||
privacy-aware proxies like Privoxy wherever possible.
|
||||
@ -1370,7 +1374,7 @@ acknowledge his existence.
|
||||
\Section{Attacks and Defenses}
|
||||
\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
|
||||
% require 10mbit connections for all ORs. -RD
|
||||
|
||||
@ -1380,21 +1384,18 @@ design withstands them.
|
||||
|
||||
\subsubsection*{Passive attacks}
|
||||
|
||||
\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.} 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
|
||||
connection patterns is hampered 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 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{Observing user content.} While content at the user end is encrypted,
|
||||
connections to responders may not be (further, the responding website
|
||||
itself may be hostile). Filtering content is not a primary goal of Onion
|
||||
Routing; nonetheless, Tor can directly use 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
|
||||
@ -1524,12 +1525,6 @@ 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
|
||||
@ -1676,18 +1671,17 @@ by the session key shared by the client and server.
|
||||
% There must be a better intro than this! -NM
|
||||
In addition to the open problems discussed in
|
||||
Section~\ref{subsec:non-goals}, many other questions remain to be
|
||||
solved by future research before we can be confident that we
|
||||
have built a secure low-latency anonymity service.
|
||||
solved by future research before we can be confident of our security.
|
||||
|
||||
Many of these open issues are questions of balance. For example,
|
||||
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
|
||||
makes the user's traffic linkable. Instead of opening a fresh
|
||||
circuit; clients can also limit linkability by exiting from a middle point
|
||||
of the circuit, or by truncating and re-extending the circuit, but
|
||||
makes the user's traffic linkable. Along with opening a fresh
|
||||
circuit, clients can also limit linkability by exiting from a middle point
|
||||
of the circuit, or by truncating and re-extending the circuit; but
|
||||
more analysis is needed to determine the proper trade-off.
|
||||
%[XXX mention predecessor attacks?]
|
||||
|
||||
A similar question surrounds timing of directory operations:
|
||||
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,
|
||||
%or not mess with them much?
|
||||
%
|
||||
%% Why would they? By routing traffic to certain nodes preferentially?
|
||||
|
||||
%[XXX Choosing paths and path lengths: I'm not writing this bit till
|
||||
|
Loading…
Reference in New Issue
Block a user