1 files changed, 352 insertions, 0 deletions
diff --git a/doc/design-paper/blocking.tex b/doc/design-paper/blocking.tex
new file mode 100644
index 0000000000..ebc677ab82
--- /dev/null
+++ b/doc/design-paper/blocking.tex
@@ -0,0 +1,352 @@
+\documentclass{llncs}
+
+\usepackage{url}
+\usepackage{amsmath}
+\usepackage{epsfig}
+
+%\setlength{\textwidth}{5.9in}
+%\setlength{\textheight}{8.4in}
+%\setlength{\topmargin}{.5cm}
+%\setlength{\oddsidemargin}{1cm}
+%\setlength{\evensidemargin}{1cm}
+
+\newenvironment{tightlist}{\begin{list}{$\bullet$}{
+  \setlength{\itemsep}{0mm}
+    \setlength{\parsep}{0mm}
+    %  \setlength{\labelsep}{0mm}
+    %  \setlength{\labelwidth}{0mm}
+    %  \setlength{\topsep}{0mm}
+    }}{\end{list}}
+
+\begin{document}
+
+\title{Design of a blocking-resistant anonymity system}
+
+\author{}
+
+\maketitle
+\pagestyle{plain}
+
+\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}
+
+\section{Introduction and Goals}
+
+Websites like Wikipedia and Blogspot are increasingly being blocked by
+government-level firewalls around the world.
+
+China is the third largest user base for Tor clients~\cite{geoip-tor}.
+Many people already want it, and the current Tor design is easy to block
+(by blocking the directory authorities, by blocking all the server
+IP addresses, or by filtering the signature of the Tor TLS handshake).
+
+Now that we've got an overlay network, we're most of the way there in
+terms of building a blocking-resistant tool.
+
+And it improves the anonymity that Tor can provide to add more different
+classes of users and goals to the Tor network.
+
+\subsection{A single system that works for multiple blocked domains}
+
+We want this to work for people in China, people in Iran, people in
+Thailand, people in firewalled corporate networks, etc. The blocking
+censor will be at different stages of the arms race in different places;
+and likely the list of blocked addresses will be different in each
+location too.
+
+
+\section{Adversary assumptions}
+\label{sec:adversary}
+
+Three main network attacks by censors currently:
+
+\begin{tightlist}
+\item Block destination by string matches in TCP packets.
+
+\item Block destination by IP address.
+
+\item Intercept DNS requests.
+\end{tightlist}
+
+Assume the network firewall has very limited CPU~\cite{clayton06}.
+
+Assume that readers of blocked content will not be punished much
+(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}
+
+\subsection{public single-hop proxies}
+
+\subsection{personal single-hop proxies}
+
+Easier to deploy; might not require client-side software.
+
+\subsection{break your sensitive strings into multiple tcp packets}
+
+\subsection{steganography}
+
+% \subsection{}
+
+\section{Useful building blocks}
+
+\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:
+\begin{tightlist}
+\item A local observer can't learn, or influence, your destination.
+\item The destination, or somebody watching the destination, can't learn
+your location.
+\item No single piece of the infrastructure can link you to your
+destination.
+\end{tightlist}
+
+We care most clearly about property number 1. But when the arms race
+progresses, property 2 will become important -- so the blocking adversary
+can't learn user+destination just by volunteering a relay. It's not so
+clear to see that property 3 is important, but consider websites and
+services that are pressured into treating clients from certain network
+locations differently.
+
+Other benefits:
+
+\begin{tightlist}
+\item Separates the role of relay from the role of exit node.
+
+\item (Re)builds circuits automatically in the background, based on
+whichever paths work.
+\end{tightlist}
+
+\subsection{Tor circuits}
+
+can build arbitrary overlay paths given a set of descriptors~\cite{blossom}
+
+\subsection{Tor directory servers}
+
+\subsection{Tor user base}
+
+\section{The Design, version one}
+
+\subsection{Bridge relays}
+
+Some Tor users on the free side of the network will opt to become
+bridge relays. They will relay a bit of traffic and won't need to allow
+exits. They sign up on the bridge directory authorities, below.
+
+...need to outline instructions for a Tor config that will publish
+to an alternate directory authority, and for controller commands
+that will do this cleanly.
+
+\subsection{The bridge directory authority (BDA)}
+
+They aggregate server descriptors just like the main authorities, and
+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
+server descriptor for it.
+
+XXX need to figure out how to fetch some server statuses from the BDA
+without fetching all statuses. A new URL to fetch I presume?
+
+\subsection{Blocked users}
+
+If a blocked user has a server descriptor for one working bridge relay,
+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
+and directory servers to build circuits and connect to the rest of
+the Internet.
+
+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 have not
+been modified by the local attacker) to how to learn about a working
+bridge relay.
+
+The simplest format for communicating information about a bridge relay
+is as an IP address and port for its directory cache. From there, the
+user can ask the directory cache for an up-to-date copy of that bridge
+relay's server descriptor, including its current circuit keys, the port
+it uses for Tor connections, and so on.
+
+However, connecting directly to the directory cache involves a plaintext
+http request, so the censor could create a firewall signature for the
+request and/or its response, thus preventing these connections. If that
+happens, the first fix is to use SSL -- not for authentication, but
+just for encryption so requests look different every time.
+
+There's another possible attack here: since we only learn an IP address
+and port, a local attacker could intercept our directory request and
+give us some other server descriptor. But notice that we don't need
+strong authentication for the bridge relay. Since the Tor client will
+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 relays.
+
+\section{Discovering and maintaining working bridge relays}
+
+\subsection{Initial network discovery}
+
+We make the assumption that the firewall is not perfect. People can
+get around it through the usual means, or they know a friend who can.
+If they can't get around it at all, then we can't help them -- they
+should go meet more people.
+
+Thus they can reach the BDA. From here we either assume a social
+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
+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}
+
+Users can establish reputations, perhaps based on social network
+connectivity, perhaps based on not getting their bridge relays blocked,
+
+
+
+\section{Other issues}
+
+\subsection{How many bridge relays should you know about?}
+
+If they're ordinary Tor users on cable modem or DSL, many of them will
+disappear periodically. How many bridge relays should a blockee know
+about before he's likely to have at least one up at any given point?
+
+The related question is: if the bridge relays change IP addresses
+periodically, how often does the blockee need to "check in" in order
+to keep from being cut out of the loop?
+
+\subsection{How do we know if a bridge relay has been blocked?}
+
+We need some mechanism for testing reachability from inside the
+blocked area. The easiest answer is for certain users inside
+the area to sign up as testing relays, and then we can route through
+them and see if it works.
+
+First problem is that different network areas block different net masks,
+and it will likely be hard to know which users are in which areas. So
+if a bridge relay isn't reachable, is that because of a network block
+somewhere, because of a problem at the bridge relay, or just a temporary
+outage?
+
+Second problem is that if we pick random users to test random relays, the
+adversary should sign up users on the inside, and enumerate the relays
+we test. But it seems dangerous to just let people come forward and
+declare that things are blocked for them, since they could be tricking
+us. (This matters even moreso if our reputation system above relies on
+whether things get blocked to punish or reward.)
+
+
+
+
+\subsection{Tunneling directory lookups through Tor}
+
+All you need to do is bootstrap, and then you can use
+your Tor connection to maintain your Tor connection,
+including doing secure directory fetches.
+
+\subsection{Predictable SSL ports}
+
+We should encourage most servers to listen on port 443, which is
+where SSL normally listens.
+
+Is that all it will take, or should we set things up so some fraction
+of them pick random ports? I can see that both helping and hurting.
+
+\subsection{Predictable TLS handshakes}
+
+Right now Tor has some predictable strings in its TLS handshakes.
+These can be removed; but should they be replaced with nothing, or
+should we try to emulate some popular browser? In any case our
+protocol demands a pair of certs on both sides -- how much will this
+make Tor handshakes stand out?
+
+\section{Anonymity issues from becoming a bridge relay}
+
+You can actually harm your anonymity by relaying traffic in Tor.  This is
+the same issue that ordinary Tor servers face. On the other hand, it
+provides improved anonymity against some attacks too:
+
+\begin{verbatim}
+http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#ServerAnonymity
+\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}
+
+\subsection{Bridges inside the blocked network too}
+
+Assuming actually crossing the firewall is the risky part of the
+operation, can we have some bridge relays inside the blocked area too,
+and more established users can use them as relays so they don't need to
+communicate over the firewall directly at all? A simple example here is
+to make new blocked users into internal bridges also -- so they sign up
+on the BDA as part of doing their query, and we give out their addresses
+rather than (or along with) the external bridge addresses. This design
+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.
+
+%\bibliographystyle{plain} \bibliography{tor-design}
+
+\end{document}
+