|
@@ -91,8 +91,11 @@ leveraged for a new blocking-resistant design. Section~\ref{sec:related}
|
|
|
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
|
|
@@ -110,7 +113,7 @@ security implications; ..... %write the rest.
|
|
|
\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 @@ We assume that the attackers' goals are somewhat complex.
|
|
|
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 @@ Section~\ref{subsec:trust-chain} for discussion on helping the user
|
|
|
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 @@ user has for her first hop, and the more options she has for her last hop,
|
|
|
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 @@ Sixth, Tor has an established user base of hundreds of
|
|
|
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 @@ 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
|
|
|
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 @@ this idea when we consider whether and how to publicize a Tor variant
|
|
|
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 @@ have such a set: the Tor users.
|
|
|
|
|
|
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 @@ differently from, say, instant messaging.
|
|
|
% 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 @@ The first distribution strategy (used for the first pool) publishes bridge
|
|
|
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 @@ be useful to some users even as the arms races progress.
|
|
|
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 @@ always reasonable.
|
|
|
|
|
|
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 @@ community, though, this question remains a critical weakness.
|
|
|
%issues?
|
|
|
|
|
|
\section{Maintaining reachability}
|
|
|
+\label{sec:reachability}
|
|
|
|
|
|
\subsection{How many bridge relays should you know about?}
|
|
|
|
|
@@ -1522,37 +1528,50 @@ running bridges?
|
|
|
|
|
|
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}.
|
|
|
-
|
|
|
-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 use some kind of ID-based knocking protocol, or we could act like an
|
|
|
-unconfigured HTTPS server if treated like one.
|
|
|
-
|
|
|
-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).
|
|
|
-
|
|
|
+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.
|
|
|
+
|
|
|
+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.
|
|
|
+
|
|
|
+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 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 @@ will be pleased to run it. We take a similar approach here, by leveraging
|
|
|
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 @@ Many people working on this field want to publicize the existence
|
|
|
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 @@ other media.
|
|
|
See Section~\ref{subsec:first-bridge} for more discussion.
|
|
|
|
|
|
\section{Future designs}
|
|
|
+\label{sec:future}
|
|
|
|
|
|
\subsection{Bridges inside the blocked network too}
|
|
|
|
|
@@ -1651,16 +1674,30 @@ is a lot trickier because it brings in the complexity of whether the
|
|
|
internal bridges will remain available, can maintain reachability with
|
|
|
the outside world, etc.
|
|
|
|
|
|
-Hidden services as bridges. Hidden services as bridge directory authorities.
|
|
|
-
|
|
|
-\section{Conclusion}
|
|
|
-
|
|
|
-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.
|
|
|
-
|
|
|
-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.
|
|
|
+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.
|
|
|
+
|
|
|
+% Hidden services as bridge directory authorities.
|
|
|
+
|
|
|
+\section{Next Steps}
|
|
|
+\label{sec:conclusion}
|
|
|
+
|
|
|
+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}
|
|
|
|