[or-cvs] r13290: down to 24 pages (tor/trunk/doc/design-paper)
arma at seul.org
arma at seul.org
Sat Jan 26 02:48:44 UTC 2008
Author: arma
Date: 2008-01-25 21:48:43 -0500 (Fri, 25 Jan 2008)
New Revision: 13290
Modified:
tor/trunk/doc/design-paper/blocking.pdf
tor/trunk/doc/design-paper/blocking.tex
Log:
down to 24 pages
Modified: tor/trunk/doc/design-paper/blocking.pdf
===================================================================
(Binary files differ)
Modified: tor/trunk/doc/design-paper/blocking.tex
===================================================================
--- tor/trunk/doc/design-paper/blocking.tex 2008-01-26 01:06:57 UTC (rev 13289)
+++ tor/trunk/doc/design-paper/blocking.tex 2008-01-26 02:48:43 UTC (rev 13290)
@@ -25,7 +25,7 @@
%\newcommand{\workingnote}[1]{(**#1)} % makes the note visible.
\date{}
-\title{Design of a blocking-resistant anonymity system\\DRAFT}
+\title{Design of a blocking-resistant anonymity system}
%\author{Roger Dingledine\inst{1} \and Nick Mathewson\inst{1}}
\author{Roger Dingledine \\ The Tor Project \\ arma at torproject.org \and
@@ -50,12 +50,12 @@
\end{abstract}
-\section{Introduction and Goals}
+\section{Introduction}
Anonymizing networks like Tor~\cite{tor-design} bounce traffic around a
network of encrypting relays. Unlike encryption, which hides only {\it what}
is said, these networks also aim to hide who is communicating with whom, which
-users are using which websites, and similar relations. These systems have a
+users are using which websites, and so on. These systems have a
broad range of users, including ordinary citizens who want to avoid being
profiled for targeted advertisements, corporations who don't want to reveal
information to their competitors, and law enforcement and government
@@ -78,14 +78,14 @@
and Blogspot, they are no longer affected by local censorship
and firewall rules. In fact, an informal user study
%(described in Appendix~\ref{app:geoip})
-showed China as the third largest user base
-for Tor clients, with perhaps ten thousand people accessing the Tor
-network from China each day.
+showed that a few hundred thousand users people access the Tor network
+each day, with about 20\% of them coming from China~\cite{something}.
The current Tor design is easy to block if the attacker controls Alice's
connection to the Tor network---by blocking the directory authorities,
-by blocking all the server IP addresses in the directory, or by filtering
-based on the fingerprint of the Tor TLS handshake. Here we describe an
+by blocking all the relay IP addresses in the directory, or by filtering
+based on the network fingerprint of the Tor TLS handshake. Here we
+describe an
extended design that builds upon the current Tor network to provide an
anonymizing
network that resists censorship as well as anonymity-breaking attacks.
@@ -99,7 +99,7 @@
security implications and Section~\ref{sec:reachability} presents other
issues with maintaining connectivity and sustainability for the design.
%Section~\ref{sec:future} speculates about future more complex designs,
-Finally Section~\ref{sec:conclusion} summarizes our next steps and
+Finally section~\ref{sec:conclusion} summarizes our next steps and
recommendations.
% The other motivation is for places where we're concerned they will
@@ -137,8 +137,8 @@
a variety of adversaries in mind, we can take advantage of the fact that
adversaries will be in different stages of the arms race at each location,
so an address blocked in one locale can still be useful in others.
+We focus on an attacker with somewhat complex goals:
-We assume that the attackers' goals are somewhat complex.
\begin{tightlist}
\item The attacker would like to restrict the flow of certain kinds of
information, particularly when this information is seen as embarrassing to
@@ -222,7 +222,7 @@
We do not assume that government-level attackers are always uniform
across the country. For example, users of different ISPs in China
-experience different censorship policies and mechanisms.
+experience different censorship policies and mechanisms~\cite{china-ccs07}.
%there is no single centralized place in China
%that coordinates its specific censorship decisions and steps.
@@ -253,11 +253,11 @@
Tor is popular and sees a lot of use---it's the largest anonymity
network of its kind, and has
-attracted more than 800 volunteer-operated routers from around the
+attracted more than 1500 volunteer-operated routers from around the
world. Tor protects each user by routing their traffic through a multiply
-encrypted ``circuit'' built of a few randomly selected servers, each of which
-can remove only a single layer of encryption. Each server sees only the step
-before it and the step after it in the circuit, and so no single server can
+encrypted ``circuit'' built of a few randomly selected relay, each of which
+can remove only a single layer of encryption. Each relay sees only the step
+before it and the step after it in the circuit, and so no single relay can
learn the connection between a user and her chosen communication partners.
In this section, we examine some of the reasons why Tor has become popular,
with particular emphasis to how we can take advantage of these properties
@@ -290,7 +290,7 @@
present in manual or ad hoc circumvention techniques.
First, Tor has a well-analyzed and well-understood way to distribute
-information about servers.
+information about relay.
Tor directory authorities automatically aggregate, test,
and publish signed summaries of the available Tor routers. Tor clients
can fetch these summaries to learn which routers are available and
@@ -365,11 +365,11 @@
addresses that we can leverage for our blocking-resistance design.
Finally and perhaps most importantly, Tor provides anonymity and prevents any
-single server from linking users to their communication partners. Despite
+single relay from linking users to their communication partners. Despite
initial appearances, {\it distributed-trust anonymity is critical for
-anti-censorship efforts}. If any single server can expose dissident bloggers
+anti-censorship efforts}. If any single relay can expose dissident bloggers
or compile a list of users' behavior, the censors can profitably compromise
-that server's operator, perhaps by applying economic pressure to their
+that relay's operator, perhaps by applying economic pressure to their
employers,
breaking into their computer, pressuring their family (if they have relatives
in the censored area), or so on. Furthermore, in designs where any relay can
@@ -394,7 +394,8 @@
For example, we can divide the pieces of Tor in the previous section
into the process of building paths and sending
traffic over them (relay) and the process of learning from the directory
-servers about what routers are available (discovery). With this distinction
+authorities about what routers are available (discovery). With this
+distinction
in mind, we now examine several categories of relay-based schemes.
\subsection{Centrally-controlled shared proxies}
@@ -579,33 +580,34 @@
reconstruction~\cite{ptacek98insertion}. This technique relies on the
same insight as our weak steganography assumption.
-\subsection{Internal caching networks}
+%\subsection{Internal caching networks}
-Freenet~\cite{freenet-pets00} is an anonymous peer-to-peer data store.
-Analyzing Freenet's security can be difficult, as its design is in flux as
-new discovery and routing mechanisms are proposed, and no complete
-specification has (to our knowledge) been written. Freenet servers relay
-requests for specific content (indexed by a digest of the content)
-``toward'' the server that hosts it, and then cache the content as it
-follows the same path back to
-the requesting user. If Freenet's routing mechanism is successful in
-allowing nodes to learn about each other and route correctly even as some
-node-to-node links are blocked by firewalls, then users inside censored areas
-can ask a local Freenet server for a piece of content, and get an answer
-without having to connect out of the country at all. Of course, operators of
-servers inside the censored area can still be targeted, and the addresses of
-external servers can still be blocked.
+%Freenet~\cite{freenet-pets00} is an anonymous peer-to-peer data store.
+%Analyzing Freenet's security can be difficult, as its design is in flux as
+%new discovery and routing mechanisms are proposed, and no complete
+%specification has (to our knowledge) been written. Freenet servers relay
+%requests for specific content (indexed by a digest of the content)
+%``toward'' the server that hosts it, and then cache the content as it
+%follows the same path back to
+%the requesting user. If Freenet's routing mechanism is successful in
+%allowing nodes to learn about each other and route correctly even as some
+%node-to-node links are blocked by firewalls, then users inside censored areas
+%can ask a local Freenet server for a piece of content, and get an answer
+%without having to connect out of the country at all. Of course, operators of
+%servers inside the censored area can still be targeted, and the addresses of
+%external servers can still be blocked.
-\subsection{Skype}
+%\subsection{Skype}
-The popular Skype voice-over-IP software uses multiple techniques to tolerate
-restrictive networks, some of which allow it to continue operating in the
-presence of censorship. By switching ports and using encryption, Skype
-attempts to resist trivial blocking and content filtering. Even if no
-encryption were used, it would still be expensive to scan all voice
-traffic for sensitive words. Also, most current keyloggers are unable to
-store voice traffic. Nevertheless, Skype can still be blocked, especially at
-its central login server.
+%The popular Skype voice-over-IP software uses multiple techniques to tolerate
+%restrictive networks, some of which allow it to continue operating in the
+%presence of censorship. By switching ports and using encryption, Skype
+%attempts to resist trivial blocking and content filtering. Even if no
+%encryption were used, it would still be expensive to scan all voice
+%traffic for sensitive words. Also, most current keyloggers are unable to
+%store voice traffic. Nevertheless, Skype can still be blocked, especially at
+%its central login server.
+
%*sjmurdoch* "we consider the login server to be the only central component in
%the Skype p2p network."
%*sjmurdoch* http://www1.cs.columbia.edu/~salman/publications/skype1_4.pdf
@@ -661,7 +663,7 @@
\subsection{Bridge relays}
-Today, Tor servers operate on less than a thousand distinct IP addresses;
+Today, Tor relays operate on a few thousand distinct IP addresses;
an adversary
could enumerate and block them all with little trouble. To provide a
means of ingress to the network, we need a larger set of entry points, most
@@ -695,7 +697,7 @@
How do the bridge relays advertise their existence to the world? We
introduce a second new component of the design: a specialized directory
authority that aggregates and tracks bridges. Bridge relays periodically
-publish server descriptors (summaries of their keys, locations, etc,
+publish relay descriptors (summaries of their keys, locations, etc,
signed by their long-term identity key), just like the relays in the
``main'' Tor network, but in this case they publish them only to the
bridge directory authorities.
@@ -703,7 +705,7 @@
The main difference between bridge authorities and the directory
authorities for the main Tor network is that the main authorities provide
a list of every known relay, but the bridge authorities only give
-out a server descriptor if you already know its identity key. That is,
+out a relay descriptor if you already know its identity key. That is,
you can keep up-to-date on a bridge's location and other information
once you know about it, but you can't just grab a list of all the bridges.
@@ -733,7 +735,7 @@
%Secondly, while users can in fact configure which directory authorities
%they use, we need to add a new type of directory authority and teach
%bridges to fetch directory information from the main authorities while
-%publishing server descriptors to the bridge authorities. We're most of
+%publishing relay descriptors to the bridge authorities. We're most of
%the way there, since we can already specify attributes for directory
%authorities:
%add a separate flag named ``blocking''.
@@ -756,7 +758,7 @@
he has correct address information for at least one of them, he can use
that one to make a secure connection to the bridge authority and update
his knowledge about the other bridge relays. He can also use it to make
-secure connections to the main Tor network and directory servers, so he
+secure connections to the main Tor network and directory authorities, so he
can build circuits and connect to the rest of the Internet. All of these
updates happen in the background: from the blocked user's perspective,
he just accesses the Internet via his Tor client like always.
@@ -786,15 +788,15 @@
Currently, Tor uses two protocols for its network communications. The
main protocol uses TLS for encrypted and authenticated communication
between Tor instances. The second protocol is standard HTTP, used for
-fetching directory information. All Tor servers listen on their ``ORPort''
+fetching directory information. All Tor relays listen on their ``ORPort''
for TLS connections, and some of them opt to listen on their ``DirPort''
-as well, to serve directory information. Tor servers choose whatever port
-numbers they like; the server descriptor they publish to the directory
+as well, to serve directory information. Tor relays choose whatever port
+numbers they like; the relay descriptor they publish to the directory
tells users where to connect.
One format for communicating address information about a bridge relay is
its IP address and DirPort. From there, the user can ask the bridge's
-directory cache for an up-to-date copy of its server descriptor, and
+directory cache for an up-to-date copy of its relay descriptor, and
learn its current circuit keys, its ORPort, and so on.
However, connecting directly to the directory cache involves a plaintext
@@ -824,7 +826,7 @@
Furthermore, we need to look at the specifics of Tor's TLS handshake.
Right now Tor uses some predictable strings in its TLS handshakes. For
example, it sets the X.509 organizationName field to ``Tor'', and it puts
-the Tor server's nickname in the certificate's commonName field. We
+the Tor relay's nickname in the certificate's commonName field. We
should tweak the handshake protocol so it doesn't rely on any unusual details
in the certificate, yet it remains secure; the certificate itself
should be made to resemble an ordinary HTTPS certificate. We should also try
@@ -841,7 +843,7 @@
bridges should consider using only a single TLS key certificate signed by
their identity key, and providing the full value of the identity key in an
early handshake cell. More significantly, Tor currently has all clients
-present certificates, so that clients are harder to distinguish from servers.
+present certificates, so that clients are harder to distinguish from relays.
But in a blocking-resistance environment, clients should not present
certificates at all.
@@ -892,10 +894,10 @@
traffic.
% cue paper by steven and george
-Once the Tor client has fetched the bridge's server descriptor, it should
+Once the Tor client has fetched the bridge's relay descriptor, it should
remember the identity key fingerprint for that bridge relay. Thus if
the bridge relay moves to a new IP address, the client can query the
-bridge directory authority to look up a fresh server descriptor using
+bridge directory authority to look up a fresh relay descriptor using
this fingerprint.
So we've shown that it's \emph{possible} to bootstrap into the network
@@ -1143,7 +1145,7 @@
their identity key. The better answer would be some federation of bridge
authorities that work together to provide redundancy but don't introduce
new security issues. We could even imagine designs where the bridge
-authorities have encrypted versions of the bridge's server descriptors,
+authorities have encrypted versions of the bridge's relay descriptors,
and the users learn a decryption key that they keep private when they
first hear about the bridge---this way the bridge authorities would not
be able to learn the IP address of the bridges.
@@ -1163,7 +1165,7 @@
the time is it available? Third, is it blocked in certain jurisdictions?
The first component can be tested just as we test reachability of
-ordinary Tor servers. Specifically, the bridges do a self-test---connect
+ordinary Tor relays. Specifically, the bridges do a self-test---connect
to themselves via the Tor network---before they are willing to
publish their descriptor, to make sure they're not obviously broken or
misconfigured. Once the bridges publish, the bridge authority also tests
@@ -1377,7 +1379,7 @@
Against some attacks, relaying traffic for others can improve
anonymity. The simplest example is an attacker who owns a small number
-of Tor servers. He will see a connection from the bridge, but he won't
+of Tor relays. He will see a connection from the bridge, but he won't
be able to know whether the connection originated there or was relayed
from somebody else. More generally, the mere uncertainty of whether the
traffic originated from that user may be helpful.
@@ -1406,9 +1408,9 @@
We also need to examine how entry guards fit in. Entry guards
(a small set of nodes that are always used for the first
step in a circuit) help protect against certain attacks
-where the attacker runs a few Tor servers and waits for
-the user to choose these servers as the beginning and end of her
-circuit\footnote{\url{http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ\#EntryGuards}}.
+where the attacker runs a few Tor relays and waits for
+the user to choose these relays as the beginning and end of her
+circuit\footnote{\url{http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#EntryGuards}}.
If the blocked user doesn't use the bridge's entry guards, then the bridge
doesn't gain as much cover benefit. On the other hand, what design changes
are needed for the blocked user to use the bridge's entry guards without
@@ -1450,17 +1452,17 @@
\label{subsec:trust-chain}
Tor's ``public key infrastructure'' provides a chain of trust to
-let users verify that they're actually talking to the right servers.
+let users verify that they're actually talking to the right relays.
There are four pieces to this trust chain.
First, when Tor clients are establishing circuits, at each step
-they demand that the next Tor server in the path prove knowledge of
+they demand that the next Tor relay in the path prove knowledge of
its private key~\cite{tor-design}. This step prevents the first node
in the path from just spoofing the rest of the path. Second, the
-Tor directory authorities provide a signed list of servers along with
+Tor directory authorities provide a signed list of relays along with
their public keys---so unless the adversary can control a threshold
of directory authorities, he can't trick the Tor client into using other
-Tor servers. Third, the location and keys of the directory authorities,
+Tor relays. Third, the location and keys of the directory authorities,
in turn, is hard-coded in the Tor source code---so as long as the user
got a genuine version of Tor, he can know that he is using the genuine
Tor network. And last, the source code and other packages are signed
@@ -1491,7 +1493,7 @@
%\section{Performance improvements}
%\label{sec:performance}
%
-%\subsection{Fetch server descriptors just-in-time}
+%\subsection{Fetch relay descriptors just-in-time}
%
%I guess we should encourage most places to do this, so blocked
%users don't stand out.
@@ -1635,9 +1637,9 @@
%(Minor
%anonymity implications, but hey.) (In many cases there won't be much
%activity, so this may backfire. Or it may be better suited to full-fledged
-%Tor servers.)
+%Tor relay.)
-% Also consider everybody-a-server. Many of the scalability questions
+% Also consider everybody-a-relay. Many of the scalability questions
% are easier when you're talking about making everybody a bridge.
%\subsection{What if the clients can't install software?}
@@ -1702,7 +1704,7 @@
copy.
See Section~\ref{subsec:first-bridge} for more discussion.
-% Ian suggests that we have every tor server distribute a signed copy of the
+% Ian suggests that we have every tor relay distribute a signed copy of the
% software.
\section{Next Steps}
@@ -1824,7 +1826,7 @@
9. Bridge directories must not simply be a handful of nodes that
provide the list of bridges. They must flood or otherwise distribute
information out to other Tor nodes as mirrors. That way it becomes
-difficult for censors to flood the bridge directory servers with
+difficult for censors to flood the bridge directory authorities with
requests, effectively denying access for others. But, there's lots of
churn and a much larger size than Tor directories. We are forced to
handle the directory scaling problem here much sooner than for the
More information about the tor-commits
mailing list