Browse Source

continue fleshing out the blocking-resistance design doc

svn:r8385
Roger Dingledine 18 years ago
parent
commit
7f1fa9aab5
1 changed files with 91 additions and 33 deletions
  1. 91 33
      doc/design-paper/blocking.tex

+ 91 - 33
doc/design-paper/blocking.tex

@@ -29,7 +29,16 @@
 
 
 \begin{abstract}
 \begin{abstract}
 
 
-...
+Websites around the world are increasingly being blocked by
+government-level firewalls. Many people use anonymizing networks like
+Tor to contact sites without letting an attacker trace their activities,
+and as an added benefit they are no longer affected by local censorship.
+But if the attacker simply denies access to the Tor network itself,
+blocked users can no longer benefit from the security Tor offers.
+
+Here we describe a design that uses the current Tor network as a
+building block to provide an anonymizing network that resists blocking
+by government-level attackers.
 
 
 \end{abstract}
 \end{abstract}
 
 
@@ -61,7 +70,7 @@ location too.
 \section{Adversary assumptions}
 \section{Adversary assumptions}
 \label{sec:adversary}
 \label{sec:adversary}
 
 
-Three main network attacks currently:
+Three main network attacks by censors currently:
 
 
 \begin{tightlist}
 \begin{tightlist}
 \item Block destination by string matches in TCP packets.
 \item Block destination by string matches in TCP packets.
@@ -71,11 +80,18 @@ Three main network attacks currently:
 \item Intercept DNS requests.
 \item Intercept DNS requests.
 \end{tightlist}
 \end{tightlist}
 
 
-Assume the network firewall has very limited CPU [clayton06] %~\cite{clayton06}.
+Assume the network firewall has very limited CPU~\cite{clayton06}.
 
 
 Assume that readers of blocked content will not be punished much
 Assume that readers of blocked content will not be punished much
 (relative to writers).
 (relative to writers).
 
 
+Assume that while various different adversaries can coordinate and share
+notes, there will be a significant time lag between one attacker learning
+how to overcome a facet of our design and other attackers picking it up.
+
+
+
+
 \section{Related schemes}
 \section{Related schemes}
 
 
 \subsection{public single-hop proxies}
 \subsection{public single-hop proxies}
@@ -94,6 +110,16 @@ Easier to deploy; might not require client-side software.
 
 
 \subsection{Tor}
 \subsection{Tor}
 
 
+Anonymizing networks such as
+Tor~\cite{tor-design}
+aim to hide not only what is being said, but also who is
+communicating with whom, which 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 intelligence agencies who need
+to do operations on the Internet without being noticed.
+
 Tor provides three security properties:
 Tor provides three security properties:
 \begin{tightlist}
 \begin{tightlist}
 \item A local observer can't learn, or influence, your destination.
 \item A local observer can't learn, or influence, your destination.
@@ -121,19 +147,19 @@ whichever paths work.
 
 
 \subsection{Tor circuits}
 \subsection{Tor circuits}
 
 
-can build arbitrary overlay paths given a set of descriptors [blossom] %~\cite{blossom}
+can build arbitrary overlay paths given a set of descriptors~\cite{blossom}
 
 
 \subsection{Tor directory servers}
 \subsection{Tor directory servers}
 
 
 \subsection{Tor user base}
 \subsection{Tor user base}
 
 
-\section{The Design}
+\section{The Design, version one}
 
 
 \subsection{Bridge relays}
 \subsection{Bridge relays}
 
 
-Some Tor users on the free side of the network will opt to become bridge
+Some Tor users on the free side of the network will opt to become
-relays. They will relay a bit of traffic and don't allow exits. They
+bridge relays. They will relay a bit of traffic and won't need to allow
-sign up on the bridge directory authorities, below.
+exits. They sign up on the bridge directory authorities, below.
 
 
 ...need to outline instructions for a Tor config that will publish
 ...need to outline instructions for a Tor config that will publish
 to an alternate directory authority, and for controller commands
 to an alternate directory authority, and for controller commands
@@ -147,39 +173,53 @@ answer all queries as usual, except they don't publish network statuses.
 So once you know a bridge relay's key, you can get the most recent
 So once you know a bridge relay's key, you can get the most recent
 server descriptor for it.
 server descriptor for it.
 
 
-XXX need to figure out how to fetch some statuses from the BDA without
+XXX need to figure out how to fetch some server statuses from the BDA
-fetching all statuses. A new URL to fetch I presume?
+without fetching all statuses. A new URL to fetch I presume?
 
 
 \subsection{Blocked users}
 \subsection{Blocked users}
 
 
-If a blocked user knows about a working bridge relay, then he can make
+If a blocked user has a server descriptor for one working bridge relay,
-secure connections to the BDA to update his knowledge about bridge
+then he can make secure connections to the BDA to update his knowledge
+about other bridge
 relays, and he can make secure connections to the main Tor network
 relays, and he can make secure connections to the main Tor network
 and directory servers to build circuits and connect to the rest of
 and directory servers to build circuits and connect to the rest of
 the Internet.
 the Internet.
 
 
 So now we've reduced the problem from how to circumvent the firewall
 So now we've reduced the problem from how to circumvent the firewall
-for all transactions (and how to know that the pages you get are the
+for all transactions (and how to know that the pages you get have not
-real ones) to how to learn about a working bridge relay. They can
+been modified by the local attacker) to how to learn about a working
-be distributed in three ways:
+bridge relay.
-\begin{tightlist}
+
-\item IP:dirport, so the user can connect directly to the bridge
+The simplest format for communicating information about a bridge relay
-relay, learn the associated
+is as an IP address and port for its directory cache. From there, the
-server descriptor, and start building circuits. This is great, but what if
+user can ask the directory cache for an up-to-date copy of that bridge
-the firewall creates signatures for plaintext http requests for server
+relay's server descriptor, including its current circuit keys, the port
-descriptors, to block them? One option is a workaround that changes the
+it uses for Tor connections, and so on.
-appearance of the plaintext at each step (I can imagine a simple scheme
+
-where we send a 16 byte key, and then encrypt the rest of the stream with
+However, connecting directly to the directory cache involves a plaintext
-that key -- it doesn't provide actual confidentiality, but it's hard to
+http request, so the censor could create a firewall signature for the
-recognize that it's a Tor connection); another option is to conclude that
+request and/or its response, thus preventing these connections. If that
-it will be better to tunnel through a Tor circuit when fetching them.
+happens, the first fix is to use SSL -- not for authentication, but
-\item Key fingerprint, which lets you lookup the most recent server
+just for encryption so requests look different every time.
-descriptor at the BDA (assuming you can reach it).
+
-\item A blinded token, which can be exchanged at the BDA (assuming you
+There's another possible attack here: since we only learn an IP address
-can reach it) for a new IP:dirport or server descriptor.
+and port, a local attacker could intercept our directory request and
-\end{tightlist}
+give us some other server descriptor. But notice that we don't need
-
+strong authentication for the bridge relay. Since the Tor client will
-See the following section for ways to bootstrap knowledge of your first
+ship with trusted keys for the bridge directory authority and the Tor
+network directory authorities, the user can decide if the bridge relays
+are lying to him or not.
+
+Once the Tor client has fetched the server descriptor at least once,
+it should remember the identity key fingerprint for that bridge relay.
+If the bridge relay moves to a new IP address, the client can then
+use the bridge directory authority to look up a fresh server descriptor
+using this fingerprint.
+
+another option is to conclude
+that it will be better to tunnel through a Tor circuit when fetching them.
+
+The following section describes ways to bootstrap knowledge of your first
 bridge relay, and ways to maintain connectivity once you know a few
 bridge relay, and ways to maintain connectivity once you know a few
 bridge relays.
 bridge relays.
 
 
@@ -197,6 +237,13 @@ network or other mechanism for learning IP:dirport or key fingerprints
 as above, or we assume an account server that allows us to limit the
 as above, or we assume an account server that allows us to limit the
 number of new bridge relays an external attacker can discover.
 number of new bridge relays an external attacker can discover.
 
 
+
+
+\section{The Design, version two}
+
+\item A blinded token, which can be exchanged at the BDA (assuming you
+can reach it) for a new IP:dirport or server descriptor.
+
 \subsection{The account server}
 \subsection{The account server}
 
 
 Users can establish reputations, perhaps based on social network
 Users can establish reputations, perhaps based on social network
@@ -271,6 +318,17 @@ provides improved anonymity against some attacks too:
 http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#ServerAnonymity
 http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#ServerAnonymity
 \end{verbatim}
 \end{verbatim}
 
 
+\subsection{Cablemodem users don't provide important websites}
+
+...so our adversary could just block all DSL and cablemodem networks,
+and for the most part only our bridge relays would be affected.
+
+The first answer is to aim to get volunteers both from traditionally
+``consumer'' networks and also from traditionally ``producer'' networks.
+
+The second answer (not so good) would be to encourage more use of consumer
+networks for popular and useful websites.
+
 \section{Future designs}
 \section{Future designs}
 
 
 \subsection{Bridges inside the blocked network too}
 \subsection{Bridges inside the blocked network too}