torproject/tor
1
0
Fork 0
mirror of https://gitlab.torproject.org/tpo/core/tor.git synced 2024-12-06 19:41:15 +01:00
Code Issues Actions Packages Projects Releases Wiki Activity

commit fixes for the first half of the paper

Browse Source 
still need to do an overall pass to reduce redundancy


svn:r3560
This commit is contained in:
Roger Dingledine
2005-02-05 01:03:17 +00:00
parent 7240950230
commit 0ff41a3b37
1 changed files with 110 additions and 105 deletions
Download Patch File Download Diff File Expand all files Collapse all files
doc/design-paper/challenges.tex
+110 -105
View File
@@ -14,7 +14,7 @@
\begin{document}
\title{Challenges in practical low-latency stream anonymity (DRAFT)}
\title{Challenges in deploying low-latency anonymity (DRAFT)}
\author{Roger Dingledine and Nick Mathewson}
\institute{The Free Haven Project\\
@@ -58,7 +58,7 @@ we fall prey to a variety
of intra-network~\cite{back01,attack-tor-oak05,flow-correlation04} and
end-to-end~\cite{danezis-pet2004,SS03} anonymity-breaking attacks.
Tor is secure so long as adversaries are unable to
Users are safe so long as adversaries are unable to
observe connections as they both enter and leave the Tor network.
Therefore, Tor's defense lies in having a diverse enough set of servers
that most real-world
@@ -77,7 +77,7 @@ to do operations on the Internet without being noticed.
Tor research and development has been funded by the U.S.~Navy and DARPA
for use in securing government
communications, and also by the Electronic Frontier Foundation, for use
communications, and by the Electronic Frontier Foundation, for use
in maintaining civil liberties for ordinary citizens online. The Tor
protocol is one of the leading choices
to be the anonymizing layer in the European Union's PRIME directive to
@@ -87,10 +87,9 @@ their popular Java Anon Proxy anonymizing client. This wide variety of
interests helps maintain both the stability and the security of the
network.
%awk
Tor's principal research strategy, in attempting to deploy a network that is
practical, useful, and anonymous, has been to insist, when trade-offs arise
between these properties, on remaining useful enough to attract many users,
The ideal Tor network would be practical, useful and and anonymous. When
trade-offs arise between these properties, Tor's research strategy has been
to insist on remaining useful enough to attract many users,
and practical enough to support them. Subject to these
constraints, we aim to maximize anonymity. This is not the only possible
direction in anonymity research: designs exist that provide more anonymity
@@ -107,36 +106,41 @@ of what makes a system ``practical'' for volunteer operators and ``useful''
for home users, and helps illuminate undernoticed issues which any deployed
volunteer anonymity network will need to address.
While~\cite{tor-design} gives an overall view of the Tor design and goals,
While the Tor design paper~\cite{tor-design} gives an overall view its
design and goals,
this paper describes the policy and technical issues that Tor faces as
we continue deployment. Rather than trying to provide complete solutions
to every problem here, we lay out the assumptions and constraints
that we have observed through deploying Tor in the wild. In doing so, we
aim to create a research agenda for others to
help in addressing these issues. Section~\ref{sec:what-is-tor} gives an
overview of the Tor
design and ours goals. Sections~\ref{sec:crossroads-policy}
and~\ref{sec:crossroads-design} go on to describe the practical challenges,
both policy and technical respectively, that stand in the way of moving
from a practical useful network to a practical useful anonymous network.
help in addressing these issues.
% Section~\ref{sec:what-is-tor} gives an
%overview of the Tor
%design and ours goals. Sections~\ref{sec:crossroads-policy}
%and~\ref{sec:crossroads-design} go on to describe the practical challenges,
%both policy and technical respectively,
%that stand in the way of moving
%from a practical useful network to a practical useful anonymous network.
%\section{What Is Tor}
\section{Distributed trust: safety in numbers}
\label{sec:what-is-tor}
Here we give a basic overview of the Tor design and its properties. For
details on the design, assumptions, and security arguments, we refer
the reader to the Tor design paper~\cite{tor-design}.
%Here we give a basic overview of the Tor design and its properties. For
%details on the design, assumptions, and security arguments, we refer
%the reader to the Tor design paper~\cite{tor-design}.
% XXX this section needs to mention that we have exit policies.
Tor provides \emph{forward privacy}, so that users can connect to
Internet sites without revealing their logical or physical locations
to those sites or to observers. It also provides \emph{location-hidden
services}, so that critical servers can support authorized users without
giving adversaries an effective vector for physical or online attacks.
The design provides this protection even when a portion of its own
The design provides these protections even when a portion of its own
infrastructure is controlled by an adversary.
To create a private network pathway with Tor, the user's software (client)
To create a private network pathway with Tor, the client
incrementally builds a \emph{circuit} of encrypted connections through
servers on the network. The circuit is extended one hop at a time, and
each server along the way knows only which server gave it data and which
@@ -144,16 +148,11 @@ server it is giving data to. No individual server ever knows the complete
path that a data packet has taken. The client negotiates a separate set
of encryption keys for each hop along the circuit to ensure that each
hop can't trace these connections as they pass through.
Once a circuit has been established, many kinds of data can be exchanged
and several different sorts of software applications can be deployed over
the Tor network. Because each server sees no more than one hop in the
Because each server sees no more than one hop in the
circuit, neither an eavesdropper nor a compromised server can use traffic
analysis to link the connection's source and destination. Tor only works
for TCP streams and can be used by any application with SOCKS support.
analysis to link the connection's source and destination.
For efficiency, the Tor software uses the same circuit for connections
that happen within the same minute or so. Later requests are given a new
that happen within the same short period. Later requests are given a new
circuit, to prevent long-term linkability between different actions by
a single user.
@@ -175,7 +174,7 @@ in its security and flexibility. Mix networks such as
Mixmaster~\cite{mixmaster-spec} or its successor Mixminion~\cite{minion-design}
gain the highest degrees of anonymity at the expense of introducing highly
variable delays, thus making them unsuitable for applications such as web
browsing that require quick response times. Commercial single-hop
browsing. Commercial single-hop
proxies~\cite{anonymizer} present a single point of failure, where
a single compromise can expose all users' traffic, and a single-point
eavesdropper can perform traffic analysis on the entire network.
@@ -202,7 +201,7 @@ the Tor design includes an enclave approach that lets data be encrypted
(and authenticated) end-to-end, so high-sensitivity users can be sure it
hasn't been read or modified. This even works for Internet services that
don't have built-in encryption and authentication, such as unencrypted
HTTP or chat, and it requires no modification of those services to do so.
HTTP or chat, and it requires no modification of those services.
As of January 2005, the Tor network has grown to around a hundred servers
on four continents, with a total capacity exceeding 1Gbit/s. Appendix A
@@ -218,12 +217,9 @@ to join the network.
Tor is not the only anonymity system that aims to be practical and useful.
Commercial single-hop proxies~\cite{anonymizer}, as well as unsecured
open proxies around the Internet, can provide good
performance and some security against a weaker attacker. Dresden's Java
performance and some security against a weaker attacker. The Java
Anon Proxy~\cite{web-mix} provides similar functionality to Tor but only
handles web browsing rather than arbitrary TCP\@. Also, JAP's network
topology uses cascades (fixed routes through the network); since without
end-to-end padding it is just as vulnerable as Tor to end-to-end timing
attacks, its dispersal properties are therefore worse than Tor's.
handles web browsing rather than arbitrary TCP\@.
%Some peer-to-peer file-sharing overlay networks such as
%Freenet~\cite{freenet} and Mute~\cite{mute}
Zero-Knowledge Systems' commercial Freedom
@@ -239,7 +235,6 @@ have not yet been fielded. We direct the interested reader to Section
%six-four. crowds. i2p.
have a serious discussion of morphmix's assumptions, since they would
seem to be the direct competition. in fact tor is a flexible architecture
that would encompass morphmix, and they're nearly identical except for
@@ -259,12 +254,13 @@ introducing a prohibitive degree of traffic padding between the user and the
network, or introducing an unacceptable degree of latency (but see
Section \ref{subsec:mid-latency}).
And, it is not clear that padding works at all if we assume a
minimally active adversary that merely modifies the timing of packets
to or from the user. Thus, Tor only attempts to defend against
minimally active adversary that modifies the timing of packets
to or from the user by sending network traffic of his own. Thus, Tor
only attempts to defend against
external observers who cannot observe both sides of a user's
connection.
Against internal attackers, who sign up Tor servers, the situation is more
Against internal attackers who sign up Tor servers, the situation is more
complicated. In the simplest case, if an adversary has compromised $c$ of
$n$ servers on the Tor network, then the adversary will be able to compromise
a random circuit with probability $\frac{c^2}{n^2}$ (since the circuit
@@ -275,13 +271,13 @@ complicating factors:
is pretty certain to see a statistical sample of the user's traffic, and
thereby can build an increasingly accurate profile of her behavior. (See
\ref{subsec:helper-nodes} for possible solutions.)
\item If an adversary controls a popular service outside of the Tor network,
he can be certain of observing all connections to that service; he
\item An adversary who controls a popular service outside of the Tor network
can be certain of observing all connections to that service; he
therefore will trace connections to that service with probability
$\frac{c}{n}$.
\item Users do not in fact choose servers with uniform probability; they
favor servers with high bandwidth, and exit servers that permit connections
to their favorite services.
favor servers with high bandwidth or uptime, and exit servers that
permit connections to their favorite services.
\end{tightlist}
%discuss $\frac{c^2}{n^2}$, except how in practice the chance of owning
@@ -295,6 +291,8 @@ complicating factors:
% not? -nm
% Sure. In fact, better off, since they seem to scale more easily. -rd
% the below paragraph should probably move later, and merge with
% other discussions of attack-tor-oak5.
In practice Tor's threat model is based entirely on the goal of
dispersal and diversity. Murdoch and Danezis describe an attack
\cite{attack-tor-oak05} that lets an attacker determine the nodes used
@@ -333,7 +331,7 @@ matter of system design or technology development. In particular, the
Tor project's \emph{image} with respect to its users and the rest of
the Internet impacts the security it can provide.
As an example to motivate this section, some U.S.~Department of Enery
As an example to motivate this section, some U.S.~Department of Energy
penetration testing engineers are tasked with compromising DoE computers
from the outside. They only have a limited number of ISPs from which to
launch their attacks, and they found that the defenders were recognizing
@@ -370,7 +368,7 @@ if the hype attracts more users~\cite{usability-network-effect}.
So it follows that we should come up with ways to accurately communicate
the available security levels to the user, so she can make informed
decisions. Dresden's JAP project aims to do this, by including a
decisions. JAP aims to do this by including a
comforting `anonymity meter' dial in the software's graphical interface,
giving the user an impression of the level of protection for her current
traffic.
@@ -384,22 +382,22 @@ other, there's an arms race between end-to-end statistical attacks and
counter-strategies~\cite{statistical-disclosure,minion-design,e2e-traffic,trickle02}.
But for low-latency systems like Tor, end-to-end \emph{traffic
correlation} attacks~\cite{danezis-pet2004,SS03,defensive-dropping}
allow an attacker who watches or controls both ends of a communication
to use statistics to match packet timing and volume, quickly linking
allow an attacker who can measure both ends of a communication
to match packet timing and volume, quickly linking
the initiator to her destination. This is why Tor's threat model is
based on preventing the adversary from observing both the initiator and
the responder.
Like Tor, the current JAP implementation does not pad connections
(apart from using small fixed-size cells for transport). In fact,
its cascade-based network toplogy may be even more vulnerable to these
attacks, because the network has fewer endpoints. JAP was born out of
its cascade-based network topology may be even more vulnerable to these
attacks, because the network has fewer edges. JAP was born out of
the ISDN mix design~\cite{isdn-mixes}, where padding made sense because
every user had a fixed bandwidth allocation, but in its current context
as a general Internet web anonymizer, adding sufficient padding to JAP
would be prohibitively expensive.\footnote{Even if they could find and
maintain extra funding to run higher-capacity nodes, our experience with
users suggests that many users would not accept the increased per-user
maintain extra funding to run higher-capacity nodes, our experience
suggests that many users would not accept the increased per-user
bandwidth requirements, leading to an overall much smaller user base. But
see Section \ref{subsec:mid-latency}.} Therefore, since under this threat
model the number of concurrent users does not seem to have much impact
@@ -417,28 +415,30 @@ who use the network. We investigate this issue in the next section.
\subsection{Reputability}
Another factor impacting the network's security is its reputability:
the perception of its social value based on its current user base. If I'm
the perception of its social value based on its current user base. If Alice is
the only user who has ever downloaded the software, it might be socially
accepted, but I'm not getting much anonymity. Add a thousand animal rights
activists, and I'm anonymous, but everyone thinks I'm a bambi lover (or
accepted, but she's not getting much anonymity. Add a thousand animal rights
activists, and she's anonymous, but everyone thinks she's a Bambi lover (or
NRA member if you prefer a contrasting example). Add a thousand
random citizens (cancer survivors, privacy enthusiasts, and so on)
and now I'm harder to profile.
and now she's harder to profile.
The more cancer survivors on Tor, the better for the human rights
activists. The more script kiddies, the worse for the normal users. Thus,
reputability is an anonymity issue for two reasons. First, it impacts
the sustainability of the network: a network that's always about to be
shut down has difficulty attracting and keeping users, so its anonymity
set suffers. Second, a disreputable network attracts the attention of
set suffers.
% XXX but we said the anonymity set doesn't matter!
Second, a disreputable network attracts the attention of
powerful attackers who may not mind revealing the identities of all the
users to uncover a few bad ones.
While people therefore have an incentive for the network to be used for
``more reputable'' activities than their own, there are still tradeoffs
involved when it comes to anonymity. To follow the above example, a
network used entirely by cancer survivors might welcome some animal rights
activists onto the network, though of course they'd prefer a wider
network used entirely by cancer survivors might welcome some NRA members
onto the network, though of course they'd prefer a wider
variety of users.
Reputability becomes even more tricky in the case of privacy networks,
@@ -456,19 +456,19 @@ attracts next.
%% to go down the same way again, public perception has not been kind.)
\subsection{Sustainability and incentives}
One of the (arguably) unsolved problems in low-latency anonymity designs is
One of the unsolved problems in low-latency anonymity designs is
how to keep the servers running. Zero-Knowledge Systems's Freedom network
depended on paying third parties to run its servers; the JAP project's
bandwidth is dependent on grants from ???? to pay for its bandwidth and
bandwidth depends on grants to pay for its bandwidth and
administrative expenses. In Tor, bandwidth and administrative costs are
distributed across the volunteers who run Tor nodes, so at least we have
distributed across the volunteers who run Tor nodes, so we at least have
reason to think that the Tor network could survive without continued research
funding.\footnote{It also helps that Tor is implemented with free and open
source software that can be maintained by anybody with the ability and
inclination.} But why are these volunteers running nodes, and what can we
do to encourage more volunteers to do so?
We have not surveyed Tor operators to learn why they are running ORs, but
We have not surveyed Tor operators to learn why they are running servers, but
from the information they have provided, it seems that many of them run Tor
nodes for reasons of personal interest in privacy issues. It is possible
that others are running Tor for anonymity reasons, but of course they are
@@ -479,22 +479,24 @@ a server. In a high-latency mix network, users can receive additional
anonymity by running their own server, since doing so obscures when they are
injecting messages into the network. But in Tor, anybody observing a Tor
server can tell when the server is generating traffic that corresponds to
none of its incoming traffic, and therefore originating traffic itself.
none of its incoming traffic.
Still, anonymity and privacy incentives do remain for server operators:
\begin{tightlist}
\item Against a hostile website, running a Tor exit node can provide a degree
of ``deniaibility'' for traffic that originates at that exit node. For
example, it is likely in practise that HTTP requests from a Tor server's IP
will be assumed to have left the Tor network.
of ``deniability'' for traffic that originates at that exit node. For
example, it is likely in practice that HTTP requests from a Tor server's IP
will be assumed to be from the Tor network.
\item Local Tor entry and exit servers allow users on a network to run in an
`enclave' configuration. [XXXX say more]
`enclave' configuration. [XXXX need to resolve this. They would do this
for E2E encryption + auth?]
\end{tightlist}
First, we try to make the costs of running a Tor server easily minimized.
Since Tor is run by volunteers, the most crucial software usability issue is
usability by operators: when an operator leaves, the network becomes less
usable by everybody. To keep operators pleased, we must try to keep Tor's
resource and administrative demands as low as possible. [XXXX say mroe]
resource and administrative demands as low as possible. [XXXX say more. E.g.,
exit policies.]
Because of ISP billing structures, many Tor operators have underused capacity
that they are willing to donate to the network, at no additional monetary
@@ -508,6 +510,8 @@ section~\ref{subsec:bandwidth-and-usability} below.
[XXXX say more. Why else would you run a server? What else can we do/do we
already do to make running a server more attractive?]
[We can enforce incentives; see Section 6.1. We can rate-limit clients.
We can put "top bandwidth servers lists" up a la seti@home.]
\subsection{Bandwidth and usability}
\label{subsec:bandwidth-and-usability}
@@ -528,12 +532,12 @@ over anonymity tend to leave the system, thus freeing capacity until the
remaining users on the network are exactly those willing to use that capacity
there is.
XXXX hibernation vs rate-limiting: do we want diversity or throughput? i
think we're shifting back to wanting diversity.
XXX what if the file-sharers are more persistent than the journalists?
\subsection{Tor and file-sharing}
One potentially problematical area with deploying Tor has been our response
to file-sharing applications. These applications make up an enormous
%One potentially problematical area with deploying Tor has been our response
%to file-sharing applications.
File-sharing applications make up an enormous
fraction of the traffic on the Internet today, and provide two challenges to
any anonymizing network: their intensive bandwidth requirement, and the
degree to which they are associated (correctly or not) with copyright
@@ -542,8 +546,8 @@ violation.
As noted above, high-bandwidth protocols can make the network unresponsive,
but tend to be somewhat self-correcting. Issues of copyright violation,
however, are more interesting. Typical exit node operators want to help
people achieve privacy and anonymous speech, not to help people (say) host
Vin Diesel movies for illegal download; and typical ISPs would rather not
people achieve private and anonymous speech, not to help people (say) host
Vin Diesel movies for download; and typical ISPs would rather not
deal with customers who incur them the overhead of getting menacing letters
from the MPAA. While it is quite likely that the operators are doing nothing
illegal, many ISPs have policies of dropping users who get repeated legal
@@ -560,8 +564,8 @@ block filesharing would have to find some way to integrate Tor with a
protocol-aware exit filter. This could be a technically expensive
undertaking, and one with poor prospects: it is unlikely that Tor exit nodes
would succeed where so many institutional firewalls have failed. Another
possibility for sensitive operators is to run a very restrictive server that
only permits exit connections to a very restricted range of ports which are
possibility for sensitive operators is to run a restrictive server that
only permits exit connections to a restricted range of ports which are
not frequently associated with file sharing. There are increasingly few such
ports.
@@ -582,12 +586,12 @@ your computer is doing that behavior.
\subsection{Tor and blacklists}
Takedowns and efnet abuse and wikipedia complaints and irc
networks.
It was long expected that, alongside Tor's legitimate users, it would also
attract troublemakers who exploited Tor in order to abuse services on the
Internet. Our initial answer to this situation was to use ``exit policies''
Internet.
[XXX we're not talking bandwidth abuse here, we're talking vandalism,
hate mails via hotmail, attacks, etc.]
Our initial answer to this situation was to use ``exit policies''
to allow individual Tor servers to block access to specific IP/port ranges.
This approach was meant to make operators more willing to run Tor by allowing
them to prevent their servers from being used for abusing particular
@@ -595,7 +599,7 @@ services. For example, all Tor servers currently block SMTP (port 25), in
order to avoid being used to send spam.
This approach is useful, but is insufficient for two reasons. First, since
it is not possible to force all ORs to block access to any given service,
it is not possible to force all servers to block access to any given service,
many of those services try to block Tor instead. More broadly, while being
blockable is important to being good netizens, we would like to encourage
services to allow anonymous access; services should not need to decide
@@ -622,7 +626,8 @@ though this information is readily available. One IP blacklist even bans
every class C network that contains a Tor server, and recommends banning SMTP
from these networks even though Tor does not allow SMTP at all.)
[****Since this is stupid and we oppose it, shouldn't we name names here -pfs]
[XXX also, they're making \emph{middleman nodes leave} because they're caught
up in the standoff!]
Problems of abuse occur mainly with services such as IRC networks and
Wikipedia, which rely on IP blocking to ban abusive users. While at first
@@ -639,30 +644,30 @@ access abuse-prone services. One conceivable approach would be to require
would-be IRC users, for instance, to register accounts if they wanted to
access the IRC network from Tor. But in practise, this would not
significantly impede abuse if creating new accounts were easily automatable;
% XXX captcha
[ XXX yahoo uses captchas in exactly this situation]
this is why services use IP blocking. In order to deter abuse, pseudonymous
identities need to impose a significant switching cost in resources or human
identities need to require a significant switching cost in resources or human
time.
One approach, similar to that taken by Freedom, would be to bootstrap some
non-anonymous costly identification mechanism to allow access to a
blind-signature pseudonym protocol. This would effectively create costly
pseudonyms, which services could require in order to allow anonymous access.
This approach has difficulties in practise, however:
\begin{tightlist}
\item Unlike Freedom, Tor is not a commercial service. Therefore, it would
be a shame to require payment in order to make Tor useful, or to make
non-paying users second-class citizens.
\item It is hard to think of an underlying resource that would actually work.
We could use IP addresses, but that's the problem, isn't it?
\item Managing single sign-on services is not considered a well-solved
problem in practice. If Microsoft can't get universal acceptance for
Passport, why do we think that a Tor-specific solution would do any good?
\item Even if we came up with a perfect authentication system for our needs,
there's no guarantee that any service would actually start using it. It
would require a nonzero effort for them to support it, and it might just
be less hassle for them to block tor anyway.
\end{tightlist}
%One approach, similar to that taken by Freedom, would be to bootstrap some
%non-anonymous costly identification mechanism to allow access to a
%blind-signature pseudonym protocol. This would effectively create costly
%pseudonyms, which services could require in order to allow anonymous access.
%This approach has difficulties in practise, however:
%\begin{tightlist}
%\item Unlike Freedom, Tor is not a commercial service. Therefore, it would
% be a shame to require payment in order to make Tor useful, or to make
% non-paying users second-class citizens.
%\item It is hard to think of an underlying resource that would actually work.
% We could use IP addresses, but that's the problem, isn't it?
%\item Managing single sign-on services is not considered a well-solved
% problem in practice. If Microsoft can't get universal acceptance for
% Passport, why do we think that a Tor-specific solution would do any good?
%\item Even if we came up with a perfect authentication system for our needs,
% there's no guarantee that any service would actually start using it. It
% would require a nonzero effort for them to support it, and it might just
% be less hassle for them to block tor anyway.
%\end{tightlist}
The use of squishy IP-based ``authentication'' and ``authorization''
has not broken down even to the level that SSNs used for these
@@ -678,7 +683,7 @@ workable alternative.
%by implementing the Morphmix-specific node discovery and path selection
%pieces.
\section{Crossroads: Scaling and Design choices}
\section{Crossroads: Design choices}
\label{sec:crossroads-design}
\subsection{Transporting the stream vs transporting the packets}
@@ -725,11 +730,11 @@ potential abuse issues are resolved by the fact that Tor only transports
valid TCP streams (as opposed to arbitrary IP including malformed packets
and IP floods), so exit policies become even \emph{more} important as
we become able to transport IP packets. We also need a way to compactly
characterize the exit policies and let clients parse them to decide
characterize the exit policies and let clients parse them to predict
which nodes will allow which packets to exit.
\item \emph{The Tor-internal name spaces would need to be redesigned.} We
support hidden service {\tt{.onion}} addresses, and other special addresses
like {\tt{.exit}} (see Section~\ref{subsec:hidden-services}),
like {\tt{.exit}} for the user to request a particular exit server,
by intercepting the addresses when they are passed to the Tor client.
\end{enumerate}