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

add the dirservers section

Browse Source 
svn:r662
This commit is contained in:
Roger Dingledine
2003-10-23 11:45:51 +00:00
parent c0a47ce885
commit 1e5963e95a
2 changed files with 144 additions and 44 deletions
Download Patch File Download Diff File Expand all files Collapse all files
trunk/doc/tor-design.bib
+24 -5
View File
@@ -10,6 +10,14 @@
note = {\url{http://www.authnet.org/anonnet/}}
}
% can somebody track down the rest of this? -RD
@Misc{castro-liskov,
author = {Miguel Castro and Barbara Liskov},
title = {Proactive Recovery in a Byzantine-Fault-Tolerant System},
howpublished = {
$<$http://www.pmg.lcs.mit.edu/$\tilde{\hspace{5pt}}$castro/application/recovery.pdf$>$},
}
@inproceedings{econymics,
title = {On the Economics of Anonymity},
author = {Alessandro Acquisti and Roger Dingledine and Paul Syverson},
@@ -63,10 +71,11 @@ full_papers/rao/rao.pdf}},
note = {\url{http://citeseer.nj.nec.com/pfitzmann90how.html}},
}
@Misc{mixminion-spec,
author = {Mixminion},
title = {Type {III} ({M}ixminion) Mix Protocol Specifications},
note = {\newline \url{http://mixminion.net/minion-spec.txt}},
% author = {Roger Dingledine and Nick Mathewson},
@Misc{tor-spec,
author = {Anonymized},
title = {Tor Protocol Specifications},
note = {\url{http://freehaven.net/tor/tor-spec.txt}},
}
@InProceedings{BM:mixencrypt,
@@ -723,6 +732,16 @@ full_papers/rao/rao.pdf}},
note = {\newline \url{http://www.freedom.net/products/whitepapers/white11.html}},
}
@techreport{freedom2-arch,
title = {Freedom Systems 2.0 Architecture},
author = {Philippe Boucher and Adam Shostack and Ian Goldberg},
institution = {Zero Knowledge Systems, {Inc.}},
year = {2000},
month = {December},
type = {White Paper},
day = {18},
}
@techreport{freedom21-security,
title = {Freedom Systems 2.1 Security Issues and Analysis},
author = {Adam Back and Ian Goldberg and Adam Shostack},
@@ -918,7 +937,7 @@ full_papers/rao/rao.pdf}},
title = {Defending Anonymous Communication Against Passive Logging Attacks},
author = {Matthew Wright and Micah Adler and Brian Neil Levine and Clay Shields},
booktitle = {2003 IEEE Symposium on Security and Privacy},
pages= {28--41}
pages= {28--41},
year = {2003},
month = {May},
publisher = {IEEE CS},
trunk/doc/tor-design.tex
+120 -39
View File
@@ -41,7 +41,6 @@
\title{Tor: Design of a Next-Generation Onion Router}
%\author{Anonymous}
%\author{Roger Dingledine \\ The Free Haven Project \\ arma@freehaven.net \and
%Nick Mathewson \\ The Free Haven Project \\ nickm@freehaven.net \and
%Paul Syverson \\ Naval Research Lab \\ syverson@itd.nrl.navy.mil}
@@ -78,6 +77,7 @@ at each node, revealing the downstream node. The original onion routing
project published several design and analysis papers
\cite{or-jsac98,or-discex00,or-ih96,or-pet00}. While there was briefly
a wide area onion routing network,
% how long is briefly? a day, a month? -RD
the only long-running and publicly accessible
implementation was a fragile proof-of-concept that ran on a single
machine. Many critical design and deployment issues were never implemented,
@@ -99,9 +99,9 @@ the initiator knows which hop failed and can try extending to a new node.
\item \textbf{Applications talk to the onion proxy via Socks:}
The original onion routing design required a separate proxy for each
supported application protocol, resulting in a lot of extra code (most
of which was never written) and also meaning that a lot of TCP-based
applications were not supported. Tor uses the unified and standard Socks
supported application protocol, resulting in a lot of extra code --- most
of which was never written, so most applications were not supported.
Tor uses the unified and standard Socks
\cite{socks4,socks5} interface, allowing us to support any TCP-based
program without modification.
@@ -162,32 +162,33 @@ onion routers also serve as directory servers; they provide signed
are currently up. Users periodically download these directories via HTTP.
\item \textbf{End-to-end integrity checking:} Without integrity checking
on traffic going through the network, an onion router can change the
contents of cells as they pass by, e.g. by redirecting a connection on
the fly so it connects to a different webserver, or by tagging encrypted
traffic and looking for traffic at the network edges that has been
tagged \cite{minion-design}.
on traffic going through the network, any onion router on the path
can change the contents of cells as they pass by, e.g. to redirect a
connection on the fly so it connects to a different webserver, or to
tag encrypted traffic and look for the tagged traffic at the network
edges \cite{minion-design}.
\item \textbf{Robustness to node failure:} Node failure for a
low-latency system like Tor is not as serious a problem as it is for
a traditional mix network. Nonetheless, simple mechanisms that allow
connections to be established despite slightly dated information
from a directory server or very recent node failure are useful. Tor
permits onion routers to have router twins. These share the same
private decryption key that is used when establishing a connection
through the onion router. Note that because of how connections are
now established with perfect forward secrecy, this does not
automatically mean that an onion router can read the traffic on a
connection established through its twin even while that connection
is active. Also, which nodes are twins can change dynamically
depending on current circumstances, and twins may or may not be
under the same administrative authority.
\item \textbf{Robustness to failed nodes:} A failed node in a traditional
mix network means lost messages, but in Tor, users can notice failed
nodes while building circuits and route around them. We further provide a
simple mechanism that allows connections to be established despite recent
node failure or slightly dated information from a directory server. Tor
permits onion routers to have \emph{router twins} --- nodes that share
the same private decryption key. Note that because connections now have
perfect forward secrecy, an onion router still cannot read the traffic
on a connection established through its twin even while that connection
is active. Also, which nodes are twins can change dynamically depending
on current circumstances, and twins may or may not be under the same
administrative authority.
\item \textbf{Exit policies:}
Tor provides a consistent mechanism for each node to specify and
advertise an exit policy.
\item \textbf{Exit policies:} Tor provides a consistent mechanism for
each node to specify and advertise its own exit policy. Exit policies
are critical in a volunteer-based distributed infrastructure, because
each operator is comfortable with allowing different types of traffic
to exit the Tor network from his node.
\item \textbf{Rendezvous points:}
\item \textbf{Rendezvous points and location-protected servers:} Tor
provides an integrated mechanism for responder-anonymity
location-protected servers
\end{tightlist}
@@ -312,7 +313,7 @@ The first of these was the Eternity Service \cite{eternity}. Since
then, there have been many alternatives and refinements, of which we note
but a few
\cite{eternity,gap-pets03,freenet-pets00,freehaven-berk,publius,tangler,taz}.
From the first, traffic analysis resistant communication has been
From the beginning, traffic analysis resistant communication has been
recognized as an important element of censorship resistance because of
the relation between the ability to censor material and the ability to
find its distribution source.
@@ -381,7 +382,7 @@ activities); and designs that are difficult or expensive to implement
or ).
Second, the system must be {\bf usable}. A hard-to-use system has
fewer users---and because anonymity systems hide users among users, a
fewer users --- and because anonymity systems hide users among users, a
system with fewer users provides less anonymity. Thus, usability is
not only a convenience, but is a security requirement for anonymity
systems.
@@ -404,8 +405,8 @@ speculative solutions to problems we don't KNOW how to solve? -NM]
\subsection{Non-goals}
In favoring conservative, deployable designs, we have explicitly
deferred a number of goals---not because they are not desirable in
anonymity systems---but because solving them is either solved
deferred a number of goals --- not because they are not desirable in
anonymity systems --- but because solving them is either solved
elsewhere, or an area of active research without a generally accepted
solution.
@@ -416,16 +417,18 @@ servers.
Tor does not claim to provide a definitive solution to end-to-end
timing or intersection attacks for users who do not run their own
Onion Routers.
% Does that mean we do claim to solve intersection attack for
% the enclave-firewall model? -RD
Tor does not provide ``protocol normalization'' like the Anonymizer,
Privoxy, or XXX. In order to provide client indistinguishibility for
Tor does not provide \emph{protocol normalization} like the Anonymizer or
Privoxy. In order to provide client indistinguishibility for
complex and variable protocols such as HTTP, Tor must be layered with
a proxy such as Privoxy or XXX. Similarly, Tor does not currently
a filtering proxy such as Privoxy. Similarly, Tor does not currently
integrate tunneling for non-stream-based protocols; this too must be
provided by an external service.
Tor is not steganographic. It doesn't try to conceal which users are
sending or receiving communications via Tor.
Tor is not steganographic: it doesn't try to conceal which users are
sending or receiving communications.
\SubSection{Adversary Model}
@@ -559,6 +562,7 @@ tagging attacks
\SubSection{Assumptions}
For purposes of this paper, we assume all directory servers are honest
% No longer true, see subsec:dirservers below -RD
and trusted. Perhaps more accurately, we assume that all users and
nodes can perform their own periodic checks on information they have
from directory servers and that all will always have access to at
@@ -568,7 +572,7 @@ techniques to cope with a minority dishonest servers.
Somewhere between ten percent and twenty percent of nodes are assumed
to be compromised. In some circumstances, e.g., if the Tor network is
running on a hardened network where all operators have had careful
running on a hardened network where all operators have had
background checks, the percent of compromised nodes might be much
lower. It may be worthwhile to consider cases where many of the `bad'
nodes are not fully compromised but simply (passive) observing
@@ -579,6 +583,8 @@ above. We assume that all adversary components, regardless of their
capabilities are collaborating and are connected in an offline clique.
We do not assume any hostile users, except in the context of
% This sounds horrible. What do you mean we don't assume any hostile
% users? Surely we can tolerate some? -RD
rendezvous points. Nonetheless, we assume that users vary widely in
both the duration and number of times they are connected to the Tor
network. They can also be assumed to vary widely in the volume and
@@ -600,7 +606,78 @@ shape of the traffic they send and receive.
\label{subsec:exitpolicies}
\SubSection{Directory Servers}
\label{subsec:dir-servers}
\label{subsec:dirservers}
First-generation Onion Routing designs \cite{or-jsac98,freedom2-arch} did
% is or-jsac98 the right cite here? what's our stock OR cite? -RD
in-band network status updates: each router flooded a signed statement
to its neighbors, which propagated it onward. But anonymizing networks
have different security goals than typical link-state routing protocols.
For example, we worry more about delays (accidental or intentional)
which cause different parts of the network to have different pictures
of link-state and topology. We also worry about attacks to deceive a
client about the router membership list, topology, or current network
state. Such \emph{partitioning attacks} on client knowledge help an
adversary with limited resources to efficiently deploy those resources
when attacking a target.
Instead, Tor uses a small group of redundant directory servers to
track network topology and node state such as current keys and exit
policies. The directory servers are normal onion routers, but there are
only a few of them and they are more trusted. They listen on a separate
port as an HTTP server, both so participants can fetch current network
state and router lists (a \emph{directory}), and so other onion routers
can upload a signed summary of their keys, address, bandwidth, exit
policy, etc (\emph{server descriptors}.
Of course, a variety of attacks remain. An adversary who controls a
directory server can track certain clients by providing different
information --- perhaps by listing only nodes under its control
as working, or by informing only certain clients about a given
node. Moreover, an adversary without control of a directory server can
still exploit differences among client knowledge. If Eve knows that
node $M$ is listed on server $D_1$ but not on $D_2$, she can use this
knowledge to link traffic through $M$ to clients who have queried $D_1$.
Thus these directory servers must be synchronized and redundant. The
software is distributed with the signature public key of each directory
server, and directories must be signed by a threshold of these keys.
The directory servers in Tor are modeled after those in Mixminion
\cite{minion-design}, but our situation is easier. Firstly, we make the
simplifying assumption that all participants agree on who the directory
servers are. Secondly, Mixminion needs to predict node behavior ---
that is, build a reputation system for guessing future performance of
nodes based on past performance, and then figure out a way to build
a threshold consensus of these predictions. Tor just needs to get a
threshold consensus of the current state of the network.
The threshold consensus can be reached with standard Byzantine agreement
techniques \cite{castro-liskov}.
% Should I just stop the section here? Is the rest crap? -RD
But this library, while more efficient than previous Byzantine agreement
systems, is still complex and heavyweight for our purposes: we only need
to compute a single algorithm, and we do not require strict in-order
computation steps. The Tor directory servers build a consensus directory
through a simple four-round broadcast protocol. First, each server signs
and broadcasts its current opinion to the other directory servers; each
server then rebroadcasts all the signed opinions it has received. At this
point all directory servers check to see if anybody's cheating. If so,
directory service stops, the humans are notified, and that directory
server is permanently removed from the network. Assuming no cheating,
each directory server then computes a local algorithm on the set of
opinions, resulting in a uniform shared directory. Then the servers sign
this directory and broadcast it; and finally all servers rebroadcast
the directory and all the signatures.
The rebroadcast steps ensure that a directory server is heard by either
all of the other servers or none of them (some of the links between
directory servers may be down). Broadcasts are feasible because there
are so few directory servers (currently 3, but we expect to use as many
as 9 as the network scales). The actual local algorithm for computing
the shared directory is straightforward, and is described in the Tor
specification \cite{tor-spec}.
% we should, uh, add this to the spec. oh, and write it. -RD
\Section{Rendezvous points: location privacy}
\label{sec:rendezvous}
@@ -666,6 +743,10 @@ and the first half of a DH key exchange. When Bob connects to the meeting
place and gets connected to Alice's pipe, his first cell contains the
other half of the DH key exchange.
% briefly talk about our notion of giving cookies to people proportional
% to how important they are, for location-protected servers hardened
% against DDoS threat? -RD
\subsection{Integration with user applications}
For each service Bob offers, he configures his local onion proxy to know
@@ -841,7 +922,7 @@ link-level cover traffic and also long-range cover traffic. In particular,
we expect restricted route topologies to reduce the cost of cover traffic
because there are fewer links to cover.
\item \emph{Better directory distribution:} Even with the threshold
directory agreement algorithm described in \ref{sec:dirservers},
directory agreement algorithm described in \ref{subsec:dirservers},
the directory servers are still trust bottlenecks. We must find more
decentralized yet practical ways to distribute up-to-date snapshots of
network status without introducing new attacks.