mirror of
https://gitlab.torproject.org/tpo/core/tor.git
synced 2024-11-28 06:13:31 +01:00
sharpen section 1
try to help the rest some more too svn:r3436
This commit is contained in:
parent
1f5172d697
commit
729d4f55ef
@ -30,11 +30,22 @@ foo
|
||||
\section{Introduction}
|
||||
|
||||
Tor is a low-latency anonymous communication overlay network designed
|
||||
to be practical and usable for securing TCP streams over the Internet
|
||||
\cite{tor-design}. We have been operating a publicly deployed Tor network
|
||||
since October 2003 that has grown to over a hundred nodes and carries
|
||||
over 70 megabits per second of average traffic.
|
||||
to be practical and usable for protecting TCP streams over the
|
||||
Internet~\cite{tor-design}. We have been operating a publicly deployed
|
||||
Tor network since October 2003 that has grown to over a hundred volunteer
|
||||
nodes and carries over 70 megabits per second of average traffic.
|
||||
|
||||
Tor has a weaker threat model than many anonymity designs in the
|
||||
literature, because we aim primarily to provide a
|
||||
practical and useful network. Given that fixed assumption, we then
|
||||
provide as much anonymity as we can. In particular, because we
|
||||
want to support interactive communications, we fall prey to a variety
|
||||
of intra-network~\cite{danezis-oakland,flow-correlation04,bar} and
|
||||
end-to-end~\cite{danezis-pet2004,SS03} anonymity breaking attacks.
|
||||
|
||||
Tor's defense lies in having a diverse enough network that its adversaries
|
||||
are unlikely to be in the right places to attack both ends of a user's
|
||||
stream. Specifically,
|
||||
Tor aims to resist observers and insiders by distributing each transaction
|
||||
over several nodes in the network. This ``distributed trust'' approach
|
||||
means the Tor network can be safely operated and used by a wide variety
|
||||
@ -58,29 +69,24 @@ their popular Java Anon Proxy anonymizing client. This wide variety of
|
||||
interests helps maintain both the stability and the security of the
|
||||
network.
|
||||
|
||||
Tor has a weaker threat model than many anonymity designs in the
|
||||
literature, because our primary requirements are to have a
|
||||
practical and useful network. Given that fixed assumption, we then aim
|
||||
to provide as much anonymity as we can.
|
||||
|
||||
%need to discuss how we take the approach of building the thing, and then
|
||||
%assuming that, how much anonymity can we get. we're not here to model or
|
||||
%to simulate or to produce equations and formulae. but those have their
|
||||
%roles too.
|
||||
|
||||
This paper aims to give the reader enough information to understand the
|
||||
technical and policy issues that Tor faces as we continue deployment,
|
||||
and to lay a research agenda for others to help in addressing some of
|
||||
these issues. Section \ref{sec:what-is-tor} gives an overview of the Tor
|
||||
design and ours goals. We go on in Section \ref{sec:related} to describe
|
||||
Tor's context in the anonymity space. Sections \ref{sec:crossroads-policy}
|
||||
and \ref{sec:crossroads-technical} describe the practical challenges,
|
||||
While~\cite{tor-design} gives an overall view of the Tor design and goals,
|
||||
this paper describes the policy and technical issues that Tor faces are
|
||||
we continue deployment. We aim to lay 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. We go on in Section~\ref{sec:related} to describe
|
||||
Tor's context in the anonymity space. Sections~\ref{sec:crossroads-policy}
|
||||
and~\ref{sec:crossroads-technical} 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}
|
||||
\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~\cite{tor-design}.
|
||||
|
||||
\subsection{Distributed trust: safety in numbers}
|
||||
|
||||
Tor provides \emph{forward privacy}, so that users can connect to
|
||||
@ -88,30 +94,47 @@ 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.
|
||||
Our design provides this protection even when a portion of its own
|
||||
The design provides this protection even when a portion of its own
|
||||
infrastructure is controlled by an adversary.
|
||||
|
||||
To make private connections in Tor, users incrementally build a path or
|
||||
\emph{circuit} of encrypted connections through servers on the network,
|
||||
extending it one step at a time so that each server in the circuit only
|
||||
learns which server extended to it and which server it has been asked
|
||||
to extend to. The client negotiates a separate set of encryption keys
|
||||
for each step along the circuit.
|
||||
To create a private network pathway with Tor, the user's software (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
|
||||
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, the client software waits for
|
||||
applications to request TCP connections, and directs these application
|
||||
streams along the circuit. Many streams can be multiplexed along a single
|
||||
circuit, so applications don't need to wait for keys to be negotiated
|
||||
every time they open a connection. Because each server sees no
|
||||
more than one end of the connection, a local eavesdropper or a compromised
|
||||
server cannot use traffic analysis to link the connection's source and
|
||||
destination. The Tor client software rotates circuits periodically
|
||||
to prevent long-term linkability between different actions by a
|
||||
single user.
|
||||
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
|
||||
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.
|
||||
|
||||
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
|
||||
circuit, to prevent long-term linkability between different actions by
|
||||
a single user.
|
||||
|
||||
Tor also makes it possible for users to hide their locations while
|
||||
offering various kinds of services, such as web publishing or an instant
|
||||
messaging server. Using Tor ``rendezvous points'', other Tor users can
|
||||
connect to these hidden services, each without knowing the other's network
|
||||
identity.
|
||||
%This hidden service functionality could allow Tor users to
|
||||
%set up a website where people publish material without worrying about
|
||||
%censorship. Nobody would be able to determine who was offering the site,
|
||||
%and nobody who offered the site would know who was posting to it.
|
||||
|
||||
tor works for tcp on socks (see section \ref{subsec:tcp-vs-ip}). it
|
||||
only anonymizes the channel, so you need application-level scrubbers
|
||||
like privoxy.
|
||||
|
||||
Tor differs from other deployed systems for traffic analysis resistance
|
||||
in its security and flexibility. Mix networks such as Mixmaster or its
|
||||
successor Mixminion \cite{minion-design}
|
||||
in its security and flexibility. Mix networks such as
|
||||
Mixmaster~\cite{mixmaster} 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 proxies
|
||||
@ -120,10 +143,7 @@ a single compromise can expose all users' traffic, and a single-point
|
||||
eavesdropper can perform traffic analysis on the entire network.
|
||||
Also, their proprietary implementations place any infrastucture that
|
||||
depends on these single-hop solutions at the mercy of their providers'
|
||||
financial health. Tor can handle any TCP-based protocol, such as web
|
||||
browsing, instant messaging and chat, and secure shell login; and it is
|
||||
the only implemented anonymizing design with an integrated system for
|
||||
secure location-hidden services.
|
||||
financial health as well as network security.
|
||||
|
||||
No organization can achieve this security on its own. If a single
|
||||
corporation or government agency were to build a private network to
|
||||
@ -148,9 +168,8 @@ HTTP or chat, and it requires no modification of those services to do so.
|
||||
|
||||
weasel's graph of \# nodes and of bandwidth, ideally from week 0.
|
||||
|
||||
Tor has the following goals.
|
||||
|
||||
and we made these assumptions when trying to design the thing.
|
||||
Tor doesn't try to provide steg (but see Sec \ref{china}), or
|
||||
the other non-goals listed in tor-design.
|
||||
|
||||
\section{Tor's position in the anonymity field}
|
||||
\label{sec:related}
|
||||
@ -242,6 +261,9 @@ snipe them?
|
||||
because only at the exit is it evident what port or protocol a given
|
||||
tor stream is, you can't choose not to carry file-sharing traffic.
|
||||
|
||||
hibernation vs rate-limiting: do we want diversity or throughput? i
|
||||
think we're shifting back to wanting diversity.
|
||||
|
||||
\subsection{Tor and blacklists}
|
||||
|
||||
Takedowns and efnet abuse and wikipedia complaints and irc
|
||||
@ -676,6 +698,11 @@ and we maybe we should start with a time-release IP publishing system +
|
||||
advogato based reputation system, to bound the number of IPs leaked to the
|
||||
adversary.
|
||||
|
||||
\cite{infranet}
|
||||
\cite{koepsell-wpes2004}
|
||||
\cite{advogato}
|
||||
\cite{berkman}
|
||||
|
||||
\section{The Future}
|
||||
\label{sec:conclusion}
|
||||
|
||||
|
@ -1096,6 +1096,16 @@
|
||||
note = {\url{http://tor.eff.org/tor-design.pdf}}
|
||||
}
|
||||
|
||||
@inproceedings{flow-correlation04,
|
||||
title = {On Flow Correlation Attacks and Countermeasures in Mix Networks},
|
||||
author = {Ye Zhu and Xinwen Fu and Bryan Graham and Riccardo Bettati and Wei Zhao},
|
||||
booktitle = {Proceedings of Privacy Enhancing Technologies workshop (PET 2004)},
|
||||
year = {2004},
|
||||
month = {May},
|
||||
series = {LNCS},
|
||||
note = {\url{http://students.cs.tamu.edu/xinwenfu/paper/PET04.pdf}},
|
||||
}
|
||||
|
||||
%%% Local Variables:
|
||||
%%% mode: latex
|
||||
%%% TeX-master: "tor-design"
|
||||
|
Loading…
Reference in New Issue
Block a user