[or-cvs] r8942: finish the draft. (tor/trunk/doc/design-paper)
arma at seul.org
arma at seul.org
Mon Nov 13 03:52:51 UTC 2006
Author: arma
Date: 2006-11-12 22:52:50 -0500 (Sun, 12 Nov 2006)
New Revision: 8942
Added:
tor/trunk/doc/design-paper/blocking.pdf
Modified:
tor/trunk/doc/design-paper/blocking.tex
Log:
finish the draft.
Added: tor/trunk/doc/design-paper/blocking.pdf
===================================================================
(Binary files differ)
Property changes on: tor/trunk/doc/design-paper/blocking.pdf
___________________________________________________________________
Name: svn:mime-type
+ application/octet-stream
Modified: tor/trunk/doc/design-paper/blocking.tex
===================================================================
--- tor/trunk/doc/design-paper/blocking.tex 2006-11-12 23:37:47 UTC (rev 8941)
+++ tor/trunk/doc/design-paper/blocking.tex 2006-11-13 03:52:50 UTC (rev 8942)
@@ -91,9 +91,12 @@
explains the features and drawbacks of the currently deployed solutions.
In sections~\ref{sec:bridges} through~\ref{sec:discovery}, we explore the
components of our designs in detail. Section~\ref{sec:security} considers
-security implications; ..... %write the rest.
+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,
+and finally Section~\ref{sec:conclusion} summarizes our next steps and
+recommendations.
-
% The other motivation is for places where we're concerned they will
% try to enumerate a list of Tor users. So even if they're not blocking
% the Tor network, it may be smart to not be visible as connecting to it.
@@ -110,7 +113,7 @@
\section{Adversary assumptions}
\label{sec:adversary}
-To design an effective anticensorship tool, we need a good model for the
+To design an effective anti-censorship tool, we need a good model for the
goals and resources of the censors we are evading. Otherwise, we risk
spending our effort on keeping the adversaries from doing things they have no
interest in doing, and thwarting techniques they do not use.
@@ -149,7 +152,7 @@
impossible, but unnecessary: if ``undesirable'' information is known only
to a small few, further censoring efforts can be focused elsewhere.
\item Similarly, the censors are not attempting to shut down or block {\it
- every} anticensorship tool---merely the tools that are popular and
+ every} anti-censorship tool---merely the tools that are popular and
effective (because these tools impede the censors' information restriction
goals) and those tools that are highly visible (thus making the censors
look ineffectual to their citizens and their bosses).
@@ -238,7 +241,7 @@
confirm that he has a genuine version and that he can connect to the
real Tor network.
-\section{Adapting the current Tor design to anticensorship}
+\section{Adapting the current Tor design to anti-censorship}
\label{sec:current-tor}
Tor is popular and sees a lot of use. It's the largest anonymity
@@ -325,8 +328,8 @@
the less likely it is that a given attacker will be watching both ends
of her circuit~\cite{tor-design}. As a bonus, because our design attracts
more internal relays that want to help out but don't want to deal with
-being an exit relay, we end up with more options for the first hop---the
-one most critical to being able to reach the Tor network.
+being an exit relay, we end up providing more options for the first
+hop---the one most critical to being able to reach the Tor network.
Fifth, Tor is sustainable. Zero-Knowledge Systems offered the commercial
but now defunct Freedom Network~\cite{freedom21-security}, a design with
@@ -346,7 +349,8 @@
thousands of people from around the world. This diversity of
users contributes to sustainability as above: Tor is used by
ordinary citizens, activists, corporations, law enforcement, and
-even government and military users\footnote{http://tor.eff.org/overview},
+even government and military users,
+%\footnote{http://tor.eff.org/overview}
and they can
only achieve their security goals by blending together in the same
network~\cite{econymics,usability:weis2006}. This user base also provides
@@ -356,7 +360,7 @@
Finally and perhaps most importantly, Tor provides anonymity and prevents any
single server from linking users to their communication partners. Despite
initial appearances, {\it distributed-trust anonymity is critical for
-anticensorship efforts}. If any single server can expose dissident bloggers
+anti-censorship efforts}. If any single server 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
employers,
@@ -609,7 +613,7 @@
that improves blocking-resistance---see Section~\ref{subsec:publicity}
for more discussion.)
-The broader explanation is that the maintainance of most government-level
+The broader explanation is that the maintenance of most government-level
filters is aimed at stopping widespread information flow and appearing to be
in control, not by the impossible goal of blocking all possible ways to bypass
censorship. Censors realize that there will always
@@ -647,7 +651,7 @@
Hundreds of thousands of people around the world use Tor. We can leverage
our already self-selected user base to produce a list of thousands of
-often-changing IP addresses. Specifically, we can give them a little
+frequently-changing IP addresses. Specifically, we can give them a little
button in the GUI that says ``Tor for Freedom'', and users who click
the button will turn into \emph{bridge relays} (or just \emph{bridges}
for short). They can rate limit relayed connections to 10 KB/s (almost
@@ -847,6 +851,7 @@
% learn that these are related problems, but it's not obvious to me. -RD
\subsection{Identity keys as part of addressing information}
+\label{subsec:id-address}
We have described a way for the blocked user to bootstrap into the
network once he knows the IP address and ORPort of a bridge. What about
@@ -1020,7 +1025,7 @@
addresses in a time-release fashion. The bridge authority divides the
available bridges into partitions, and each partition is deterministically
available only in certain time windows. That is, over the course of a
-given time slot (say, an hour), each requestor is given a random bridge
+given time slot (say, an hour), each requester is given a random bridge
from within that partition. When the next time slot arrives, a new set
of bridges from the pool are available for discovery. Thus some bridge
address is always available when a new
@@ -1036,9 +1041,9 @@
The second distribution strategy publishes bridge addresses based on the IP
address of the requesting user. Specifically, the bridge authority will
divide the available bridges in the pool into a bunch of partitions
-(as in the first distribution scheme), hash the requestor's IP address
+(as in the first distribution scheme), hash the requester's IP address
with a secret of its own (as in the above allocation scheme for creating
-pools), and give the requestor a random bridge from the appropriate
+pools), and give the requester a random bridge from the appropriate
partition. To raise the bar, we should discard the last octet of the
IP address before inputting it to the hash function, so an attacker
who only controls a single ``/24'' network only counts as one user. A
@@ -1387,13 +1392,13 @@
For Internet cafe Windows computers that let you attach your own USB key,
a USB-based Tor image would be smart. There's Torpark, and hopefully
-there will be more thoroughly analyzed options down the road. Worries
-remain about hardware or
-software keyloggers and other spyware---and physical surveillance.
+there will be more thoroughly analyzed and trustworthy options down the
+road. Worries remain about hardware or software keyloggers and other
+spyware, as well as and physical surveillance.
If the system lets you boot from a CD or from a USB key, you can gain
a bit more security by bringing a privacy LiveCD with you. (This
-approach isn't foolproof of course, since hardware
+approach isn't foolproof either of course, since hardware
keyloggers and physical surveillance are still a worry).
In fact, LiveCDs are also useful if it's your own hardware, since it's
@@ -1460,6 +1465,7 @@
%issues?
\section{Maintaining reachability}
+\label{sec:reachability}
\subsection{How many bridge relays should you know about?}
@@ -1522,37 +1528,50 @@
If it's trivial to verify that a given address is operating as a bridge,
and most bridges run on a predictable port, then it's conceivable our
-attacker could scan the whole Internet looking for bridges. (In fact, he
-can just concentrate on scanning likely networks like cablemodem and DSL
-services---see Section~\ref{subsec:block-cable} above for related attacks.) It
-would be nice to slow down this attack. It would be even nicer to make
-it hard to learn whether we're a bridge without first knowing some
-secret. We call this general property \emph{scanning resistance}.
+attacker could scan the whole Internet looking for bridges. (In fact,
+he can just concentrate on scanning likely networks like cablemodem
+and DSL services---see Section~\ref{subsec:block-cable} above for
+related attacks.) It would be nice to slow down this attack. It would
+be even nicer to make it hard to learn whether we're a bridge without
+first knowing some secret. We call this general property \emph{scanning
+resistance}, and it goes along with normalizing Tor's TLS handshake and
+network signature.
-Password protecting the bridges.
-Could provide a password to the bridge user. He provides a nonced hash of
-it or something when he connects. We'd need to give him an ID key for the
-bridge too, and wait to present the password until we've TLSed, else the
-adversary can pretend to be the bridge and MITM him to learn the password.
+We could provide a password to the blocked user, and she (or her Tor
+client) provides a nonced hash of this password when she connects. We'd
+need to give her an ID key for the bridge too (in addition to the IP
+address and port---see Section~\ref{subsec:id-address}), and wait to
+present the password until we've finished the TLS handshake, else it
+would look unusual. If Alice can authenticate the bridge before she
+tries to send her password, we can resist an adversary who pretends
+to be the bridge and launches a man-in-the-middle attack to learn the
+password. But even if she can't, we resist against widespread scanning.
-We could use some kind of ID-based knocking protocol, or we could act like an
-unconfigured HTTPS server if treated like one.
+Another approach would be some kind of ID-based knocking protocol,
+where the bridge only answers after some predefined set of connections
+or interactions. The bridge could even act like an unconfigured HTTPS
+server (``welcome to the default Apache page'') if accessed without the
+correct authorization.
-We can assume that the attacker can easily recognize https connections
-to unknown servers. It can then attempt to connect to them and block
-connections to servers that seem suspicious. It may be that password
-protected web sites will not be suspicious in general, in which case
-that may be the easiest way to give controlled access to the bridge.
-If such sites that have no other overt features are automatically
-blocked when detected, then we may need to be more subtle.
-Possibilities include serving an innocuous web page if a TLS encrypted
-request is received without the authorization needed to access the Tor
-network and only responding to a requested access to the Tor network
-of proper authentication is given. If an unauthenticated request to
-access the Tor network is sent, the bridge should respond as if
-it has received a message it does not understand (as would be the
-case were it not a bridge).
+We might assume that the attacker can recognize HTTPS connections that
+use self-signed certificates. (This process would be resource-intensive
+but not out of the realm of possibility.) But even in this case, many
+popular websites around the Internet use self-signed or just plain broken
+SSL certificates.
+%to unknown servers. It can then attempt to connect to them and block
+%connections to servers that seem suspicious. It may be that password
+%protected web sites will not be suspicious in general, in which case
+%that may be the easiest way to give controlled access to the bridge.
+%If such sites that have no other overt features are automatically
+%blocked when detected, then we may need to be more subtle.
+%Possibilities include serving an innocuous web page if a TLS encrypted
+%request is received without the authorization needed to access the Tor
+%network and only responding to a requested access to the Tor network
+%of proper authentication is given. If an unauthenticated request to
+%access the Tor network is sent, the bridge should respond as if
+%it has received a message it does not understand (as would be the
+%case were it not a bridge).
\subsection{How to motivate people to run bridge relays}
\label{subsec:incentives}
@@ -1564,14 +1583,16 @@
the fact that these users are already interested in protecting their
own Internet traffic, so they will install and run the software.
-Make all Tor users become bridges if they're reachable---needs more work
-on usability first, but we're making progress.
+Eventually, we may be able to make all Tor users become bridges if they
+pass their self-reachability tests---the software and installers need
+more work on usability first, but we're making progress.
-Also, we can make a snazzy network graph with Vidalia that emphasizes
-the connections the bridge user is currently relaying. (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.)
+In the mean time, we can make a snazzy network graph with Vidalia that
+emphasizes the connections the bridge user is currently relaying.
+%(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.)
% Also consider everybody-a-server. Many of the scalability questions
% are easier when you're talking about making everybody a bridge.
@@ -1608,16 +1629,17 @@
and extent of censorship concurrently with the deployment of their
circumvention software. The easy reason for this two-pronged push is
to attract volunteers for running proxies in their systems; but in many
-cases their main goal is not to build the software, but rather to educate
-the world about the censorship. The media also tries to do its part by
-broadcasting the existence of each new circumvention system.
+cases their main goal is not to focus on actually allowing individuals
+to circumvent the firewall, but rather to educate the world about the
+censorship. The media also tries to do its part by broadcasting the
+existence of each new circumvention system.
But at the same time, this publicity attracts the attention of the
censors. We can slow down the arms race by not attracting as much
attention, and just spreading by word of mouth. If our goal is to
establish a solid social network of bridges and bridge users before
-the adversary gets involved, does this attention tradeoff work to our
-advantage?
+the adversary gets involved, does this extra attention work to our
+disadvantage?
\subsection{The Tor website: how to get the software}
@@ -1636,6 +1658,7 @@
See Section~\ref{subsec:first-bridge} for more discussion.
\section{Future designs}
+\label{sec:future}
\subsection{Bridges inside the blocked network too}
@@ -1651,17 +1674,31 @@
internal bridges will remain available, can maintain reachability with
the outside world, etc.
-Hidden services as bridges. Hidden services as bridge directory authorities.
+More complex future designs involve operating a separate Tor network
+inside the blocked area, and using \emph{hidden service bridges}---bridges
+that can be accessed by users of the internal Tor network but whose
+addresses are not published or findable, even by these users---to get
+from inside the firewall to the rest of the Internet. But this design
+requires directory authorities to run inside the blocked area too,
+and they would be a fine target to take down the network.
-\section{Conclusion}
+% Hidden services as bridge directory authorities.
-a technical solution won't solve the whole problem. after all, china's
-firewall is *socially* very successful, even if technologies exist to
-get around it.
+\section{Next Steps}
+\label{sec:conclusion}
-but having a strong technical solution is still useful as a piece of the
-puzzle. and tor provides a great set of building blocks to start from.
+Technical solutions won't solve the whole censorship problem. After all,
+the firewalls in places like China and Iran are \emph{socially} very
+successful, even if technologies and tricks exist to get around them.
+However, having a strong technical solution is still necessary as one
+important piece of the puzzle.
+In this paper, we have shown that Tor provides a great set of building
+blocks to start from. The next steps are to deploy prototype bridges and
+bridge authorities, implement some of the proposed discovery strategies,
+and then observe the system in operation and get more intuition about
+the actual requirements and adversaries we're up against.
+
\bibliographystyle{plain} \bibliography{tor-design}
%\appendix
More information about the tor-commits
mailing list