\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} % need a way for users to get tor itself. (discuss trust chain.)