[tor-commits] [tech-reports/master] Add unchanged blocking tech report sources.

commit 59a46d6edd7bea6df8fb5cb9779054340ac1a408 Author: Karsten Loesing karsten.loesing@gmx.net Date: Thu Aug 30 11:26:49 2012 +0200

Add unchanged blocking tech report sources. --- 2006/blocking/.gitignore | 3 + 2006/blocking/blocking.tex | 1894 ++++++++++++++++++++++++++++++++++++++++ 2006/blocking/tor-design.bib | 1493 +++++++++++++++++++++++++++++++ 2006/blocking/usenixsubmit.cls | 7 + 4 files changed, 3397 insertions(+), 0 deletions(-)

diff --git a/2006/blocking/.gitignore b/2006/blocking/.gitignore new file mode 100644 index 0000000..cca8809 --- /dev/null +++ b/2006/blocking/.gitignore @@ -0,0 +1,3 @@ +blocking.pdf +blocking-2006-11.pdf + diff --git a/2006/blocking/blocking.tex b/2006/blocking/blocking.tex new file mode 100644 index 0000000..3d46ef1 --- /dev/null +++ b/2006/blocking/blocking.tex @@ -0,0 +1,1894 @@ +%\documentclass{llncs} +\documentclass{usenixsubmit} +%\documentclass[twocolumn]{article} +%usepackage{usenix} + +\usepackage{url} +\usepackage{amsmath} +\usepackage{epsfig} + +\setlength{\textwidth}{6.0in} +\setlength{\textheight}{8.5in} +\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}} + +\newcommand{\workingnote}[1]{} % The version that hides the note. +%\newcommand{\workingnote}[1]{(**#1)} % makes the note visible. + +\date{} +\title{Design of a blocking-resistant anonymity system\Tor Project technical report, Nov 2006} + +%\author{Roger Dingledine\inst{1} \and Nick Mathewson\inst{1}} +\author{Roger Dingledine \ The Tor Project \ arma@torproject.org \and +Nick Mathewson \ The Tor Project \ nickm@torproject.org} + +\begin{document} +\maketitle +\pagestyle{plain} + +\begin{abstract} + +Internet censorship is on the rise as websites around the world are +increasingly blocked by government-level firewalls. Although popular +anonymizing networks like Tor were originally designed to keep attackers from +tracing people's activities, many people are also using them to evade local +censorship. But if the censor 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 builds upon the current Tor network +to provide an anonymizing network that resists blocking +by government-level attackers. % We have implemented and deployed this +%design, and talk briefly about early use. + +\end{abstract} + +\section{Introduction} + +Anonymizing networks like Tor~\cite{tor-design} bounce traffic around a +network of encrypting relays. Unlike encryption, which hides only {\it what} +is said, these networks also aim to hide 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. + +Historical anonymity research has focused on an +attacker who monitors the user (call her Alice) and tries to discover her +activities, yet lets her reach any piece of the network. In more modern +threat models such as Tor's, the adversary is allowed to perform active +attacks such as modifying communications to trick Alice +into revealing her destination, or intercepting some connections +to run a man-in-the-middle attack. But these systems still assume that +Alice can eventually reach the anonymizing network. + +An increasing number of users are using the Tor software +less for its anonymity properties than for its censorship +resistance properties---if they use Tor to access Internet sites like +Wikipedia +and Blogspot, they are no longer affected by local censorship +and firewall rules. In fact, an informal user study +%(described in Appendix~\ref{app:geoip}) +showed that a few hundred thousand users people access the Tor network +each day, with about 20% of them coming from China. %~\cite{something}. + +The current Tor design is easy to block if the attacker controls Alice's +connection to the Tor network---by blocking the directory authorities, +by blocking all the relay IP addresses in the directory, or by filtering +based on the network fingerprint of the Tor TLS handshake. Here we +describe an +extended design that builds upon the current Tor network to provide an +anonymizing +network that resists censorship as well as anonymity-breaking attacks. +In section~\ref{sec:adversary} we discuss our threat model---that is, +the assumptions we make about our adversary. Section~\ref{sec:current-tor} +describes the components of the current Tor design and how they can be +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 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, +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. + +%And adding more different classes of users and goals to the Tor network +%improves the anonymity for all Tor users~\cite{econymics,usability:weis2006}. + +% Adding use classes for countering blocking as well as anonymity has +% benefits too. Should add something about how providing undetected +% access to Tor would facilitate people talking to, e.g., govt. authorities +% about threats to public safety etc. in an environment where Tor use +% is not otherwise widespread and would make one stand out. + +\section{Adversary assumptions} +\label{sec:adversary} + +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. +The history of blocking-resistance designs is littered with conflicting +assumptions about what adversaries to expect and what problems are +in the critical path to a solution. Here we describe our best +understanding of the current situation around the world. + +In the traditional security style, we aim to defeat a strong +attacker---if we can defend against this attacker, we inherit protection +against weaker attackers as well. After all, we want a general design +that will work for citizens of China, Thailand, and other censored +countries; for +whistleblowers in firewalled corporate networks; and for people in +unanticipated oppressive situations. In fact, by designing with +a variety of adversaries in mind, we can take advantage of the fact that +adversaries will be in different stages of the arms race at each location, +so an address blocked in one locale can still be useful in others. +We focus on an attacker with somewhat complex goals: + +\begin{tightlist} +\item The attacker would like to restrict the flow of certain kinds of + information, particularly when this information is seen as embarrassing to + those in power (such as information about rights violations or corruption), + or when it enables or encourages others to oppose them effectively (such as + information about opposition movements or sites that are used to organize + protests). +\item As a second-order effect, censors aim to chill citizens' behavior by + creating an impression that their online activities are monitored. +\item In some cases, censors make a token attempt to block a few sites for + obscenity, blasphemy, and so on, but their efforts here are mainly for + show. In other cases, they really do try hard to block such content. +\item Complete blocking (where nobody at all can ever download censored + content) is not a + goal. Attackers typically recognize that perfect censorship is not only + impossible, it is unnecessary: if ``undesirable'' information is known only + to a small few, further censoring efforts can be focused elsewhere. +\item Similarly, the censors do not attempt to shut down or block {\it + 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). +\item Reprisal against {\it most} passive consumers of {\it most} kinds of + blocked information is also not a goal, given the broadness of most + censorship regimes. This seems borne out by fact.\footnote{So far in places + like China, the authorities mainly go after people who publish materials + and coordinate organized movements~\cite{mackinnon-personal}. + If they find that a + user happens to be reading a site that should be blocked, the typical + response is simply to block the site. Of course, even with an encrypted + connection, the adversary may be able to distinguish readers from + publishers by observing whether Alice is mostly downloading bytes or mostly + uploading them---we discuss this issue more in + Section~\ref{subsec:upload-padding}.} +\item Producers and distributors of targeted information are in much + greater danger than consumers; the attacker would like to not only block + their work, but identify them for reprisal. +\item The censors (or their governments) would like to have a working, useful + Internet. There are economic, political, and social factors that prevent + them from ``censoring'' the Internet by outlawing it entirely, or by + blocking access to all but a tiny list of sites. + Nevertheless, the censors {\it are} willing to block innocuous content + (like the bulk of a newspaper's reporting) in order to censor other content + distributed through the same channels (like that newspaper's coverage of + the censored country). +\end{tightlist} + +We assume there are three main technical network attacks in use by censors +currently~\cite{clayton:pet2006}: + +\begin{tightlist} +\item Block a destination or type of traffic by automatically searching for + certain strings or patterns in TCP packets. Offending packets can be + dropped, or can trigger a response like closing the + connection. +\item Block certain IP addresses or destination ports at a + firewall or other routing control point. +\item Intercept DNS requests and give bogus responses for certain + destination hostnames. +\end{tightlist} + +We assume the network firewall has limited CPU and memory per +connection~\cite{clayton:pet2006}. Against an adversary who could carefully +examine the contents of every packet and correlate the packets in every +stream on the network, we would need some stronger mechanism such as +steganography, which introduces its own +problems~\cite{active-wardens,tcpstego}. But we make a ``weak +steganography'' assumption here: to remain unblocked, it is necessary to +remain unobservable only by computational resources on par with a modern +router, firewall, proxy, or IDS. + +We assume that while various different regimes can coordinate and share +notes, there will be a time lag between one attacker learning how to overcome +a facet of our design and other attackers picking it up. (The most common +vector of transmission seems to be commercial providers of censorship tools: +once a provider adds a feature to meet one country's needs or requests, the +feature is available to all of the provider's customers.) Conversely, we +assume that insider attacks become a higher risk only after the early stages +of network development, once the system has reached a certain level of +success and visibility. + +We do not assume that government-level attackers are always uniform +across the country. For example, users of different ISPs in China +experience different censorship policies and mechanisms. %~\cite{china-ccs07}. +%there is no single centralized place in China +%that coordinates its specific censorship decisions and steps. + +We assume that the attacker may be able to use political and economic +resources to secure the cooperation of extraterritorial or multinational +corporations and entities in investigating information sources. +For example, the censors can threaten the service providers of +troublesome blogs with economic reprisals if they do not reveal the +authors' identities. + +We assume that our users have control over their hardware and +software---they don't have any spyware installed, there are no +cameras watching their screens, etc. Unfortunately, in many situations +these threats are real~\cite{zuckerman-threatmodels}; yet +software-based security systems like ours are poorly equipped to handle +a user who is entirely observed and controlled by the adversary. See +Section~\ref{subsec:cafes-and-livecds} for more discussion of what little +we can do about this issue. + +Similarly, we assume that the user will be able to fetch a genuine +version of Tor, rather than one supplied by the adversary; see +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 anti-censorship} +\label{sec:current-tor} + +Tor is popular and sees a lot of use---it's the largest anonymity +network of its kind, and has +attracted more than 1500 volunteer-operated routers from around the +world. Tor protects each user by routing their traffic through a multiply +encrypted ``circuit'' built of a few randomly selected relay, each of which +can remove only a single layer of encryption. Each relay sees only the step +before it and the step after it in the circuit, and so no single relay can +learn the connection between a user and her chosen communication partners. +In this section, we examine some of the reasons why Tor has become popular, +with particular emphasis to how we can take advantage of these properties +for a blocking-resistance design. + +Tor aims to provide three security properties: +\begin{tightlist} +\item 1. A local network attacker can't learn, or influence, your +destination. +\item 2. No single router in the Tor network can link you to your +destination. +\item 3. The destination, or somebody watching the destination, +can't learn your location. +\end{tightlist} + +For blocking-resistance, we care most clearly about the first +property. But as the arms race progresses, the second property +will become important---for example, to discourage an adversary +from volunteering a relay in order to learn that Alice is reading +or posting to certain websites. The third property helps keep users safe from +collaborating websites: consider websites and other Internet services +that have been pressured +recently into revealing the identity of bloggers +%~\cite{arrested-bloggers} +or treating clients differently depending on their network +location~\cite{netauth}. +%~\cite{google-geolocation}. + +The Tor design provides other features as well that are not typically +present in manual or ad hoc circumvention techniques. + +First, Tor has a well-analyzed and well-understood way to distribute +information about relay. +Tor directory authorities automatically aggregate, test, +and publish signed summaries of the available Tor routers. Tor clients +can fetch these summaries to learn which routers are available and +which routers are suitable for their needs. Directory information is cached +throughout the Tor network, so once clients have bootstrapped they never +need to interact with the authorities directly. (To tolerate a minority +of compromised directory authorities, we use a threshold trust scheme--- +see Section~\ref{subsec:trust-chain} for details.) + +Second, the list of directory authorities is not hard-wired. +Clients use the default authorities if no others are specified, +but it's easy to start a separate (or even overlapping) Tor network just +by running a different set of authorities and convincing users to prefer +a modified client. For example, we could launch a distinct Tor network +inside China; some users could even use an aggregate network made up of +both the main network and the China network. (But we should not be too +quick to create other Tor networks---part of Tor's anonymity comes from +users behaving like other users, and there are many unsolved anonymity +questions if different users know about different pieces of the network.) + +Third, in addition to automatically learning from the chosen directories +which Tor routers are available and working, Tor takes care of building +paths through the network and rebuilding them as needed. So the user +never has to know how paths are chosen, never has to manually pick +working proxies, and so on. More generally, at its core the Tor protocol +is simply a tool that can build paths given a set of routers. Tor is +quite flexible about how it learns about the routers and how it chooses +the paths. Harvard's Blossom project~\cite{blossom-thesis} makes this +flexibility more concrete: Blossom makes use of Tor not for its security +properties but for its reachability properties. It runs a separate set +of directory authorities, its own set of Tor routers (called the Blossom +network), and uses Tor's flexible path-building to let users view Internet +resources from any point in the Blossom network. + +Fourth, Tor separates the role of \emph{internal relay} from the +role of \emph{exit relay}. That is, some volunteers choose just to relay +traffic between Tor users and Tor routers, and others choose to also allow +connections to external Internet resources. Because we don't force all +volunteers to play both roles, we end up with more relays. This increased +diversity in turn is what gives Tor its security: the more options the +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 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 +security comparable to Tor's, but its funding model relied on collecting +money from users to pay relay operators. Modern commercial proxy systems +similarly +need to keep collecting money to support their infrastructure. On the +other hand, Tor has built a self-sustaining community of volunteers who +donate their time and resources. This community trust is rooted in Tor's +open design: we tell the world exactly how Tor works, and we provide all +the source code. Users can decide for themselves, or pay any security +expert to decide, whether it is safe to use. Further, Tor's modularity +as described above, along with its open license, mean that its impact +will continue to grow. + +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{\url{https://www.torproject.org/overview%7D%7D +and they can +only achieve their security goals by blending together in the same +network~\cite{econymics,usability:weis2006}. This user base also provides +something else: hundreds of thousands of different and often-changing +addresses that we can leverage for our blocking-resistance design. + +Finally and perhaps most importantly, Tor provides anonymity and prevents any +single relay from linking users to their communication partners. Despite +initial appearances, {\it distributed-trust anonymity is critical for +anti-censorship efforts}. If any single relay can expose dissident bloggers +or compile a list of users' behavior, the censors can profitably compromise +that relay's operator, perhaps by applying economic pressure to their +employers, +breaking into their computer, pressuring their family (if they have relatives +in the censored area), or so on. Furthermore, in designs where any relay can +expose its users, the censors can spread suspicion that they are running some +of the relays and use this belief to chill use of the network. + +We discuss and adapt these components further in +Section~\ref{sec:bridges}. But first we examine the strengths and +weaknesses of other blocking-resistance approaches, so we can expand +our repertoire of building blocks and ideas. + +\section{Current proxy solutions} +\label{sec:related} + +Relay-based blocking-resistance schemes generally have two main +components: a relay component and a discovery component. The relay part +encompasses the process of establishing a connection, sending traffic +back and forth, and so on---everything that's done once the user knows +where she's going to connect. Discovery is the step before that: the +process of finding one or more usable relays. + +For example, we can divide the pieces of Tor in the previous section +into the process of building paths and sending +traffic over them (relay) and the process of learning from the directory +authorities about what routers are available (discovery). With this +distinction +in mind, we now examine several categories of relay-based schemes. + +\subsection{Centrally-controlled shared proxies} + +Existing commercial anonymity solutions (like Anonymizer.com) are based +on a set of single-hop proxies. In these systems, each user connects to +a single proxy, which then relays traffic between the user and her +destination. These public proxy +systems are typically characterized by two features: they control and +operate the proxies centrally, and many different users get assigned +to each proxy. + +In terms of the relay component, single proxies provide weak security +compared to systems that distribute trust over multiple relays, since a +compromised proxy can trivially observe all of its users' actions, and +an eavesdropper only needs to watch a single proxy to perform timing +correlation attacks against all its users' traffic and thus learn where +everyone is connecting. Worse, all users +need to trust the proxy company to have good security itself as well as +to not reveal user activities. + +On the other hand, single-hop proxies are easier to deploy, and they +can provide better performance than distributed-trust designs like Tor, +since traffic only goes through one relay. They're also more convenient +from the user's perspective---since users entirely trust the proxy, +they can just use their web browser directly. + +Whether public proxy schemes are more or less scalable than Tor is +still up for debate: commercial anonymity systems can use some of their +revenue to provision more bandwidth as they grow, whereas volunteer-based +anonymity systems can attract thousands of fast relays to spread the load. + +The discovery piece can take several forms. Most commercial anonymous +proxies have one or a handful of commonly known websites, and their users +log in to those websites and relay their traffic through them. When +these websites get blocked (generally soon after the company becomes +popular), if the company cares about users in the blocked areas, they +start renting lots of disparate IP addresses and rotating through them +as they get blocked. They notify their users of new addresses (by email, +for example). It's an arms race, since attackers can sign up to receive the +email too, but operators have one nice trick available to them: because they +have a list of paying subscribers, they can notify certain subscribers +about updates earlier than others. + +Access control systems on the proxy let them provide service only to +users with certain characteristics, such as paying customers or people +from certain IP address ranges. + +Discovery in the face of a government-level firewall is a complex and +unsolved +topic, and we're stuck in this same arms race ourselves; we explore it +in more detail in Section~\ref{sec:discovery}. But first we examine the +other end of the spectrum---getting volunteers to run the proxies, +and telling only a few people about each proxy. + +\subsection{Independent personal proxies} + +Personal proxies such as Circumventor~\cite{circumventor} and +CGIProxy~\cite{cgiproxy} use the same technology as the public ones as +far as the relay component goes, but they use a different strategy for +discovery. Rather than managing a few centralized proxies and constantly +getting new addresses for them as the old addresses are blocked, they +aim to have a large number of entirely independent proxies, each managing +its own (much smaller) set of users. + +As the Circumventor site explains, ``You don't +actually install the Circumventor \emph{on} the computer that is blocked +from accessing Web sites. You, or a friend of yours, has to install the +Circumventor on some \emph{other} machine which is not censored.'' + +This tactic has great advantages in terms of blocking-resistance---recall +our assumption in Section~\ref{sec:adversary} that the attention +a system attracts from the attacker is proportional to its number of +users and level of publicity. If each proxy only has a few users, and +there is no central list of proxies, most of them will never get noticed by +the censors. + +On the other hand, there's a huge scalability question that so far has +prevented these schemes from being widely useful: how does the fellow +in China find a person in Ohio who will run a Circumventor for him? In +some cases he may know and trust some people on the outside, but in many +cases he's just out of luck. Just as hard, how does a new volunteer in +Ohio find a person in China who needs it? + +% another key feature of a proxy run by your uncle is that you +% self-censor, so you're unlikely to bring abuse complaints onto +% your uncle. self-censoring clearly has a downside too, though. + +This challenge leads to a hybrid design---centrally-distributed +personal proxies---which we will investigate in more detail in +Section~\ref{sec:discovery}. + +\subsection{Open proxies} + +Yet another currently used approach to bypassing firewalls is to locate +open and misconfigured proxies on the Internet. A quick Google search +for ``open proxy list'' yields a wide variety of freely available lists +of HTTP, HTTPS, and SOCKS proxies. Many small companies have sprung up +providing more refined lists to paying customers. + +There are some downsides to using these open proxies though. First, +the proxies are of widely varying quality in terms of bandwidth and +stability, and many of them are entirely unreachable. Second, unlike +networks of volunteers like Tor, the legality of routing traffic through +these proxies is questionable: it's widely believed that most of them +don't realize what they're offering, and probably wouldn't allow it if +they realized. Third, in many cases the connection to the proxy is +unencrypted, so firewalls that filter based on keywords in IP packets +will not be hindered. Fourth, in many countries (including China), the +firewall authorities hunt for open proxies as well, to preemptively +block them. And last, many users are suspicious that some +open proxies are a little \emph{too} convenient: are they run by the +adversary, in which case they get to monitor all the user's requests +just as single-hop proxies can? + +A distributed-trust design like Tor resolves each of these issues for +the relay component, but a constantly changing set of thousands of open +relays is clearly a useful idea for a discovery component. For example, +users might be able to make use of these proxies to bootstrap their +first introduction into the Tor network. + +\subsection{Blocking resistance and JAP} + +K"{o}psell and Hilling's Blocking Resistance +design~\cite{koepsell:wpes2004} is probably +the closest related work, and is the starting point for the design in this +paper. In this design, the JAP anonymity system~\cite{web-mix} is used +as a base instead of Tor. Volunteers operate a large number of access +points that relay traffic to the core JAP +network, which in turn anonymizes users' traffic. The software to run these +relays is, as in our design, included in the JAP client software and enabled +only when the user decides to enable it. Discovery is handled with a +CAPTCHA-based mechanism; users prove that they aren't an automated process, +and are given the address of an access point. (The problem of a determined +attacker with enough manpower to launch many requests and enumerate all the +access points is not considered in depth.) There is also some suggestion +that information about access points could spread through existing social +networks. + +\subsection{Infranet} + +The Infranet design~\cite{infranet} uses one-hop relays to deliver web +content, but disguises its communications as ordinary HTTP traffic. Requests +are split into multiple requests for URLs on the relay, which then encodes +its responses in the content it returns. The relay needs to be an actual +website with plausible content and a number of URLs which the user might want +to access---if the Infranet software produced its own cover content, it would +be far easier for censors to identify. To keep the censors from noticing +that cover content changes depending on what data is embedded, Infranet needs +the cover content to have an innocuous reason for changing frequently: the +paper recommends watermarked images and webcams. + +The attacker and relay operators in Infranet's threat model are significantly +different than in ours. Unlike our attacker, Infranet's censor can't be +bypassed with encrypted traffic (presumably because the censor blocks +encrypted traffic, or at least considers it suspicious), and has more +computational resources to devote to each connection than ours (so it can +notice subtle patterns over time). Unlike our bridge operators, Infranet's +operators (and users) have more bandwidth to spare; the overhead in typical +steganography schemes is far higher than Tor's. + +The Infranet design does not include a discovery element. Discovery, +however, is a critical point: if whatever mechanism allows users to learn +about relays also allows the censor to do so, he can trivially discover and +block their addresses, even if the steganography would prevent mere traffic +observation from revealing the relays' addresses. + +\subsection{RST-evasion and other packet-level tricks} + +In their analysis of China's firewall's content-based blocking, Clayton, +Murdoch and Watson discovered that rather than blocking all packets in a TCP +streams once a forbidden word was noticed, the firewall was simply forging +RST packets to make the communicating parties believe that the connection was +closed~\cite{clayton:pet2006}. They proposed altering operating systems +to ignore forged RST packets. This approach might work in some cases, but +in practice it appears that many firewalls start filtering by IP address +once a sufficient number of RST packets have been sent. + +Other packet-level responses to filtering include splitting +sensitive words across multiple TCP packets, so that the censors' +firewalls can't notice them without performing expensive stream +reconstruction~\cite{ptacek98insertion}. This technique relies on the +same insight as our weak steganography assumption. + +%\subsection{Internal caching networks} + +%Freenet~\cite{freenet-pets00} is an anonymous peer-to-peer data store. +%Analyzing Freenet's security can be difficult, as its design is in flux as +%new discovery and routing mechanisms are proposed, and no complete +%specification has (to our knowledge) been written. Freenet servers relay +%requests for specific content (indexed by a digest of the content) +%``toward'' the server that hosts it, and then cache the content as it +%follows the same path back to +%the requesting user. If Freenet's routing mechanism is successful in +%allowing nodes to learn about each other and route correctly even as some +%node-to-node links are blocked by firewalls, then users inside censored areas +%can ask a local Freenet server for a piece of content, and get an answer +%without having to connect out of the country at all. Of course, operators of +%servers inside the censored area can still be targeted, and the addresses of +%external servers can still be blocked. + +%\subsection{Skype} + +%The popular Skype voice-over-IP software uses multiple techniques to tolerate +%restrictive networks, some of which allow it to continue operating in the +%presence of censorship. By switching ports and using encryption, Skype +%attempts to resist trivial blocking and content filtering. Even if no +%encryption were used, it would still be expensive to scan all voice +%traffic for sensitive words. Also, most current keyloggers are unable to +%store voice traffic. Nevertheless, Skype can still be blocked, especially at +%its central login server. + +%*sjmurdoch* "we consider the login server to be the only central component in +%the Skype p2p network." +%*sjmurdoch* http://www1.cs.columbia.edu/~salman/publications/skype1_4.pdf +%-> *sjmurdoch* ok. what is the login server's role? +%-> *sjmurdoch* and do you need to reach it directly to use skype? +%*sjmurdoch* It checks the username and password +%*sjmurdoch* It is necessary in the current implementation, but I don't know if +%it is a fundemental limitation of the architecture + +\subsection{Tor itself} + +And last, we include Tor itself in the list of current solutions +to firewalls. Tens of thousands of people use Tor from countries that +routinely filter their Internet. Tor's website has been blocked in most +of them. But why hasn't the Tor network been blocked yet? + +We have several theories. The first is the most straightforward: tens of +thousands of people are simply too few to matter. It may help that Tor is +perceived to be for experts only, and thus not worth attention yet. The +more subtle variant on this theory is that we've positioned Tor in the +public eye as a tool for retaining civil liberties in more free countries, +so perhaps blocking authorities don't view it as a threat. (We revisit +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 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 +be ways for a few people to get around the firewall, and as long as Tor +has not publically threatened their control, they see no urgent need to +block it yet. + +We should recognize that we're \emph{already} in the arms race. These +constraints can give us insight into the priorities and capabilities of +our various attackers. + +\section{The relay component of our blocking-resistant design} +\label{sec:bridges} + +Section~\ref{sec:current-tor} describes many reasons why Tor is +well-suited as a building block in our context, but several changes will +allow the design to resist blocking better. The most critical changes are +to get more relay addresses, and to distribute them to users differently. + +%We need to address three problems: +%- adapting the relay component of Tor so it resists blocking better. +%- Discovery. +%- Tor's network fingerprint. + +%Here we describe the new pieces we need to add to the current Tor design. + +\subsection{Bridge relays} + +Today, Tor relays operate on a few thousand distinct IP addresses; +an adversary +could enumerate and block them all with little trouble. To provide a +means of ingress to the network, we need a larger set of entry points, most +of which an adversary won't be able to enumerate easily. Fortunately, we +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 +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 +nothing for a broadband user in a free country, but plenty for a user +who otherwise has no access at all), and since they are just relaying +bytes back and forth between blocked users and the main Tor network, they +won't need to make any external connections to Internet sites. Because +of this separation of roles, and because we're making use of software +that the volunteers have already installed for their own use, we expect +our scheme to attract and maintain more volunteers than previous schemes. + +As usual, there are new anonymity and security implications from running a +bridge relay, particularly from letting people relay traffic through your +Tor client; but we leave this discussion for Section~\ref{sec:security}. + +%...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} + +How do the bridge relays advertise their existence to the world? We +introduce a second new component of the design: a specialized directory +authority that aggregates and tracks bridges. Bridge relays periodically +publish relay descriptors (summaries of their keys, locations, etc, +signed by their long-term identity key), just like the relays in the +``main'' Tor network, but in this case they publish them only to the +bridge directory authorities. + +The main difference between bridge authorities and the directory +authorities for the main Tor network is that the main authorities provide +a list of every known relay, but the bridge authorities only give +out a relay descriptor if you already know its identity key. That is, +you can keep up-to-date on a bridge's location and other information +once you know about it, but you can't just grab a list of all the bridges. + +The identity key, IP address, and directory port for each bridge +authority ship by default with the Tor software, so the bridge relays +can be confident they're publishing to the right location, and the +blocked users can establish an encrypted authenticated channel. See +Section~\ref{subsec:trust-chain} for more discussion of the public key +infrastructure and trust chain. + +Bridges use Tor to publish their descriptors privately and securely, +so even an attacker monitoring the bridge directory authority's network +can't make a list of all the addresses contacting the authority. +Bridges may publish to only a subset of the +authorities, to limit the potential impact of an authority compromise. + + +%\subsection{A simple matter of engineering} +% +%Although we've described bridges and bridge authorities in simple terms +%above, some design modifications and features are needed in the Tor +%codebase to add them. We describe the four main changes here. +% +%Firstly, we need to get smarter about rate limiting: +%Bandwidth classes +% +%Secondly, while users can in fact configure which directory authorities +%they use, we need to add a new type of directory authority and teach +%bridges to fetch directory information from the main authorities while +%publishing relay descriptors to the bridge authorities. We're most of +%the way there, since we can already specify attributes for directory +%authorities: +%add a separate flag named ``blocking''. +% +%Thirdly, need to build paths using bridges as the first +%hop. One more hole in the non-clique assumption. +% +%Lastly, since bridge authorities don't answer full network statuses, +%we need to add a new way for users to learn the current status for a +%single relay or a small set of relays---to answer such questions as +%``is it running?'' or ``is it behaving correctly?'' We describe in +%Section~\ref{subsec:enclave-dirs} a way for the bridge authority to +%publish this information without resorting to signing each answer +%individually. + +\subsection{Putting them together} +\label{subsec:relay-together} + +If a blocked user knows the identity keys of a set of bridge relays, and +he has correct address information for at least one of them, he can use +that one to make a secure connection to the bridge authority and update +his knowledge about the other bridge relays. He can also use it to make +secure connections to the main Tor network and directory authorities, so he +can build circuits and connect to the rest of the Internet. All of these +updates happen in the background: from the blocked user's perspective, +he just accesses the Internet via his Tor client like always. + +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. + +There's another catch though. We need to make sure that the network +traffic we generate by simply connecting to a bridge relay doesn't stand +out too much. + +%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. + +% (See Section~\ref{subsec:first-bridge} for a discussion +%of exactly what information is sufficient to characterize a bridge relay.) + + + +\section{Hiding Tor's network fingerprint} +\label{sec:network-fingerprint} +\label{subsec:enclave-dirs} + +Currently, Tor uses two protocols for its network communications. The +main protocol uses TLS for encrypted and authenticated communication +between Tor instances. The second protocol is standard HTTP, used for +fetching directory information. All Tor relays listen on their ``ORPort'' +for TLS connections, and some of them opt to listen on their ``DirPort'' +as well, to serve directory information. Tor relays choose whatever port +numbers they like; the relay descriptor they publish to the directory +tells users where to connect. + +One format for communicating address information about a bridge relay is +its IP address and DirPort. From there, the user can ask the bridge's +directory cache for an up-to-date copy of its relay descriptor, and +learn its current circuit keys, its ORPort, and so on. + +However, connecting directly to the directory cache involves a plaintext +HTTP request. A censor could create a network fingerprint (known as a +\emph{signature} in the intrusion detection field) for the request +and/or its response, thus preventing these connections. To resolve this +vulnerability, we've modified the Tor protocol so that users can connect +to the directory cache via the main Tor port---they establish a TLS +connection with the bridge as normal, and then send a special ``begindir'' +relay command to establish an internal connection to its directory cache. + +Therefore a better way to summarize a bridge's address is by its IP +address and ORPort, so all communications between the client and the +bridge will use ordinary TLS. But there are other details that need +more investigation. + +What port should bridges pick for their ORPort? We currently recommend +that they listen on port 443 (the default HTTPS port) if they want to +be most useful, because clients behind standard firewalls will have +the best chance to reach them. Is this the best choice in all cases, +or should we encourage some fraction of them pick random ports, or other +ports commonly permitted through firewalls like 53 (DNS) or 110 +(POP)? Or perhaps we should use other ports where TLS traffic is +expected, like 993 (IMAPS) or 995 (POP3S). We need more research on our +potential users, and their current and anticipated firewall restrictions. + +Furthermore, we need to look at the specifics of Tor's TLS handshake. +Right now Tor uses some predictable strings in its TLS handshakes. For +example, it sets the X.509 organizationName field to ``Tor'', and it puts +the Tor relay's nickname in the certificate's commonName field. We +should tweak the handshake protocol so it doesn't rely on any unusual details +in the certificate, yet it remains secure; the certificate itself +should be made to resemble an ordinary HTTPS certificate. We should also try +to make our advertised cipher-suites closer to what an ordinary web server +would support. + +Tor's TLS handshake uses two-certificate chains: one certificate +contains the self-signed identity key for +the router, and the second contains a current TLS key, signed by the +identity key. We use these to authenticate that we're talking to the right +router, and to limit the impact of TLS-key exposure. Most (though far from +all) consumer-oriented HTTPS services provide only a single certificate. +These extra certificates may help identify Tor's TLS handshake; instead, +bridges should consider using only a single TLS key certificate signed by +their identity key, and providing the full value of the identity key in an +early handshake cell. More significantly, Tor currently has all clients +present certificates, so that clients are harder to distinguish from relays. +But in a blocking-resistance environment, clients should not present +certificates at all. + +Last, what if the adversary starts observing the network traffic even +more closely? Even if our TLS handshake looks innocent, our traffic timing +and volume still look different than a user making a secure web connection +to his bank. The same techniques used in the growing trend to build tools +to recognize encrypted Bittorrent traffic +%~\cite{bt-traffic-shaping} +could be used to identify Tor communication and recognize bridge +relays. Rather than trying to look like encrypted web traffic, we may be +better off trying to blend with some other encrypted network protocol. The +first step is to compare typical network behavior for a Tor client to +typical network behavior for various other protocols. This statistical +cat-and-mouse game is made more complex by the fact that Tor transports a +variety of protocols, and we'll want to automatically handle web browsing +differently from, say, instant messaging. + +% Tor cells are 512 bytes each. So TLS records will be roughly +% multiples of this size? How bad is this? -RD +% Look at ``Inferring the Source of Encrypted HTTP Connections'' +% by Marc Liberatore and Brian Neil Levine (CCS 2006) +% They substantially flesh out the numbers for the web fingerprinting +% attack. -PS +% Yes, but I meant detecting the fingerprint of Tor traffic itself, not +% learning what websites we're going to. I wouldn't be surprised to +% 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 +local spoofing attacks? That is, since we never learned an identity +key fingerprint for the bridge, a local attacker could intercept our +connection and pretend to be the bridge we had in mind. It turns out +that giving false information isn't that bad---since the Tor client +ships with trusted keys for the bridge directory authority and the Tor +network directory authorities, the user can learn whether he's being +given a real connection to the bridge authorities or not. (After all, +if the adversary intercepts every connection the user makes and gives +him a bad connection each time, there's nothing we can do.) + +What about anonymity-breaking attacks from observing traffic, if the +blocked user doesn't start out knowing the identity key of his intended +bridge? The vulnerabilities aren't so bad in this case either---the +adversary could do similar attacks just by monitoring the network +traffic. +% cue paper by steven and george + +Once the Tor client has fetched the bridge's relay descriptor, it should +remember the identity key fingerprint for that bridge relay. Thus if +the bridge relay moves to a new IP address, the client can query the +bridge directory authority to look up a fresh relay descriptor using +this fingerprint. + +So we've shown that it's \emph{possible} to bootstrap into the network +just by learning the IP address and ORPort of a bridge, but are there +situations where it's more convenient or more secure to learn the bridge's +identity fingerprint as well as instead, while bootstrapping? We keep +that question in mind as we next investigate bootstrapping and discovery. + +\section{Discovering working bridge relays} +\label{sec:discovery} + +Tor's modular design means that we can develop a better relay component +independently of developing the discovery component. This modularity's +great promise is that we can pick any discovery approach we like; but the +unfortunate fact is that we have no magic bullet for discovery. We're +in the same arms race as all the other designs we described in +Section~\ref{sec:related}. + +In this section we describe a variety of approaches to adding discovery +components for our design. + +\subsection{Bootstrapping: finding your first bridge.} +\label{subsec:first-bridge} + +In Section~\ref{subsec:relay-together}, we showed that a user who knows +a working bridge address can use it to reach the bridge authority and +to stay connected to the Tor network. But how do new users reach the +bridge authority in the first place? After all, the bridge authority +will be one of the first addresses that a censor blocks. + +First, we should recognize that most government firewalls are not +perfect. That is, they may allow connections to Google cache or some +open proxy servers, or they let file-sharing traffic, Skype, instant +messaging, or World-of-Warcraft connections through. Different users will +have different mechanisms for bypassing the firewall initially. Second, +we should remember that most people don't operate in a vacuum; users will +hopefully know other people who are in other situations or have other +resources available. In the rest of this section we develop a toolkit +of different options and mechanisms, so that we can enable users in a +diverse set of contexts to bootstrap into the system. + +(For users who can't use any of these techniques, hopefully they know +a friend who can---for example, perhaps the friend already knows some +bridge relay addresses. If they can't get around it at all, then we +can't help them---they should go meet more people or learn more about +the technology running the firewall in their area.) + +By deploying all the schemes in the toolkit at once, we let bridges and +blocked users employ the discovery approach that is most appropriate +for their situation. + +\subsection{Independent bridges, no central discovery} + +The first design is simply to have no centralized discovery component at +all. Volunteers run bridges, and we assume they have some blocked users +in mind and communicate their address information to them out-of-band +(for example, through Gmail). This design allows for small personal +bridges that have only one or a handful of users in mind, but it can +also support an entire community of users. For example, Citizen Lab's +upcoming Psiphon single-hop proxy tool~\cite{psiphon} plans to use this +\emph{social network} approach as its discovery component. + +There are several ways to do bootstrapping in this design. In the simple +case, the operator of the bridge informs each chosen user about his +bridge's address information and/or keys. A different approach involves +blocked users introducing new blocked users to the bridges they know. +That is, somebody in the blocked area can pass along a bridge's address to +somebody else they trust. This scheme brings in appealing but complex game +theoretic properties: the blocked user making the decision has an incentive +only to delegate to trustworthy people, since an adversary who learns +the bridge's address and filters it makes it unavailable for both of them. +Also, delegating known bridges to members of your social network can be +dangerous: an the adversary who can learn who knows which bridges may +be able to reconstruct the social network. + +Note that a central set of bridge directory authorities can still be +compatible with a decentralized discovery process. That is, how users +first learn about bridges is entirely up to the bridges, but the process +of fetching up-to-date descriptors for them can still proceed as described +in Section~\ref{sec:bridges}. Of course, creating a central place that +knows about all the bridges may not be smart, especially if every other +piece of the system is decentralized. Further, if a user only knows +about one bridge and he loses track of it, it may be quite a hassle to +reach the bridge authority. We address these concerns next. + +\subsection{Families of bridges, no central discovery} + +Because the blocked users are running our software too, we have many +opportunities to improve usability or robustness. Our second design builds +on the first by encouraging volunteers to run several bridges at once +(or coordinate with other bridge volunteers), such that some +of the bridges are likely to be available at any given time. + +The blocked user's Tor client would periodically fetch an updated set of +recommended bridges from any of the working bridges. Now the client can +learn new additions to the bridge pool, and can expire abandoned bridges +or bridges that the adversary has blocked, without the user ever needing +to care. To simplify maintenance of the community's bridge pool, each +community could run its own bridge directory authority---reachable via +the available bridges, and also mirrored at each bridge. + +\subsection{Public bridges with central discovery} + +What about people who want to volunteer as bridges but don't know any +suitable blocked users? What about people who are blocked but don't +know anybody on the outside? Here we describe how to make use of these +\emph{public bridges} in a way that still makes it hard for the attacker +to learn all of them. + +The basic idea is to divide public bridges into a set of pools based on +identity key. Each pool corresponds to a \emph{distribution strategy}: +an approach to distributing its bridge addresses to users. Each strategy +is designed to exercise a different scarce resource or property of +the user. + +How do we divide bridges between these strategy pools such that they're +evenly distributed and the allocation is hard to influence or predict, +but also in a way that's amenable to creating more strategies later +on without reshuffling all the pools? We assign a given bridge +to a strategy pool by hashing the bridge's identity key along with a +secret that only the bridge authority knows: the first $n$ bits of this +hash dictate the strategy pool number, where $n$ is a parameter that +describes how many strategy pools we want at this point. We choose $n=3$ +to start, so we divide bridges between 8 pools; but as we later invent +new distribution strategies, we can increment $n$ to split the 8 into +16. Since a bridge can't predict the next bit in its hash, it can't +anticipate which identity key will correspond to a certain new pool +when the pools are split. Further, since the bridge authority doesn't +provide any feedback to the bridge about which strategy pool it's in, +an adversary who signs up bridges with the goal of filling a certain +pool~\cite{casc-rep} will be hindered. + +% This algorithm is not ideal. When we split pools, each existing +% pool is cut in half, where half the bridges remain with the +% old distribution policy, and half will be under what the new one +% is. So the new distribution policy inherits a bunch of blocked +% bridges if the old policy was too loose, or a bunch of unblocked +% bridges if its policy was still secure. -RD +% +% I think it should be more chordlike. +% Bridges are allocated to wherever on the ring which is divided +% into arcs (buckets). +% If a bucket gets too full, you can just split it. +% More on this below. -PFS + +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 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 +user arrives, but to learn about all bridges the attacker needs to fetch +all new addresses at every new time slot. By varying the length of the +time slots, we can make it harder for the attacker to guess when to check +back. We expect these bridges will be the first to be blocked, but they'll +help the system bootstrap until they \emph{do} get blocked. Further, +remember that we're dealing with different blocking regimes around the +world that will progress at different rates---so this pool will still +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 requester's IP address +with a secret of its own (as in the above allocation scheme for creating +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 +large attacker like China will still be able to control many addresses, +but the hassle of establishing connections from each network (or spoofing +TCP connections) may still slow them down. Similarly, as a special case, +we should treat IP addresses that are Tor exit nodes as all being on +the same network. + +The third strategy combines the time-based and location-based +strategies to further constrain and rate-limit the available bridge +addresses. Specifically, the bridge address provided in a given time +slot to a given network location is deterministic within the partition, +rather than chosen randomly each time from the partition. Thus, repeated +requests during that time slot from a given network are given the same +bridge address as the first request. + +The fourth strategy is based on Circumventor's discovery strategy. +The Circumventor project, realizing that its adoption will remain limited +if it has no central coordination mechanism, has started a mailing list to +distribute new proxy addresses every few days. From experimentation it +seems they have concluded that sending updates every three or four days +is sufficient to stay ahead of the current attackers. + +The fifth strategy provides an alternative approach to a mailing list: +users provide an email address and receive an automated response +listing an available bridge address. We could limit one response per +email address. To further rate limit queries, we could require a CAPTCHA +solution +%~\cite{captcha} +in each case too. In fact, we wouldn't need to +implement the CAPTCHA on our side: if we only deliver bridge addresses +to Yahoo or GMail addresses, we can leverage the rate-limiting schemes +that other parties already impose for account creation. + +The sixth strategy ties in the social network design with public +bridges and a reputation system. We pick some seeds---trusted people in +blocked areas---and give them each a few dozen bridge addresses and a few +\emph{delegation tokens}. We run a website next to the bridge authority, +where users can log in (they connect via Tor, and they don't need to +provide actual identities, just persistent pseudonyms). Users can delegate +trust to other people they know by giving them a token, which can be +exchanged for a new account on the website. Accounts in ``good standing'' +then accrue new bridge addresses and new tokens. As usual, reputation +schemes bring in a host of new complexities~\cite{rep-anon}: how do we +decide that an account is in good standing? We could tie reputation +to whether the bridges they're told about have been blocked---see +Section~\ref{subsec:geoip} below for initial thoughts on how to discover +whether bridges have been blocked. We could track reputation between +accounts (if you delegate to somebody who screws up, it impacts you too), +or we could use blinded delegation tokens~\cite{chaum-blind} to prevent +the website from mapping the seeds' social network. We put off deeper +discussion of the social network reputation strategy for future work. + +Pools seven and eight are held in reserve, in case our currently deployed +tricks all fail at once and the adversary blocks all those bridges---so +we can adapt and move to new approaches quickly, and have some bridges +immediately available for the new schemes. New strategies might be based +on some other scarce resource, such as relaying traffic for others or +other proof of energy spent. (We might also worry about the incentives +for bridges that sign up and get allocated to the reserve pools: will they +be unhappy that they're not being used? But this is a transient problem: +if Tor users are bridges by default, nobody will mind not being used yet. +See also Section~\ref{subsec:incentives}.) + +%Is it useful to load balance which bridges are handed out? The above +%pool concept makes some bridges wildly popular and others less so. +%But I guess that's the point. + +\subsection{Public bridges with coordinated discovery} + +We presented the above discovery strategies in the context of a single +bridge directory authority, but in practice we will want to distribute the +operations over several bridge authorities---a single point of failure +or attack is a bad move. The first answer is to run several independent +bridge directory authorities, and bridges gravitate to one based on +their identity key. The better answer would be some federation of bridge +authorities that work together to provide redundancy but don't introduce +new security issues. We could even imagine designs where the bridge +authorities have encrypted versions of the bridge's relay descriptors, +and the users learn a decryption key that they keep private when they +first hear about the bridge---this way the bridge authorities would not +be able to learn the IP address of the bridges. + +We leave this design question for future work. + +\subsection{Assessing whether bridges are useful} + +Learning whether a bridge is useful is important in the bridge authority's +decision to include it in responses to blocked users. For example, if +we end up with a list of thousands of bridges and only a few dozen of +them are reachable right now, most blocked users will not end up knowing +about working bridges. + +There are three components for assessing how useful a bridge is. First, +is it reachable from the public Internet? Second, what proportion of +the time is it available? Third, is it blocked in certain jurisdictions? + +The first component can be tested just as we test reachability of +ordinary Tor relays. Specifically, the bridges do a self-test---connect +to themselves via the Tor network---before they are willing to +publish their descriptor, to make sure they're not obviously broken or +misconfigured. Once the bridges publish, the bridge authority also tests +reachability to make sure they're not confused or outright lying. + +The second component can be measured and tracked by the bridge authority. +By doing periodic reachability tests, we can get a sense of how often the +bridge is available. More complex tests will involve bandwidth-intensive +checks to force the bridge to commit resources in order to be counted as +available. We need to evaluate how the relationship of uptime percentage +should weigh into our choice of which bridges to advertise. We leave +this to future work. + +The third component is perhaps the trickiest: with many different +adversaries out there, how do we keep track of which adversaries have +blocked which bridges, and how do we learn about new blocks as they +occur? We examine this problem next. + +\subsection{How do we know if a bridge relay has been blocked?} +\label{subsec:geoip} + +There are two main mechanisms for testing whether bridges are reachable +from inside each blocked area: active testing via users, and passive +testing via bridges. + +In the case of active testing, certain users inside each area +sign up as testing relays. The bridge authorities can then use a +Blossom-like~\cite{blossom-thesis} system to build circuits through them +to each bridge and see if it can establish the connection. But how do +we pick the users? If we ask random users to do the testing (or if we +solicit volunteers from the users), the adversary should sign up so he +can enumerate the bridges we test. Indeed, even if we hand-select our +testers, the adversary might still discover their location and monitor +their network activity to learn bridge addresses. + +Another answer is not to measure directly, but rather let the bridges +report whether they're being used. +%If they periodically report to their +%bridge directory authority how much use they're seeing, perhaps the +%authority can make smart decisions from there. +Specifically, bridges should install a GeoIP database such as the public +IP-To-Country list~\cite{ip-to-country}, and then periodically report to the +bridge authorities which countries they're seeing use from. This data +would help us track which countries are making use of the bridge design, +and can also let us learn about new steps the adversary has taken in +the arms race. (The compressed GeoIP database is only several hundred +kilobytes, and we could even automate the update process by serving it +from the bridge authorities.) +More analysis of this passive reachability +testing design is needed to resolve its many edge cases: for example, +if a bridge stops seeing use from a certain area, does that mean the +bridge is blocked or does that mean those users are asleep? + +There are many more problems with the general concept of detecting whether +bridges are blocked. First, different zones of the Internet are blocked +in different ways, and the actual firewall jurisdictions do not match +country borders. Our bridge scheme could help us map out the topology +of the censored Internet, but this is a huge task. More generally, +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 somewhere in between? And last, an attacker could poison our +bridge database by signing up already-blocked bridges. In this case, +if we're stingy giving out bridge addresses, users in that country won't +learn working bridges. + +All of these issues are made more complex when we try to integrate this +testing into our social network reputation system above. +Since in that case we punish or reward users based on whether bridges +get blocked, the adversary has new attacks to trick or bog down the +reputation tracking. Indeed, the bridge authority doesn't even know +what zone the blocked user is in, so do we blame him for any possible +censored zone, or what? + +Clearly more analysis is required. The eventual solution will probably +involve a combination of passive measurement via GeoIP and active +measurement from trusted testers. More generally, we can use the passive +feedback mechanism to track usage of the bridge network as a whole---which +would let us respond to attacks and adapt the design, and it would also +let the general public track the progress of the project. + +%Worry: the adversary could choose not to block bridges but just record +%connections to them. So be it, I guess. + +\subsection{Advantages of deploying all solutions at once} + +For once, we're not in the position of the defender: we don't have to +defend against every possible filtering scheme; we just have to defend +against at least one. On the flip side, the attacker is forced to guess +how to allocate his resources to defend against each of these discovery +strategies. So by deploying all of our strategies at once, we not only +increase our chances of finding one that the adversary has difficulty +blocking, but we actually make \emph{all} of the strategies more robust +in the face of an adversary with limited resources. + +%\subsection{Remaining unsorted notes} + +%In the first subsection we describe how to find a first bridge. + +%Going to be an arms race. Need a bag of tricks. Hard to say +%which ones will work. Don't spend them all at once. + +%Some techniques are sufficient to get us an IP address and a port, +%and others can get us IP:port:key. Lay out some plausible options +%for how users can bootstrap into learning their first bridge. + +%\section{The account / reputation system} +%\section{Social networks with directory-side support} +%\label{sec:accounts} + +%One answer is to measure based on whether the bridge addresses +%we give it end up blocked. But how do we decide if they get blocked? + +%Perhaps each bridge should be known by a single bridge directory +%authority. This makes it easier to trace which users have learned about +%it, so easier to blame or reward. It also makes things more brittle, +%since loss of that authority means its bridges aren't advertised until +%they switch, and means its bridge users are sad too. +%(Need a slick hash algorithm that will map our identity key to a +%bridge authority, in a way that's sticky even when we add bridge +%directory authorities, but isn't sticky when our authority goes +%away. Does this exist?) +% [[Ian says: What about just using something like hash table chaining? +% This should work, so long as the client knows which authorities currently +% exist.]] + +%\subsection{Discovery based on social networks} + +%A token that can be exchanged at the bridge authority (assuming you +%can reach it) for a new bridge address. + +%The account server runs as a Tor controller for the bridge authority. + +%Users can establish reputations, perhaps based on social network +%connectivity, perhaps based on not getting their bridge relays blocked, + +%Probably the most critical lesson learned in past work on reputation +%systems in privacy-oriented environments~\cite{rep-anon} is the need for +%verifiable transactions. That is, the entity computing and advertising +%reputations for participants needs to actually learn in a convincing +%way that a given transaction was successful or unsuccessful. + +%(Lesson from designing reputation systems~\cite{rep-anon}: easy to +%reward good behavior, hard to punish bad behavior. + +\section{Security considerations} +\label{sec:security} + +\subsection{Possession of Tor in oppressed areas} + +Many people speculate that installing and using a Tor client in areas with +particularly extreme firewalls is a high risk---and the risk increases +as the firewall gets more restrictive. This notion certainly has merit, but +there's +a counter pressure as well: as the firewall gets more restrictive, more +ordinary people behind it end up using Tor for more mainstream activities, +such as learning +about Wall Street prices or looking at pictures of women's ankles. So +as the restrictive firewall pushes up the number of Tor users, the +``typical'' Tor user becomes more mainstream, and therefore mere +use or possession of the Tor software is not so surprising. + +It's hard to say which of these pressures will ultimately win out, +but we should keep both sides of the issue in mind. + +%Nick, want to rewrite/elaborate on this section? + +%Ian suggests: +% Possession of Tor: this is totally of-the-cuff, and there are lots of +% security issues to think about, but what about an ActiveX version of +% Tor? The magic you learn (as opposed to a bridge address) is a plain +% old HTTPS server, which feeds you an ActiveX applet pre-configured with +% some bridge address (possibly on the same machine). For bonus points, +% somehow arrange that (a) the applet is signed in some way the user can +% reliably check, but (b) don't end up with anything like an incriminating +% long-term cert stored on the user's computer. This may be marginally +% useful in some Internet-cafe situations as well, though (a) is even +% harder to get right there. + + +\subsection{Observers can tell who is publishing and who is reading} +\label{subsec:upload-padding} + +Tor encrypts traffic on the local network, and it obscures the eventual +destination of the communication, but it doesn't do much to obscure the +traffic volume. In particular, a user publishing a home video will have a +different network fingerprint than a user reading an online news article. +Based on our assumption in Section~\ref{sec:adversary} that users who +publish material are in more danger, should we work to improve Tor's +security in this situation? + +In the general case this is an extremely challenging task: +effective \emph{end-to-end traffic confirmation attacks} +are known where the adversary observes the origin and the +destination of traffic and confirms that they are part of the +same communication~\cite{danezis:pet2004,e2e-traffic}. Related are +\emph{website fingerprinting attacks}, where the adversary downloads +a few hundred popular websites, makes a set of "fingerprints" for each +site, and then observes the target Tor client's traffic to look for +a match~\cite{pet05-bissias,defensive-dropping}. But can we do better +against a limited adversary who just does coarse-grained sweeps looking +for unusually prolific publishers? + +One answer is for bridge users to automatically send bursts of padding +traffic periodically. (This traffic can be implemented in terms of +long-range drop cells, which are already part of the Tor specification.) +Of course, convincingly simulating an actual human publishing interesting +content is a difficult arms race, but it may be worthwhile to at least +start the race. More research remains. + +\subsection{Anonymity effects from acting as a bridge relay} + +Against some attacks, relaying traffic for others can improve +anonymity. The simplest example is an attacker who owns a small number +of Tor relays. He will see a connection from the bridge, but he won't +be able to know whether the connection originated there or was relayed +from somebody else. More generally, the mere uncertainty of whether the +traffic originated from that user may be helpful. + +There are some cases where it doesn't seem to help: if an attacker can +watch all of the bridge's incoming and outgoing traffic, then it's easy +to learn which connections were relayed and which started there. (In this +case he still doesn't know the final destinations unless he is watching +them too, but in this case bridges are no better off than if they were +an ordinary client.) + +There are also some potential downsides to running a bridge. First, while +we try to make it hard to enumerate all bridges, it's still possible to +learn about some of them, and for some people just the fact that they're +running one might signal to an attacker that they place a higher value +on their anonymity. Second, there are some more esoteric attacks on Tor +relays that are not as well-understood or well-tested---for example, an +attacker may be able to ``observe'' whether the bridge is sending traffic +even if he can't actually watch its network, by relaying traffic through +it and noticing changes in traffic timing~\cite{attack-tor-oak05}. On +the other hand, it may be that limiting the bandwidth the bridge is +willing to relay will allow this sort of attacker to determine if it's +being used as a bridge but not easily learn whether it is adding traffic +of its own. + +We also need to examine how entry guards fit in. Entry guards +(a small set of nodes that are always used for the first +step in a circuit) help protect against certain attacks +where the attacker runs a few Tor relays and waits for +the user to choose these relays as the beginning and end of her +circuit\footnote{\url{http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#EntryGuards%7D%7D. +If the blocked user doesn't use the bridge's entry guards, then the bridge +doesn't gain as much cover benefit. On the other hand, what design changes +are needed for the blocked user to use the bridge's entry guards without +learning what they are (this seems hard), and even if we solve that, +do they then need to use the guards' guards and so on down the line? + +It is an open research question whether the benefits of running a bridge +outweigh the risks. A lot of the decision rests on which attacks the +users are most worried about. For most users, we don't think running a +bridge relay will be that damaging, and it could help quite a bit. + +\subsection{Trusting local hardware: Internet cafes and LiveCDs} +\label{subsec:cafes-and-livecds} + +Assuming that users have their own trusted hardware is not +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 and trustworthy options down the +road. Worries remain about hardware or software keyloggers and other +spyware, as well as 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 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 +easier to avoid leaving private data and logs scattered around the +system. + +%\subsection{Forward compatibility and retiring bridge authorities} +% +%Eventually we'll want to change the identity key and/or location +%of a bridge authority. How do we do this mostly cleanly? + +\subsection{The trust chain} +\label{subsec:trust-chain} + +Tor's ``public key infrastructure'' provides a chain of trust to +let users verify that they're actually talking to the right relays. +There are four pieces to this trust chain. + +First, when Tor clients are establishing circuits, at each step +they demand that the next Tor relay in the path prove knowledge of +its private key~\cite{tor-design}. This step prevents the first node +in the path from just spoofing the rest of the path. Second, the +Tor directory authorities provide a signed list of relays along with +their public keys---so unless the adversary can control a threshold +of directory authorities, he can't trick the Tor client into using other +Tor relays. Third, the location and keys of the directory authorities, +in turn, is hard-coded in the Tor source code---so as long as the user +got a genuine version of Tor, he can know that he is using the genuine +Tor network. And last, the source code and other packages are signed +with the GPG keys of the Tor developers, so users can confirm that they +did in fact download a genuine version of Tor. + +In the case of blocked users contacting bridges and bridge directory +authorities, the same logic applies in parallel: the blocked users fetch +information from both the bridge authorities and the directory authorities +for the `main' Tor network, and they combine this information locally. + +How can a user in an oppressed country know that he has the correct +key fingerprints for the developers? As with other security systems, it +ultimately comes down to human interaction. The keys are signed by dozens +of people around the world, and we have to hope that our users have met +enough people in the PGP web of trust +%~\cite{pgp-wot} +that they can learn +the correct keys. For users that aren't connected to the global security +community, though, this question remains a critical weakness. + +%\subsection{Security through obscurity: publishing our design} + +%Many other schemes like dynaweb use the typical arms race strategy of +%not publishing their plans. Our goal here is to produce a design---a +%framework---that can be public and still secure. Where's the tradeoff? + +%\section{Performance improvements} +%\label{sec:performance} +% +%\subsection{Fetch relay descriptors just-in-time} +% +%I guess we should encourage most places to do this, so blocked +%users don't stand out. +% +% +%network-status and directory optimizations. caching better. partitioning +%issues? + +\section{Maintaining reachability} +\label{sec:reachability} + +\subsection{How many bridge relays should you know about?} + +The strategies described in Section~\ref{sec:discovery} talked about +learning one bridge address at a time. But if most bridges are ordinary +Tor users on cable modem or DSL connection, many of them will disappear +and/or move periodically. How many bridge relays should a blocked user +know about so that she is likely to have at least one reachable at any +given point? This is already a challenging problem if we only consider +natural churn: the best approach is to see what bridges we attract in +reality and measure their churn. We may also need to factor in a parameter +for how quickly bridges get discovered and blocked by the attacker; +we leave this for future work after we have more deployment experience. + +A related question is: if the bridge relays change IP addresses +periodically, how often does the blocked user need to fetch updates in +order to keep from being cut out of the loop? + +Once we have more experience and intuition, we should explore technical +solutions to this problem too. For example, if the discovery strategies +give out $k$ bridge addresses rather than a single bridge address, perhaps +we can improve robustness from the user perspective without significantly +aiding the adversary. Rather than giving out a new random subset of $k$ +addresses at each point, we could bind them together into \emph{bridge +families}, so all users that learn about one member of the bridge family +are told about the rest as well. + +This scheme may also help defend against attacks to map the set of +bridges. That is, if all blocked users learn a random subset of bridges, +the attacker should learn about a few bridges, monitor the country-level +firewall for connections to them, then watch those users to see what +other bridges they use, and repeat. By segmenting the bridge address +space, we can limit the exposure of other users. + +\subsection{Cablemodem users don't usually provide important websites} +\label{subsec:block-cable} + +Another attacker we might be concerned about is that the attacker could +just block all DSL and cablemodem network addresses, on the theory that +they don't run any important services anyway. If most of our bridges +are on these networks, this attack could really hurt. + +The first answer is to aim to get volunteers both from traditionally +``consumer'' networks and also from traditionally ``producer'' networks. +Since bridges don't need to be Tor exit nodes, as we improve our usability +it seems quite feasible to get a lot of websites helping out. + +The second answer (not as practical) would be to encourage more use of +consumer networks for popular and useful Internet services. +%(But P2P exists; +%minor websites exist; gaming exists; IM exists; ...) + +A related attack we might worry about is based on large countries putting +economic pressure on companies that want to expand their business. For +example, what happens if Verizon wants to sell services in China, and +China pressures Verizon to discourage its users in the free world from +running bridges? + +\subsection{Scanning resistance: making bridges more subtle} + +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}, and it goes along with normalizing Tor's TLS handshake and +network fingerprint. + +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 still resist against widespread +scanning. + +How should the bridge behave if accessed without the correct +authorization? Perhaps it should act like an unconfigured HTTPS server +(``welcome to the default Apache page''), or maybe it should mirror +and act like common websites, or websites randomly chosen from Google. + +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). + +% Ian suggests a ``socialist millionaires'' protocol here, for something. + +% Did we once mention knocking here? it's a good idea, but we should clarify +% what we mean. Ian also notes that knocking itself is very fingerprintable, +% and we should beware. + +\subsection{How to motivate people to run bridge relays} +\label{subsec:incentives} + +One of the traditional ways to get people to run software that benefits +others is to give them motivation to install it themselves. An often +suggested approach is to install it as a stunning screensaver so everybody +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. + +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. + +In the mean time, we can make a snazzy network graph with +Vidalia\footnote{\url{http://vidalia-project.net/%7D%7D 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 relay.) + +% Also consider everybody-a-relay. Many of the scalability questions +% are easier when you're talking about making everybody a bridge. + +%\subsection{What if the clients can't install software?} + +%[this section should probably move to the related work section, +%or just disappear entirely.] + +%Bridge users without Tor software + +%Bridge relays could always open their socks proxy. This is bad though, +%first +%because bridges learn the bridge users' destinations, and second because +%we've learned that open socks proxies tend to attract abusive users who +%have no idea they're using Tor. + +%Bridges could require passwords in the socks handshake (not supported +%by most software including Firefox). Or they could run web proxies +%that require authentication and then pass the requests into Tor. This +%approach is probably a good way to help bootstrap the Psiphon network, +%if one of its barriers to deployment is a lack of volunteers willing +%to exit directly to websites. But it clearly drops some of the nice +%anonymity and security features Tor provides. + +%A hybrid approach where the user gets his anonymity from Tor but his +%software-less use from a web proxy running on a trusted machine on the +%free side. + +\subsection{Publicity attracts attention} +\label{subsec:publicity} + +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 focus on getting more users signed up, +but rather to educate the rest of 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 extra attention work to our +disadvantage? + +\subsection{The Tor website: how to get the software} + +One of the first censoring attacks against a system like ours is to +block the website and make the software itself hard to find. Our system +should work well once the user is running an authentic +copy of Tor and has found a working bridge, but to get to that point +we rely on their individual skills and ingenuity. + +Right now, most countries that block access to Tor block only the main +website and leave mirrors and the network itself untouched. +Falling back on word-of-mouth is always a good last resort, but we should +also take steps to make sure it's relatively easy for users to get a copy, +such as publicizing the mirrors more and making copies available through +other media. We might also mirror the latest version of the software on +each bridge, so users who hear about an honest bridge can get a good +copy. +See Section~\ref{subsec:first-bridge} for more discussion. + +% Ian suggests that we have every tor relay distribute a signed copy of the +% software. + +\section{Next Steps} +\label{sec:conclusion} + +Technical solutions won't solve the whole censorship problem. After all, +the firewalls in places like China 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 + +%\section{Counting Tor users by country} +%\label{app:geoip} + +\end{document} + + + +\section{Future designs} +\label{sec:future} + +\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 bridge authority 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. + +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. + + +------------------------------------------ + +ship geoip db to bridges. they look up users who tls to them in the db, +and upload a signed list of countries and number-of-users each day. the +bridge authority aggregates them and publishes stats. + +bridge relays have buddies +they ask a user to test the reachability of their buddy. +leaks O(1) bridges, but not O(n). + +we should not be blockable by ordinary cisco censorship features. +that is, if they want to block our new design, they will need to +add a feature to block exactly this. +strategically speaking, this may come in handy. + +Bridges come in clumps of 4 or 8 or whatever. If you know one bridge +in a clump, the authority will tell you the rest. Now bridges can +ask users to test reachability of their buddies. + +Giving out clumps helps with dynamic IP addresses too. Whether it +should be 4 or 8 depends on our churn. + +the account server. let's call it a database, it doesn't have to +be a thing that human interacts with. + +so how do we reward people for being good? + +\subsubsection{Public Bridges with Coordinated Discovery} + +****Pretty much this whole subsubsection will probably need to be +deferred until ``later'' and moved to after end document, but I'm leaving +it here for now in case useful.****** + +Rather than be entirely centralized, we can have a coordinated +collection of bridge authorities, analogous to how Tor network +directory authorities now work. + +Key components +``Authorities'' will distribute caches of what they know to overlapping +collections of nodes so that no one node is owned by one authority. +Also so that it is impossible to DoS info maintained by one authority +simply by making requests to it. + +Where a bridge gets assigned is not predictable by the bridge? + +If authorities don't know the IP addresses of the bridges they +are responsible for, they can't abuse that info (or be attacked for +having it). But, they also can't, e.g., control being sent massive +lists of nodes that were never good. This raises another question. +We generally decry use of IP address for location, etc. but we +need to do that to limit the introduction of functional but useless +IP addresses because, e.g., they are in China and the adversary +owns massive chunks of the IP space there. + +We don't want an arbitrary someone to be able to contact the +authorities and say an IP address is bad because it would be easy +for an adversary to take down all the suspicious bridges +even if they provide good cover websites, etc. Only the bridge +itself and/or the directory authority can declare a bridge blocked +from somewhere. + + +9. Bridge directories must not simply be a handful of nodes that +provide the list of bridges. They must flood or otherwise distribute +information out to other Tor nodes as mirrors. That way it becomes +difficult for censors to flood the bridge directory authorities with +requests, effectively denying access for others. But, there's lots of +churn and a much larger size than Tor directories. We are forced to +handle the directory scaling problem here much sooner than for the +network in general. Authorities can pass their bridge directories +(and policy info) to some moderate number of unidentified Tor nodes. +Anyone contacting one of those nodes can get bridge info. the nodes +must remain somewhat synched to prevent the adversary from abusing, +e.g., a timed release policy or the distribution to those nodes must +be resilient even if they are not coordinating. + +I think some kind of DHT like scheme would work here. A Tor node is +assigned a chunk of the directory. Lookups in the directory should be +via hashes of keys (fingerprints) and that should determine the Tor +nodes responsible. Ordinary directories can publish lists of Tor nodes +responsible for fingerprint ranges. Clients looking to update info on +some bridge will make a Tor connection to one of the nodes responsible +for that address. Instead of shutting down a circuit after getting +info on one address, extend it to another that is responsible for that +address (the node from which you are extending knows you are doing so +anyway). Keep going. This way you can amortize the Tor connection. + +10. We need some way to give new identity keys out to those who need +them without letting those get immediately blocked by authorities. One +way is to give a fingerprint that gets you more fingerprints, as +already described. These are meted out/updated periodically but allow +us to keep track of which sources are compromised: if a distribution +fingerprint repeatedly leads to quickly blocked bridges, it should be +suspect, dropped, etc. Since we're using hashes, there shouldn't be a +correlation with bridge directory mirrors, bridges, portions of the +network observed, etc. It should just be that the authorities know +about that key that leads to new addresses. + +This last point is very much like the issues in the valet nodes paper, +which is essentially about blocking resistance wrt exiting the Tor network, +while this paper is concerned with blocking the entering to the Tor network. +In fact the tickets used to connect to the IPo (Introduction Point), +could serve as an example, except that instead of authorizing +a connection to the Hidden Service, it's authorizing the downloading +of more fingerprints. + +Also, the fingerprints can follow the hash(q + '1' + cookie) scheme of +that paper (where q = hash(PK + salt) gave the q.onion address). This +allows us to control and track which fingerprint was causing problems. + +Note that, unlike many settings, the reputation problem should not be +hard here. If a bridge says it is blocked, then it might as well be. +If an adversary can say that the bridge is blocked wrt +$\mathit{censor}_i$, then it might as well be, since +$\mathit{censor}_i$ can presumably then block that bridge if it so +chooses. + +11. How much damage can the adversary do by running nodes in the Tor +network and watching for bridge nodes connecting to it? (This is +analogous to an Introduction Point watching for Valet Nodes connecting +to it.) What percentage of the network do you need to own to do how +much damage. Here the entry-guard design comes in helpfully. So we +need to have bridges use entry-guards, but (cf. 3 above) not use +bridges as entry-guards. Here's a serious tradeoff (again akin to the +ratio of valets to IPos) the more bridges/client the worse the +anonymity of that client. The fewer bridges/client the worse the +blocking resistance of that client. + + + diff --git a/2006/blocking/tor-design.bib b/2006/blocking/tor-design.bib new file mode 100644 index 0000000..981761e --- /dev/null +++ b/2006/blocking/tor-design.bib @@ -0,0 +1,1493 @@ +% hs-attack +@inproceedings{hs-attack, + title = {Locating Hidden Servers}, + author = {Lasse {\O}verlier and Paul Syverson}, + booktitle = {Proceedings of the 2006 IEEE Symposium on Security and Privacy}, + year = {2006}, + month = {May}, + publisher = {IEEE CS}, +} + + +@TechReport{bauer:tr2007, + author = {Kevin Bauer and Damon McCoy and Dirk Grunwald and Tadayoshi Kohno and Douglas Sicker}, + title = {Low-Resource Routing Attacks Against Anonymous Systems}, + institution = {University of Colorado at Boulder}, + year = 2007, + number = {CU-CS-1025-07} +} + +@inproceedings{bauer:wpes2007, + title = {Low-Resource Routing Attacks Against Tor}, + author = {Kevin Bauer and Damon McCoy and Dirk Grunwald and Tadayoshi Kohno and Douglas Sicker}, + booktitle = {{Proceedings of the Workshop on Privacy in the Electronic Society (WPES 2007)}}, + year = {2007}, + month = {October}, + address = {Washington, DC, USA}, +} + +% fix me +@misc{tannenbaum96, + author = "Andrew Tannenbaum", + title = "Computer Networks", + year = "1996", + publisher = "Prentice Hall, 3rd edition", +} + +@article{ meadows96, + author = "Catherine Meadows", + title = "The {NRL} Protocol Analyzer: An Overview", + journal = "Journal of Logic Programming", + volume = "26", + number = "2", + pages = "113--131", + year = "1996", +} +@inproceedings{kesdogan:pet2002, + title = {Unobservable Surfing on the World Wide Web: Is Private Information Retrieval an + alternative to the MIX based Approach?}, + author = {Dogan Kesdogan and Mark Borning and Michael Schmeink}, + booktitle = {Privacy Enhancing Technologies (PET 2002)}, + year = {2002}, + month = {April}, + editor = {Roger Dingledine and Paul Syverson}, + publisher = {Springer-Verlag, LNCS 2482}, +} + +@inproceedings{statistical-disclosure, + title = {Statistical Disclosure Attacks}, + author = {George Danezis}, + booktitle = {Security and Privacy in the Age of Uncertainty ({SEC2003})}, + organization = {{IFIP TC11}}, + year = {2003}, + month = {May}, + address = {Athens}, + pages = {421--426}, + publisher = {Kluwer}, +} + +@inproceedings{limits-open, + title = {Limits of Anonymity in Open Environments}, + author = {Dogan Kesdogan and Dakshi Agrawal and Stefan Penz}, + booktitle = {Information Hiding Workshop (IH 2002)}, + year = {2002}, + month = {October}, + editor = {Fabien Petitcolas}, + publisher = {Springer-Verlag, LNCS 2578}, +} + +@inproceedings{isdn-mixes, + title = {{ISDN-mixes: Untraceable communication with very small bandwidth overhead}}, + author = {Andreas Pfitzmann and Birgit Pfitzmann and Michael Waidner}, + booktitle = {GI/ITG Conference on Communication in Distributed Systems}, + year = {1991}, + month = {February}, + pages = {451-463}, +} + + +@Article{jerichow-jsac98, + author = {Anja Jerichow and Jan M"{u}ller and Andreas + Pfitzmann and Birgit Pfitzmann and Michael Waidner}, + title = {Real-Time Mixes: A Bandwidth-Efficient Anonymity Protocol}, + journal = {IEEE Journal on Selected Areas in Communications}, + year = 1998, + volume = 16, + number = 4, + pages = {495--509}, + month = {May} +} + +@inproceedings{tarzan:ccs02, + title = {Tarzan: A Peer-to-Peer Anonymizing Network Layer}, + author = {Michael J. Freedman and Robert Morris}, + booktitle = {9th {ACM} {C}onference on {C}omputer and {C}ommunications + {S}ecurity ({CCS 2002})}, + year = {2002}, + month = {November}, + address = {Washington, DC}, +} + +@inproceedings{cebolla, + title = {{Cebolla: Pragmatic IP Anonymity}}, + author = {Zach Brown}, + booktitle = {Ottawa Linux Symposium}, + year = {2002}, + month = {June}, +} + +@inproceedings{eax, + author = "M. Bellare and P. Rogaway and D. Wagner", + title = {The {EAX} Mode of Operation: A Two-Pass Authenticated-Encryption Scheme Optimized for Simplicity and Efficiency}, + booktitle = {Fast Software Encryption 2004}, + month = {February}, + year = {2004}, +} + +@misc{darkside, + title = {{The Dark Side of the Web: An Open Proxy's View}}, + author = {Vivek S. Pai and Limin Wang and KyoungSoo Park and Ruoming Pang and Larry Peterson}, + note = {\newline \url{http://codeen.cs.princeton.edu/%7D%7D, +} +% note = {Submitted to HotNets-II. \url{http://codeen.cs.princeton.edu/%7D%7D, + +@Misc{anonymizer, + key = {anonymizer}, + title = {The {Anonymizer}}, + note = {\url{http://anonymizer.com/%7D%7D +} + +@Misc{privoxy, + key = {privoxy}, + title = {{Privoxy}}, + note = {\url{http://www.privoxy.org/%7D%7D +} + +@Misc{i2p, + key = {i2p}, + title = {{I2P}}, + note = {\url{http://www.i2p.net/%7D%7D +} + +@Misc{nym, + author = {Jason Holt}, + title = {nym: practical pseudonymity for anonymous networks}, + note = {Paper and source code at \url{http://www.lunkwill.org/src/nym/%7D%7D +} + +@InProceedings{nymble, + author = {Peter C. Johnson and Apu Kapadia and Patrick P. Tsang and Sean W. Smith}, + title = {Nymble: Anonymous {IP}-address Blocking}, + booktitle = {Privacy Enhancing Technologies (PET 2007)}, + year = 2007, + publisher = {Springer-Verlag, LNCS 4776} +} + +@inproceedings{anonnet, + title = {{Analysis of an Anonymity Network for Web Browsing}}, + author = {Marc Rennhard and Sandro Rafaeli and Laurent Mathy and Bernhard Plattner and + David Hutchison}, + booktitle = {{IEEE 7th Intl. Workshop on Enterprise Security (WET ICE + 2002)}}, + year = {2002}, + month = {June}, + address = {Pittsburgh, USA}, +} +% pages = {49--54}, + +@inproceedings{econymics, + title = {On the Economics of Anonymity}, + author = {Alessandro Acquisti and Roger Dingledine and Paul Syverson}, + booktitle = {Financial Cryptography}, + year = {2003}, + editor = {Rebecca N. Wright}, + publisher = {Springer-Verlag, LNCS 2742}, +} + +@inproceedings{defensive-dropping, + title = {Timing Analysis in Low-Latency Mix-Based Systems}, + author = {Brian N. Levine and Michael K. Reiter and Chenxi Wang and Matthew Wright}, + booktitle = {Financial Cryptography}, + year = {2004}, + editor = {Ari Juels}, + publisher = {Springer-Verlag, LNCS (forthcoming)}, +} + +@inproceedings{morphmix:fc04, + title = {Practical Anonymity for the Masses with MorphMix}, + author = {Marc Rennhard and Bernhard Plattner}, + booktitle = {Financial Cryptography}, + year = {2004}, + editor = {Ari Juels}, + publisher = {Springer-Verlag, LNCS (forthcoming)}, +} + +@inproceedings{eternity, + title = {The Eternity Service}, + author = {Ross Anderson}, + booktitle = {Pragocrypt '96}, + year = {1996}, +} + %note = {\url{http://www.cl.cam.ac.uk/users/rja14/eternity/eternity.html%7D%7D, + + +@inproceedings{minion-design, + title = {Mixminion: Design of a Type {III} Anonymous Remailer Protocol}, + author = {George Danezis and Roger Dingledine and Nick Mathewson}, + booktitle = {2003 IEEE Symposium on Security and Privacy}, + year = {2003}, + month = {May}, + publisher = {IEEE CS}, + pages = {2--15}, +} + %note = {\url{http://mixminion.net/minion-design.pdf%7D%7D, + +@inproceedings{ rao-pseudonymity, + author = "Josyula R. Rao and Pankaj Rohatgi", + title = "Can Pseudonymity Really Guarantee Privacy?", + booktitle = "Proceedings of the Ninth USENIX Security Symposium", + year = {2000}, + month = Aug, + publisher = {USENIX}, + pages = "85--96", +} + %note = {\url{http://www.usenix.org/publications/library/proceedings/sec2000/ +%full_papers/rao/rao.pdf}}, + +@InProceedings{pfitzmann90how, + author = "Birgit Pfitzmann and Andreas Pfitzmann", + title = "How to Break the Direct {RSA}-Implementation of {MIXes}", + booktitle = {Eurocrypt 89}, + publisher = {Springer-Verlag, LNCS 434}, + year = {1990}, + note = {\url{http://citeseer.nj.nec.com/pfitzmann90how.html%7D%7D, +} + +@Misc{tor-spec, + author = {Roger Dingledine and Nick Mathewson}, + title = {Tor Protocol Specifications}, + note = {\url{https://www.torproject.org/svn/trunk/doc/tor-spec.txt%7D%7D, +} + +@Misc{incentives-txt, + author = {Roger Dingledine and Nick Mathewson}, + title = {Tor Incentives Design Brainstorms}, + note = {\url{https://www.torproject.org/svn/trunk/doc/incentives.txt%7D%7D, +} + +@InProceedings{BM:mixencrypt, + author = {M{"o}ller, Bodo}, + title = {Provably Secure Public-Key Encryption for Length-Preserving Chaumian Mixes}, + booktitle = {{CT-RSA} 2003}, + publisher = {Springer-Verlag, LNCS 2612}, + year = 2003, +} + +@InProceedings{back01, + author = {Adam Back and Ulf M"oller and Anton Stiglic}, + title = {Traffic Analysis Attacks and Trade-Offs in Anonymity Providing Systems}, + booktitle = {Information Hiding (IH 2001)}, + pages = {245--257}, + year = 2001, + editor = {Ira S. Moskowitz}, + publisher = {Springer-Verlag, LNCS 2137}, +} + %note = {\newline \url{http://www.cypherspace.org/adam/pubs/traffic.pdf%7D%7D, + +@InProceedings{rackoff93cryptographic, + author = {Charles Rackoff and Daniel R. Simon}, + title = {Cryptographic Defense Against Traffic Analysis}, + booktitle = {{ACM} Symposium on Theory of Computing}, + pages = {672--681}, + year = {1993}, +} + %note = {\url{http://research.microsoft.com/crypto/dansimon/me.htm%7D%7D, + +@InProceedings{freehaven-berk, + author = {Roger Dingledine and Michael J. Freedman and David Molnar}, + title = {The Free Haven Project: Distributed Anonymous Storage Service}, + booktitle = {Designing Privacy Enhancing Technologies: Workshop + on Design Issue in Anonymity and Unobservability}, + year = 2000, + month = {July}, + editor = {H. Federrath}, + publisher = {Springer-Verlag, LNCS 2009}, +} + + @InProceedings{move-ndss05, + author = {Angelos Stavrou and Angelos D. Keromytis and Jason Nieh and Vishal Misra and Dan Rubenstein}, + title = {MOVE: An End-to-End Solution To Network Denial of Service}, + booktitle = {{ISOC Network and Distributed System Security Symposium (NDSS05)}}, + year = 2005, + month = {February}, + publisher = {Internet Society} +} + +%note = {\url{http://freehaven.net/papers.html%7D%7D, + + + + +@InProceedings{raymond00, + author = {J. F. Raymond}, + title = {{Traffic Analysis: Protocols, Attacks, Design Issues, + and Open Problems}}, + booktitle = {Designing Privacy Enhancing Technologies: Workshop + on Design Issue in Anonymity and Unobservability}, + year = 2000, + month = {July}, + pages = {10-29}, + editor = {H. Federrath}, + publisher = {Springer-Verlag, LNCS 2009}, +} + +@InProceedings{sybil, + author = "John Douceur", + title = {{The Sybil Attack}}, + booktitle = "Proceedings of the 1st International Peer To Peer Systems Workshop (IPTPS)", + month = Mar, + year = 2002, +} + + +@InCollection{price-privacy, + author = {Paul Syverson and Adam Shostack}, + editor = {L. Jean Camp and Stephen Lewis}, + title = {What Price Privacy? (and why identity theft is about neither identity nor theft)}, + booktitle = {Economics of Information Security}, + chapter = 10, + publisher = {Kluwer}, + year = 2004, + pages = {129--142} +} + + +@InProceedings{trickle02, + author = {Andrei Serjantov and Roger Dingledine and Paul Syverson}, + title = {From a Trickle to a Flood: Active Attacks on Several + Mix Types}, + booktitle = {Information Hiding (IH 2002)}, + year = {2002}, + editor = {Fabien Petitcolas}, + publisher = {Springer-Verlag, LNCS 2578}, +} + +@InProceedings{langos02, + author = {Oliver Berthold and Heinrich Langos}, + title = {Dummy Traffic Against Long Term Intersection Attacks}, + booktitle = {Privacy Enhancing Technologies (PET 2002)}, + year = {2002}, + editor = {Roger Dingledine and Paul Syverson}, + publisher = {Springer-Verlag, LNCS 2482} +} + + +@InProceedings{hintz-pet02, + author = {Andrew Hintz}, + title = {Fingerprinting Websites Using Traffic Analysis}, + booktitle = {Privacy Enhancing Technologies (PET 2002)}, + pages = {171--178}, + year = 2002, + editor = {Roger Dingledine and Paul Syverson}, + publisher = {Springer-Verlag, LNCS 2482} +} + +@InProceedings{or-discex00, + author = {Paul Syverson and Michael Reed and David Goldschlag}, + title = {{O}nion {R}outing Access Configurations}, + booktitle = {DARPA Information Survivability Conference and + Exposition (DISCEX 2000)}, + year = {2000}, + publisher = {IEEE CS Press}, + pages = {34--40}, + volume = {1}, +} + %note = {\newline \url{http://www.onion-router.net/Publications.html%7D%7D, + +@Inproceedings{or-pet00, + title = {{Towards an Analysis of Onion Routing Security}}, + author = {Paul Syverson and Gene Tsudik and Michael Reed and + Carl Landwehr}, + booktitle = {Designing Privacy Enhancing Technologies: Workshop + on Design Issue in Anonymity and Unobservability}, + year = 2000, + month = {July}, + pages = {96--114}, + editor = {H. Federrath}, + publisher = {Springer-Verlag, LNCS 2009}, +} + %note = {\url{http://www.onion-router.net/Publications/WDIAU-2000.ps.gz%7D%7D, + +@Inproceedings{freenet-pets00, + title = {Freenet: A Distributed Anonymous Information Storage + and Retrieval System}, + author = {Ian Clarke and Oskar Sandberg and Brandon Wiley and + Theodore W. Hong}, + booktitle = {Designing Privacy Enhancing Technologies: Workshop + on Design Issue in Anonymity and Unobservability}, + year = 2000, + month = {July}, + pages = {46--66}, + editor = {H. Federrath}, + publisher = {Springer-Verlag, LNCS 2009}, +} + %note = {\url{http://citeseer.nj.nec.com/clarke00freenet.html%7D%7D, + +@InProceedings{or-ih96, + author = {David M. Goldschlag and Michael G. Reed and Paul + F. Syverson}, + title = {Hiding Routing Information}, + booktitle = {Information Hiding, First International Workshop}, + pages = {137--150}, + year = 1996, + editor = {R. Anderson}, + month = {May}, + publisher = {Springer-Verlag, LNCS 1174}, +} + +@InProceedings{federrath-ih96, + author = {Hannes Federrath and Anja Jerichow and Andreas Pfitzmann}, + title = {{MIXes} in Mobile Communication Systems: Location + Management with Privacy}, + booktitle = {Information Hiding, First International Workshop}, + pages = {121--135}, + year = 1996, + editor = {R. Anderson}, + month = {May}, + publisher = {Springer-Verlag, LNCS 1174}, +} + + +@InProceedings{reed-protocols97, + author = {Michael G. Reed and Paul F. Syverson and David + M. Goldschlag}, + title = {Protocols Using Anonymous Connections: Mobile Applications}, + booktitle = {Security Protocols: 5th International Workshop}, + pages = {13--23}, + year = 1997, + editor = {Bruce Christianson and Bruno Crispo and Mark Lomas + and Michael Roe}, + month = {April}, + publisher = {Springer-Verlag, LNCS 1361} +} + + + +@Article{or-jsac98, + author = {Michael G. Reed and Paul F. Syverson and David + M. Goldschlag}, + title = {Anonymous Connections and Onion Routing}, + journal = {IEEE Journal on Selected Areas in Communications}, + year = 1998, + volume = 16, + number = 4, + pages = {482--494}, + month = {May}, +} + %note = {\url{http://www.onion-router.net/Publications/JSAC-1998.ps.gz%7D%7D + +@Misc{TLS, + author = {T. Dierks and C. Allen}, + title = {The {TLS} {P}rotocol --- {V}ersion 1.0}, + howpublished = {IETF RFC 2246}, + month = {January}, + year = {1999}, +} +%note = {\url{http://www.rfc-editor.org/rfc/rfc2246.txt%7D%7D, + +@Misc{SMTP, + author = {J. Postel}, + title = {Simple {M}ail {T}ransfer {P}rotocol}, + howpublished = {IETF RFC 2821 (also STD0010)}, + month = {April}, + year = {2001}, + note = {\url{http://www.rfc-editor.org/rfc/rfc2821.txt%7D%7D, +} + +@Misc{IMAP, + author = {M. Crispin}, + title = {Internet {M}essage {A}ccess {P}rotocol --- {V}ersion 4rev1}, + howpublished = {IETF RFC 2060}, + month = {December}, + year = {1996}, + note = {\url{http://www.rfc-editor.org/rfc/rfc2060.txt%7D%7D, +} + +@misc{pipenet, + title = {PipeNet 1.1}, + author = {Wei Dai}, + year = 1996, + month = {August}, + howpublished = {Usenet post}, + note = {\url{http://www.eskimo.com/~weidai/pipenet.txt%7D First mentioned + in a post to the cypherpunks list, Feb.\ 1995.}, +} + + +@Misc{POP3, + author = {J. Myers and M. Rose}, + title = {Post {O}ffice {P}rotocol --- {V}ersion 3}, + howpublished = {IETF RFC 1939 (also STD0053)}, + month = {May}, + year = {1996}, + note = {\url{http://www.rfc-editor.org/rfc/rfc1939.txt%7D%7D, +} + + +@InProceedings{shuffle, + author = {C. Andrew Neff}, + title = {A Verifiable Secret Shuffle and its Application to E-Voting}, + booktitle = {8th ACM Conference on Computer and Communications + Security (CCS-8)}, + pages = {116--125}, + year = 2001, + editor = {P. Samarati}, + month = {November}, + publisher = {ACM Press}, +} + %note = {\url{http://www.votehere.net/ada_compliant/ourtechnology/ + % technicaldocs/shuffle.pdf}}, + +@InProceedings{dolev91, + author = {Danny Dolev and Cynthia Dwork and Moni Naor}, + title = {Non-Malleable Cryptography}, + booktitle = {23rd ACM Symposium on the Theory of Computing (STOC)}, + pages = {542--552}, + year = 1991, + note = {Updated version at + \url{http://citeseer.nj.nec.com/dolev00nonmalleable.html%7D%7D, +} + +@TechReport{rsw96, + author = {Ronald L. Rivest and Adi Shamir and David A. Wagner}, + title = {Time-lock puzzles and timed-release Crypto}, + year = 1996, + type = {MIT LCS technical memo}, + number = {MIT/LCS/TR-684}, + month = {February}, + note = {\newline \url{http://citeseer.nj.nec.com/rivest96timelock.html%7D%7D, +} + +@InProceedings{web-mix, + author = {Oliver Berthold and Hannes Federrath and Stefan K"opsell}, + title = {Web {MIX}es: A system for anonymous and unobservable + {I}nternet access}, + booktitle = {Designing Privacy Enhancing Technologies: Workshop + on Design Issue in Anonymity and Unobservability}, + editor = {H. Federrath}, + publisher = {Springer-Verlag, LNCS 2009}, + year = {2000}, +} +% pages = {115--129}, + +@InProceedings{disad-free-routes, + author = {Oliver Berthold and Andreas Pfitzmann and Ronny Standtke}, + title = {The disadvantages of free {MIX} routes and how to overcome + them}, + booktitle = {Designing Privacy Enhancing Technologies: Workshop + on Design Issue in Anonymity and Unobservability}, + pages = {30--45}, + year = 2000, + editor = {H. Federrath}, + publisher = {Springer-Verlag, LNCS 2009}, +} + %note = {\url{http://www.tik.ee.ethz.ch/~weiler/lehre/netsec/Unterlagen/anon/ + % disadvantages_berthold.pdf}}, + +@InProceedings{boneh00, + author = {Dan Boneh and Moni Naor}, + title = {Timed Commitments}, + booktitle = {Advances in Cryptology -- {CRYPTO} 2000}, + pages = {236--254}, + year = 2000, + publisher = {Springer-Verlag, LNCS 1880}, + note = {\newline \url{http://crypto.stanford.edu/~dabo/abstracts/timedcommit.html%7D%7D, +} + +@InProceedings{goldschlag98, + author = {David M. Goldschlag and Stuart G. Stubblebine}, + title = {Publicly Verifiable Lotteries: Applications of + Delaying Functions}, + booktitle = {Financial Cryptography}, + pages = {214--226}, + year = 1998, + publisher = {Springer-Verlag, LNCS 1465}, + note = {\newline \url{http://citeseer.nj.nec.com/goldschlag98publicly.html%7D%7D, +} + +@InProceedings{syverson98, + author = {Paul Syverson}, + title = {Weakly Secret Bit Commitment: Applications to + Lotteries and Fair Exchange}, + booktitle = {Computer Security Foundations Workshop (CSFW11)}, + pages = {2--13}, + year = 1998, + address = {Rockport Massachusetts}, + month = {June}, + publisher = {IEEE CS Press}, + note = {\newline \url{http://chacs.nrl.navy.mil/publications/CHACS/1998/%7D%7D, +} + +@Misc{shoup-iso, + author = {Victor Shoup}, + title = {A Proposal for an {ISO} {S}tandard for Public Key Encryption (version 2.1)}, + note = {Revised December 20, 2001. \url{http://www.shoup.net/papers/%7D%7D, +} + +@Misc{shoup-oaep, + author = {Victor Shoup}, + title = {{OAEP} Reconsidered}, + howpublished = {{IACR} e-print 2000/060}, + note = {\newline \url{http://eprint.iacr.org/2000/060/%7D%7D, +} + +@Misc{oaep-still-alive, + author = {E. Fujisaki and D. Pointcheval and T. Okamoto and J. Stern}, + title = {{RSA}-{OAEP} is Still Alive!}, + howpublished = {{IACR} e-print 2000/061}, + note = {\newline \url{http://eprint.iacr.org/2000/061/%7D%7D, +} + +@misc{echolot, + author = {Peter Palfrader}, + title = {Echolot: a pinger for anonymous remailers}, + note = {\url{http://www.palfrader.org/echolot/%7D%7D, +} + +@Misc{mixmaster-attacks, + author = {Lance Cottrell}, + title = {Mixmaster and Remailer Attacks}, + note = {\url{http://www.obscura.com/~loki/remailer/remailer-essay.html%7D%7D, +} + +@Misc{mixmaster-spec, + author = {Ulf M{"o}ller and Lance Cottrell and Peter + Palfrader and Len Sassaman}, + title = {Mixmaster {P}rotocol --- {V}ersion 2}, + year = {2003}, + month = {July}, + howpublished = {Draft}, + note = {\url{http://www.abditum.com/mixmaster-spec.txt%7D%7D, +} + +@InProceedings{puzzles-tls, + author = "Drew Dean and Adam Stubblefield", + title = {{Using Client Puzzles to Protect TLS}}, + booktitle = "Proceedings of the 10th USENIX Security Symposium", + year = {2001}, + month = Aug, + publisher = {USENIX}, +} + +@InProceedings{breadpudding, + author = {Markus Jakobsson and Ari Juels}, + title = {Proofs of Work and Bread Pudding Protocols}, + booktitle = {Proceedings of the IFIP TC6 and TC11 Joint Working + Conference on Communications and Multimedia Security + (CMS '99)}, + year = 1999, + month = {September}, + publisher = {Kluwer} +} + +@Misc{hashcash, + author = {Adam Back}, + title = {Hash cash}, + note = {\newline \url{http://www.cypherspace.org/~adam/hashcash/%7D%7D, +} + +@InProceedings{oreilly-acc, + author = {Roger Dingledine and Michael J. Freedman and David Molnar}, + title = {Accountability}, + booktitle = {Peer-to-peer: Harnessing the Benefits of a Disruptive + Technology}, + year = {2001}, + publisher = {O'Reilly and Associates}, +} + + +@InProceedings{han, + author = {Yongfei Han}, + title = {Investigation of non-repudiation protocols}, + booktitle = {ACISP '96}, + year = 1996, + publisher = {Springer-Verlag}, +} + + +@Misc{socks5, + key = {socks5}, + title = {{SOCKS} {P}rotocol {V}ersion 5}, + howpublished= {IETF RFC 1928}, + month = {March}, + year = 1996, + note = {\url{http://www.ietf.org/rfc/rfc1928.txt%7D%7D +} + +@InProceedings{abe, + author = {Masayuki Abe}, + title = {Universally Verifiable {MIX} With Verification Work Independent of + The Number of {MIX} Servers}, + booktitle = {{EUROCRYPT} 1998}, + year = {1998}, + publisher = {Springer-Verlag, LNCS 1403}, +} + +@InProceedings{desmedt, + author = {Yvo Desmedt and Kaoru Kurosawa}, + title = {How To Break a Practical {MIX} and Design a New One}, + booktitle = {{EUROCRYPT} 2000}, + year = {2000}, + publisher = {Springer-Verlag, LNCS 1803}, + note = {\url{http://citeseer.nj.nec.com/447709.html%7D%7D, +} + +@InProceedings{mitkuro, + author = {M. Mitomo and K. Kurosawa}, + title = {{Attack for Flash MIX}}, + booktitle = {{ASIACRYPT} 2000}, + year = {2000}, + publisher = {Springer-Verlag, LNCS 1976}, + note = {\newline \url{http://citeseer.nj.nec.com/450148.html%7D%7D, +} + +@InProceedings{hybrid-mix, + author = {M. Ohkubo and M. Abe}, + title = {A {L}ength-{I}nvariant {H}ybrid {MIX}}, + booktitle = {Advances in Cryptology - {ASIACRYPT} 2000}, + year = {2000}, + publisher = {Springer-Verlag, LNCS 1976}, +} + +@InProceedings{PShuffle, + author = {Jun Furukawa and Kazue Sako}, + title = {An Efficient Scheme for Proving a Shuffle}, + editor = {Joe Kilian}, + booktitle = {CRYPTO 2001}, + year = {2001}, + publisher = {Springer-Verlag, LNCS 2139}, +} + + +@InProceedings{jakobsson-optimally, + author = "Markus Jakobsson and Ari Juels", + title = "An Optimally Robust Hybrid Mix Network (Extended Abstract)", + booktitle = {Principles of Distributed Computing - {PODC} '01}, + year = "2001", + publisher = {ACM Press}, + note = {\url{http://citeseer.nj.nec.com/492015.html%7D%7D, +} + +@InProceedings{kesdogan, + author = {D. Kesdogan and M. Egner and T. B"uschkes}, + title = {Stop-and-Go {MIX}es Providing Probabilistic Anonymity in an Open + System}, + booktitle = {Information Hiding (IH 1998)}, + year = {1998}, + publisher = {Springer-Verlag, LNCS 1525}, +} + %note = {\url{http://www.cl.cam.ac.uk/~fapp2/ihw98/ihw98-sgmix.pdf%7D%7D, + +@InProceedings{socks4, + author = {David Koblas and Michelle R. Koblas}, + title = {{SOCKS}}, + booktitle = {UNIX Security III Symposium (1992 USENIX Security + Symposium)}, + pages = {77--83}, + year = 1992, + publisher = {USENIX}, +} + +@InProceedings{flash-mix, + author = {Markus Jakobsson}, + title = {Flash {M}ixing}, + booktitle = {Principles of Distributed Computing - {PODC} '99}, + year = {1999}, + publisher = {ACM Press}, + note = {\newline \url{http://citeseer.nj.nec.com/jakobsson99flash.html%7D%7D, +} + +@InProceedings{SK, + author = {Joe Kilian and Kazue Sako}, + title = {Receipt-Free {MIX}-Type Voting Scheme - A Practical Solution to + the Implementation of a Voting Booth}, + booktitle = {EUROCRYPT '95}, + year = {1995}, + publisher = {Springer-Verlag}, +} + +@InProceedings{OAEP, + author = {M. Bellare and P. Rogaway}, + year = {1994}, + booktitle = {EUROCRYPT '94}, + title = {Optimal {A}symmetric {E}ncryption {P}adding : How To Encrypt With + {RSA}}, + publisher = {Springer-Verlag}, + note = {\newline \url{http://www-cse.ucsd.edu/users/mihir/papers/oaep.html%7D%7D, +} +@inproceedings{babel, + title = {Mixing {E}-mail With {B}abel}, + author = {Ceki G"ulc"u and Gene Tsudik}, + booktitle = {{Network and Distributed Security Symposium (NDSS 96)}}, + year = 1996, + month = {February}, + pages = {2--16}, + publisher = {IEEE}, +} + %note = {\url{http://citeseer.nj.nec.com/2254.html%7D%7D, + +@Misc{rprocess, + author = {RProcess}, + title = {Selective Denial of Service Attacks}, + note = {\newline \url{http://www.eff.org/pub/Privacy/Anonymity/1999%5C_09%5C_DoS%5C_remail%5C_vuln..., +} + +@Article{remailer-history, + author = {Sameer Parekh}, + title = {Prospects for Remailers}, + journal = {First Monday}, + volume = {1}, + number = {2}, + month = {August}, + year = {1996}, + note = {\url{http://www.firstmonday.dk/issues/issue2/remailers/%7D%7D, +} + +@Article{chaum-mix, + author = {David Chaum}, + title = {Untraceable electronic mail, return addresses, and digital pseudo-nyms}, + journal = {Communications of the ACM}, + year = {1981}, + volume = {4}, + number = {2}, + month = {February}, +} + %note = {\url{http://www.eskimo.com/~weidai/mix-net.txt%7D%7D, + +@InProceedings{nym-alias-net, + author = {David Mazi`{e}res and M. Frans Kaashoek}, + title = {{The Design, Implementation and Operation of an Email + Pseudonym Server}}, + booktitle = {$5^{th}$ ACM Conference on Computer and + Communications Security (CCS'98)}, + year = 1998, + publisher = {ACM Press}, +} + %note = {\newline \url{http://www.scs.cs.nyu.edu/~dm/%7D%7D, + +@InProceedings{tangler, + author = {Marc Waldman and David Mazi`{e}res}, + title = {Tangler: A Censorship-Resistant Publishing System + Based on Document Entanglements}, + booktitle = {$8^{th}$ ACM Conference on Computer and + Communications Security (CCS-8)}, + pages = {86--135}, + year = 2001, + publisher = {ACM Press}, +} + %note = {\url{http://www.scs.cs.nyu.edu/~dm/%7D%7D + +@misc{neochaum, + author = {Tim May}, + title = {Payment mixes for anonymity}, + howpublished = {E-mail archived at + \url{http://%5Cnewline www.inet-one.com/cypherpunks/dir.2000.02.28-2000.03.05/msg00334.html}}, +} + +@misc{helsingius, + author = {J. Helsingius}, + title = {{\tt anon.penet.fi} press release}, + note = {\newline \url{http://www.penet.fi/press-english.html%7D%7D, +} + +@InProceedings{garay97secure, + author = {J. Garay and R. Gennaro and C. Jutla and T. Rabin}, + title = {Secure distributed storage and retrieval}, + booktitle = {11th International Workshop, WDAG '97}, + pages = {275--289}, + year = {1997}, + publisher = {Springer-Verlag, LNCS 1320}, + note = {\newline \url{http://citeseer.nj.nec.com/garay97secure.html%7D%7D, +} + +@InProceedings{PIK, + author = {C. Park and K. Itoh and K. Kurosawa}, + title = {Efficient anonymous channel and all/nothing election scheme}, + booktitle = {Advances in Cryptology -- {EUROCRYPT} '93}, + pages = {248--259}, + publisher = {Springer-Verlag, LNCS 765}, +} + +@Misc{pgpfaq, + key = {PGP}, + title = {{PGP} {FAQ}}, + note = {\newline \url{http://www.faqs.org/faqs/pgp-faq/%7D%7D, +} + +@Article{riordan-schneier, + author = {James Riordan and Bruce Schneier}, + title = {A Certified E-mail Protocol with No Trusted Third Party}, + journal = {13th Annual Computer Security Applications Conference}, + month = {December}, + year = {1998}, + note = {\newline \url{http://www.counterpane.com/certified-email.html%7D%7D, +} + + +@Article{crowds-tissec, + author = {Michael K. Reiter and Aviel D. Rubin}, + title = {Crowds: Anonymity for Web Transactions}, + journal = {ACM TISSEC}, + year = 1998, + volume = 1, + number = 1, + pages = {66--92}, + month = {June}, +} + %note = {\url{http://citeseer.nj.nec.com/284739.html%7D%7D + +@Article{crowds-dimacs, + author = {Michael K. Reiter and Aviel D. Rubin}, + title = {Crowds: Anonymity for Web Transactions}, + journal = {{DIMACS} Technical Report (Revised)}, + volume = {97}, + number = {15}, + month = {August}, + year = {1997}, +} + +@Misc{advogato, + author = {Raph Levien}, + title = {Advogato's Trust Metric}, + note = {\newline \url{http://www.advogato.org/trust-metric.html%7D%7D, +} + +@InProceedings{publius, + author = {Marc Waldman and Aviel Rubin and Lorrie Cranor}, + title = {Publius: {A} robust, tamper-evident, censorship-resistant and + source-anonymous web publishing system}, + booktitle = {Proc. 9th USENIX Security Symposium}, + pages = {59--72}, + year = {2000}, + month = {August}, +} + %note = {\newline \url{http://citeseer.nj.nec.com/waldman00publius.html%7D%7D, + +@Misc{freedom-nyms, + author = {Russell Samuels}, + title = {Untraceable Nym Creation on the {F}reedom {N}etwork}, + year = {1999}, + month = {November}, + day = {21}, + note = {\newline \url{http://www.freedom.net/products/whitepapers/white11.html%7D%7D, +} + +@techreport{freedom2-arch, + title = {Freedom Systems 2.0 Architecture}, + author = {Philippe Boucher and Adam Shostack and Ian Goldberg}, + institution = {Zero Knowledge Systems, {Inc.}}, + year = {2000}, + month = {December}, + type = {White Paper}, + day = {18}, +} + +@techreport{freedom21-security, + title = {Freedom Systems 2.1 Security Issues and Analysis}, + author = {Adam Back and Ian Goldberg and Adam Shostack}, + institution = {Zero Knowledge Systems, {Inc.}}, + year = {2001}, + month = {May}, + type = {White Paper}, +} + +@inproceedings{cfs:sosp01, + title = {Wide-area cooperative storage with {CFS}}, + author = {Frank Dabek and M. Frans Kaashoek and David Karger and Robert Morris and Ion Stoica}, + booktitle = {18th {ACM} {S}ymposium on {O}perating {S}ystems {P}rinciples ({SOSP} '01)}, + year = {2001}, + month = {October}, + address = {Chateau Lake Louise, Banff, Canada}, +} + +@inproceedings{SS03, + title = {Passive Attack Analysis for Connection-Based Anonymity Systems}, + author = {Andrei Serjantov and Peter Sewell}, + booktitle = {Computer Security -- ESORICS 2003}, + publisher = {Springer-Verlag, LNCS 2808}, + year = {2003}, + month = {October}, +} + %note = {\url{http://www.cl.cam.ac.uk/users/aas23/papers_aas/conn_sys.ps%7D%7D, + +@Misc{pk-relations, + author = {M. Bellare and A. Desai and D. Pointcheval and P. Rogaway}, + title = {Relations Among Notions of Security for Public-Key Encryption + Schemes}, + howpublished = { + Extended abstract in {\em Advances in Cryptology - CRYPTO '98}, LNCS Vol. 1462. + Springer-Verlag, 1998. + Full version available from \newline \url{http://www-cse.ucsd.edu/users/mihir/%7D%7D, +} + + +@InProceedings{mix-acc, + author = {Roger Dingledine and Michael J. Freedman and David + Hopwood and David Molnar}, + title = {{A Reputation System to Increase MIX-net + Reliability}}, + booktitle = {Information Hiding (IH 2001)}, + pages = {126--141}, + year = 2001, + editor = {Ira S. Moskowitz}, + publisher = {Springer-Verlag, LNCS 2137}, +} + %note = {\url{http://www.freehaven.net/papers.html%7D%7D, + +@InProceedings{casc-rep, + author = {Roger Dingledine and Paul Syverson}, + title = {{Reliable MIX Cascade Networks through Reputation}}, + booktitle = {Financial Cryptography}, + year = 2002, + editor = {Matt Blaze}, + publisher = {Springer-Verlag, LNCS 2357}, +} + %note = {\newline \url{http://www.freehaven.net/papers.html%7D%7D, + +@InProceedings{zhou96certified, + author = {Zhou and Gollmann}, + title = {Certified Electronic Mail}, + booktitle = {{ESORICS: European Symposium on Research in Computer + Security}}, + publisher = {Springer-Verlag, LNCS 1146}, + year = {1996}, + note = {\newline \url{http://citeseer.nj.nec.com/zhou96certified.html%7D%7D, +} + +@Misc{realtime-mix, + author = {Anja Jerichow and Jan M"uller and Andreas Pfitzmann and + Birgit Pfitzmann and Michael Waidner}, + title = {{Real-Time MIXes: A Bandwidth-Efficient Anonymity Protocol}}, + howpublished = {IEEE Journal on Selected Areas in Communications, 1998.}, + note = {\url{http://www.zurich.ibm.com/security/publications/1998.html%7D%7D, +} + +@InProceedings{danezis:pet2003, + author = {George Danezis}, + title = {Mix-networks with Restricted Routes}, + booktitle = {Privacy Enhancing Technologies (PET 2003)}, + year = 2003, + editor = {Roger Dingledine}, + publisher = {Springer-Verlag LNCS 2760} +} + +@InProceedings{gap-pets03, + author = {Krista Bennett and Christian Grothoff}, + title = {{GAP} -- practical anonymous networking}, + booktitle = {Privacy Enhancing Technologies (PET 2003)}, + year = 2003, + editor = {Roger Dingledine}, + publisher = {Springer-Verlag LNCS 2760} +} + +@Article{hordes-jcs, + author = {Brian Neal Levine and Clay Shields}, + title = {Hordes: A Multicast-Based Protocol for Anonymity}, + journal = {Journal of Computer Security}, + year = 2002, + volume = 10, + number = 3, + pages = {213--240} +} + +@TechReport{herbivore, + author = {Sharad Goel and Mark Robson and Milo Polte and Emin G"{u}n Sirer}, + title = {Herbivore: A Scalable and Efficient Protocol for Anonymous Communication}, + institution = {Cornell University Computing and Information Science}, + year = 2003, + type = {Technical Report}, + number = {TR2003-1890}, + month = {February} +} + +@InProceedings{p5, + author = {Rob Sherwood and Bobby Bhattacharjee and Aravind Srinivasan}, + title = {$P^5$: A Protocol for Scalable Anonymous Communication}, + booktitle = {IEEE Symposium on Security and Privacy}, + pages = {58--70}, + year = 2002, + publisher = {IEEE CS} +} + +@phdthesis{ian-thesis, + title = {A Pseudonymous Communications Infrastructure for the Internet}, + author = {Ian Goldberg}, + school = {UC Berkeley}, + year = {2000}, + month = {Dec}, +} + +@Article{taz, + author = {Ian Goldberg and David Wagner}, + title = {TAZ Servers and the Rewebber Network: Enabling + Anonymous Publishing on the World Wide Web}, + journal = {First Monday}, + year = 1998, + volume = 3, + number = 4, + month = {August}, + note = {\url{http://www.firstmonday.dk/issues/issue3_4/goldberg/%7D%7D +} + +@Misc{tcp-over-tcp-is-bad, + key = {tcp-over-tcp-is-bad}, + title = {Why {TCP} Over {TCP} Is A Bad Idea}, + author = {Olaf Titz}, + note = {\url{http://sites.inka.de/sites/bigred/devel/tcp-tcp.html%7D%7D +} + +@inproceedings{wright02, + title = {An Analysis of the Degradation of Anonymous Protocols}, + author = {Matthew Wright and Micah Adler and Brian Neil Levine and Clay Shields}, + booktitle = {{Network and Distributed Security Symposium (NDSS 02)}}, + year = {2002}, + month = {February}, + publisher = {IEEE}, +} + +@inproceedings{wright03, + title = {Defending Anonymous Communication Against Passive Logging Attacks}, + author = {Matthew Wright and Micah Adler and Brian Neil Levine and Clay Shields}, + booktitle = {IEEE Symposium on Security and Privacy}, + pages= {28--41}, + year = {2003}, + month = {May}, + publisher = {IEEE CS}, +} + + +@InProceedings{attack-tor-oak05, + author = {Steven J. Murdoch and George Danezis}, + title = {Low-cost Traffic Analysis of {T}or}, + booktitle = {IEEE Symposium on Security and Privacy}, + year = 2005, + month = {May}, + publisher = {IEEE CS} +} + +@Misc{jap-backdoor, + author={{The AN.ON Project}}, + howpublished={Press release}, + year={2003}, + month={September}, + title={German Police proceeds against anonymity service}, + note={\url{http://www.datenschutzzentrum.de/material/themen/presse/anon-bka_e.htm%7D%7D +} + +@article{shsm03, + title = {Using Caching for Browsing Anonymity}, + author = {Anna Shubina and Sean Smith}, + journal = {ACM SIGEcom Exchanges}, + volume = {4}, + number = {2}, + year = {2003}, + month = {Sept}, + note = {\url{http://www.acm.org/sigs/sigecom/exchanges/volume_4_(03)/4.2-Shubina.pdf%7D%7..., +} + +@inproceedings{tor-design, + title = {Tor: The Second-Generation Onion Router}, + author = {Roger Dingledine and Nick Mathewson and Paul Syverson}, + booktitle = {Proceedings of the 13th USENIX Security Symposium}, + year = {2004}, + month = {August}, + note = {\url{https://www.torproject.org/tor-design.pdf%7D%7D +} + +@inproceedings{flow-correlation04, + title = {On Flow Correlation Attacks and Countermeasures in Mix Networks}, + author = {Ye Zhu and Xinwen Fu and Bryan Graham and Riccardo Bettati and Wei Zhao}, + booktitle = {Proceedings of Privacy Enhancing Technologies workshop (PET 2004)}, + year = {2004}, + month = {May}, + series = {LNCS}, + note = {\url{http://students.cs.tamu.edu/xinwenfu/paper/PET04.pdf%7D%7D, +} + +@InProceedings{danezis:pet2004, + author = "George Danezis", + title = "The Traffic Analysis of Continuous-Time Mixes", + booktitle= {Privacy Enhancing Technologies (PET 2004)}, + editor = {David Martin and Andrei Serjantov}, + month = {May}, + year = {2004}, + series = {LNCS}, + note = {\url{http://www.cl.cam.ac.uk/users/gd216/cmm2.pdf%7D%7D, +} + +@inproceedings{feamster:wpes2004, + title = {Location Diversity in Anonymity Networks}, + author = {Nick Feamster and Roger Dingledine}, + booktitle = {{Proceedings of the Workshop on Privacy in the Electronic Society (WPES 2004)}}, + year = {2004}, + month = {October}, + address = {Washington, DC, USA}, + note = {\url{http://freehaven.net/doc/routing-zones/routing-zones.ps%7D%7D, +} + +@inproceedings{koepsell:wpes2004, + title = {How to Achieve Blocking Resistance for Existing Systems Enabling Anonymous Web Surfing}, + author = {Stefan K"opsell and Ulf Hilling}, + booktitle = {{Proceedings of the Workshop on Privacy in the Electronic Society (WPES 2004)}}, + year = {2004}, + month = {October}, + address = {Washington, DC, USA}, + note = {\url{http://freehaven.net/anonbib/papers/p103-koepsell.pdf%7D%7D, +} + +@inproceedings{sync-batching, + title = {Synchronous Batching: From Cascades to Free Routes}, + author = {Roger Dingledine and Vitaly Shmatikov and Paul Syverson}, + booktitle = {Proceedings of Privacy Enhancing Technologies workshop (PET 2004)}, + editor = {David Martin and Andrei Serjantov}, + year = {2004}, + month = {May}, + series = {LNCS}, + note = {\url{http://freehaven.net/doc/sync-batching/sync-batching.pdf%7D%7D, +} + +@InProceedings{e2e-traffic, + author = "Nick Mathewson and Roger Dingledine", + title = "Practical Traffic Analysis: Extending and Resisting Statistical Disclosure", + booktitle= {Privacy Enhancing Technologies (PET 2004)}, + editor = {David Martin and Andrei Serjantov}, + month = {May}, + year = {2004}, + series = {LNCS}, + note = {\url{http://freehaven.net/doc/e2e-traffic/e2e-traffic.pdf%7D%7D, +} + +@Misc{dtls, + author = {E. Rescorla and N. Modadugu}, + title = {{Datagram Transport Layer Security}}, + howpublished = {IETF Draft}, + month = {December}, + year = {2003}, + note = {\url{http://www.ietf.org/internet-drafts/draft-rescorla-dtls-02.txt%7D%7D, +} + +@InProceedings{usability-network-effect, + author={Roger Dingledine and Nick Mathewson}, + title={Anonymity Loves Company: Usability and the Network Effect}, + booktitle = {Designing Security Systems That People Can Use}, + year = {2005}, + publisher = {O'Reilly Media}, +} + +@inproceedings{usability:weis2006, + title = {Anonymity Loves Company: Usability and the Network Effect}, + author = {Roger Dingledine and Nick Mathewson}, + booktitle = {Proceedings of the Fifth Workshop on the Economics of Information Security + (WEIS 2006)}, + year = {2006}, + month = {June}, + address = {Cambridge, UK}, + bookurl = {http://weis2006.econinfosec.org/%7D, + note = {\url{http://freehaven.net/doc/wupss04/usability.pdf%7D%7D, +} + +@Misc{six-four, + key = {six-four}, + title = {{The Six/Four System}}, + note = {\url{http://sourceforge.net/projects/sixfour/%7D%7D +} + +@inproceedings{clayton:pet2006, + title = {Ignoring the Great Firewall of China}, + author = {Richard Clayton and Steven J. Murdoch and Robert N. M. Watson}, + booktitle = {Proceedings of the Sixth Workshop on Privacy Enhancing Technologies (PET 2006)}, + year = {2006}, + month = {June}, + address = {Cambridge, UK}, + publisher = {Springer}, + bookurl = {http://petworkshop.org/2006/%7D, + note = {\url{http://www.cl.cam.ac.uk/~rnc1/ignoring.pdf%7D%7D, +} + +@Misc{zuckerman-threatmodels, + key = {zuckerman-threatmodels}, + title = {We've got to adjust some of our threat models}, + author = {Ethan Zuckerman}, + note = {\url{http://www.ethanzuckerman.com/blog/?p=1019%7D%7D +} + +@Misc{cgiproxy, + key = {cgiproxy}, + title = {{CGIProxy: HTTP/FTP Proxy in a CGI Script}}, + author = {James Marshall}, + note = {\url{http://www.jmarshall.com/tools/cgiproxy/%7D%7D +} + +@Misc{circumventor, + key = {circumventor}, + title = {{How to install the Circumventor program}}, + author = {Bennett Haselton}, + note = {\url{http://www.peacefire.org/circumventor/simple-circumventor-instructions.html%... +} + +@Misc{psiphon, + key = {psiphon}, + title = {Psiphon}, + author = {Ronald Deibert et al}, + note = {\url{http://psiphon.civisec.org/%7D%7D +} + +@InProceedings{tcpstego, author = {Steven J. Murdoch and Stephen Lewis}, + title = {Embedding Covert Channels into {TCP/IP}}, + booktitle = {Information Hiding: 7th International Workshop}, + pages = {247--261}, + year = {2005}, + editor = {Mauro Barni and Jordi Herrera-Joancomart'{\i} and +Stefan Katzenbeisser and Fernando P'{e}rez-Gonz'{a}lez}, + volume = {3727}, + series = {LNCS}, + address = {Barcelona, Catalonia (Spain)}, + month = {June}, + publisher = {Springer-Verlag}, + url = {http://www.cl.cam.ac.uk/~sjm217/papers/ih05coverttcp.pdf%7D +} + +@phdthesis{blossom-thesis, + title = {Perspective Access Networks}, + author = {Geoffrey Goodell}, + school = {Harvard University}, + year = {2006}, + month = {July}, + note = {\url{http://afs.eecs.harvard.edu/~goodell/thesis.pdf%7D%7D, +} + +@inproceedings{tap:pet2006, + title = {On the Security of the Tor Authentication Protocol}, + author = {Ian Goldberg}, + booktitle = {Proceedings of the Sixth Workshop on Privacy Enhancing Technologies (PET 2006)}, + year = {2006}, + month = {June}, + address = {Cambridge, UK}, + publisher = {Springer}, + bookurl = {http://petworkshop.org/2006/%7D, + note = {\url{http://www.cypherpunks.ca/~iang/pubs/torsec.pdf%7D%7D, +} + +@inproceedings{rep-anon, + title = {{Reputation in P2P Anonymity Systems}}, + author = {Roger Dingledine and Nick Mathewson and Paul Syverson}, + booktitle = {Proceedings of Workshop on Economics of Peer-to-Peer Systems}, + year = {2003}, + month = {June}, + note = {\url{http://freehaven.net/doc/econp2p03/econp2p03.pdf%7D%7D, +} + +@misc{tor-challenges, + author = {Roger Dingledine and Nick Mathewson and Paul Syverson}, + title = {Challenges in deploying low-latency anonymity}, + year = {2005}, + note = {Manuscript} +} + +@InProceedings{chaum-blind, + author = {David Chaum}, + title = {Blind Signatures for Untraceable Payments}, + booktitle = {Advances in Cryptology: Proceedings of Crypto 82}, + pages = {199--203}, + year = 1983, + editor = {D. Chaum and R.L. Rivest and A.T. Sherman}, + publisher = {Plenum Press} +} + +@Article{netauth, + author = {Geoffrey Goodell and Paul Syverson}, + title = {The Right Place at the Right Time: Examining the use of network location in authentication and abuse prevention}, + journal = {Communications of the ACM}, + year = 2007, + volume = 50, + number = 5, + pages = {113--117}, + month = {May} +} + +@misc{ip-to-country, + key = {ip-to-country}, + title = {IP-to-country database}, + note = {\url{http://ip-to-country.webhosting.info/%7D%7D, +} + +@misc{mackinnon-personal, + author = {Rebecca MacKinnon}, + title = {Private communication}, + year = {2006}, +} + +@inproceedings{pet05-bissias, + title = {Privacy Vulnerabilities in Encrypted HTTP Streams}, + author = {George Dean Bissias and Marc Liberatore and Brian Neil Levine}, + booktitle = {Proceedings of Privacy Enhancing Technologies workshop (PET 2005)}, + year = {2005}, + month = {May}, + note = {\url{http://prisms.cs.umass.edu/brian/pubs/bissias.liberatore.pet.2005.pdf%7D%7D, +} + +@InProceedings{infranet, + author = {Nick Feamster and Magdalena Balazinska and Greg Harfst and Hari Balakrishnan and David Karger}, + title = {Infranet: Circumventing Web Censorship and Surveillance}, + booktitle = {Proceedings of the 11th USENIX Security Symposium}, + year = {2002}, + month = {August}, + note = {\url{http://nms.lcs.mit.edu/~feamster/papers/usenixsec2002.pdf%7D%7D, +} + +@techreport{ ptacek98insertion, + author = "Thomas H. Ptacek and Timothy N. Newsham", + title = "Insertion, Evasion, and Denial of Service: Eluding Network Intrusion Detection", + institution = "Secure Networks, Inc.", + address = "Suite 330, 1201 5th Street S.W, Calgary, Alberta, Canada, T2R-0Y6", + year = "1998", + url = "citeseer.ist.psu.edu/ptacek98insertion.html", +} + +@inproceedings{active-wardens, + author = "Gina Fisk and Mike Fisk and Christos Papadopoulos and Joshua Neil", + title = "Eliminating Steganography in Internet Traffic with Active Wardens", + booktitle = {Information Hiding Workshop (IH 2002)}, + year = {2002}, + month = {October}, + editor = {Fabien Petitcolas}, + publisher = {Springer-Verlag, LNCS 2578}, +} + +@inproceedings{clog-the-queue, + title = {Don't Clog the Queue: Circuit Clogging and Mitigation in {P2P} anonymity schemes}, + author = {Jon McLachlan and Nicholas Hopper}, + booktitle = {Proceedings of Financial Cryptography (FC '08)}, + year = {2008}, + month = {January}, +} + +@inproceedings{snader08, + title = {A Tune-up for {Tor}: Improving Security and Performance in the {Tor} Network}, + author = {Robin Snader and Nikita Borisov}, + booktitle = {Proceedings of the Network and Distributed Security Symposium - {NDSS} '08}, + year = {2008}, + month = {February}, + publisher = {Internet Society}, +} + +@inproceedings{murdoch-pet2008, + title = {Metrics for Security and Performance in Low-Latency Anonymity Networks}, + author = {Steven J. Murdoch and Robert N. M. Watson}, + booktitle = {Proceedings of the Eighth International Symposium on Privacy Enhancing Technologies (PETS 2008)}, + year = {2008}, + month = {July}, + address = {Leuven, Belgium}, + pages = {115--132}, + editor = {Nikita Borisov and Ian Goldberg}, + publisher = {Springer}, + bookurl = {http://petsymposium.org/2008/%7D, +} + +@inproceedings{danezis-pet2008, + title = {Bridging and Fingerprinting: Epistemic Attacks on Route Selection}, + author = {George Danezis and Paul Syverson}, + booktitle = {Proceedings of the Eighth International Symposium on Privacy Enhancing Technologies (PETS 2008)}, + year = {2008}, + month = {July}, + address = {Leuven, Belgium}, + pages = {133--150}, + editor = {Nikita Borisov and Ian Goldberg}, + publisher = {Springer}, + bookurl = {http://petsymposium.org/2008/%7D, +} + +%%% Local Variables: +%%% mode: latex +%%% TeX-master: "tor-design" +%%% End: diff --git a/2006/blocking/usenixsubmit.cls b/2006/blocking/usenixsubmit.cls new file mode 100644 index 0000000..743ffcf --- /dev/null +++ b/2006/blocking/usenixsubmit.cls @@ -0,0 +1,7 @@ +% Created by Anil Somayaji + +\ProvidesClass{usenixsubmit} +\LoadClass[11pt,letterpaper]{article} +\usepackage{times} +\usepackage[margin=1in]{geometry} +