[tor-commits] [tor-design-2012/master] Updates to Introduction

sjm217 at torproject.org sjm217 at torproject.org
Mon Nov 5 18:37:45 UTC 2012


commit 1dd430acb841b2f64ffbad9c1ff9aed655572379
Author: Steven Murdoch <Steven.Murdoch at cl.cam.ac.uk>
Date:   Mon Nov 5 18:12:26 2012 +0000

    Updates to Introduction
---
 tor-design-2012.tex |  100 ++++++++++++++++++++++++++++++++++++--------------
 1 files changed, 72 insertions(+), 28 deletions(-)

diff --git a/tor-design-2012.tex b/tor-design-2012.tex
index 1b74b5e..da7c70b 100644
--- a/tor-design-2012.tex
+++ b/tor-design-2012.tex
@@ -145,10 +145,10 @@ proxy'' for each supported application protocol---most of which
 were never written, so many applications were never supported.
 Tor uses the standard and near-ubiquitous SOCKS~\cite{socks4}
 proxy interface, allowing us to support most TCP-based programs
-without modification.  Tor now relies on the filtering features
-of privacy-enhancing application-level proxies such as
-Privoxy~\cite{privoxy}, without trying to duplicate those
-features itself.
+without modification.  For the protocol cleaning of HTTP and
+HTTPS, Tor relies on Torbutton~\cite{torbutton} (a Firefox
+add-on) and modifications made to the version of Firefox
+delivered to users as part of the Tor Browser Bundle.
 
 \textbf{No mixing, padding, or traffic shaping (yet):} Onion
 Routing originally called for batching and reordering cells as
@@ -177,7 +177,9 @@ every request, and also presented a threat to anonymity from
 building so many circuits; see
 Section~\ref{sec:maintaining-anonymity}.  Tor multiplexes
 multiple TCP streams along each circuit to improve efficiency
-and anonymity.
+and anonymity, but allows the user to control which streams may
+share a circuit with which other streams to prevent unintended
+linking of pseudonyms.
 
 \textbf{Leaky-pipe circuit topology:} Through in-band signaling
 within the circuit, Tor initiators can direct traffic to nodes
@@ -200,16 +202,19 @@ until the congestion subsides.
 % We've been working on this some; we have found that our current approach
 % doesn't work so well. -NM
 
-\textbf{Directory servers:} The earlier Onion Routing design
+\textbf{Directory authorities:} The earlier Onion Routing design
 planned to flood state information through the network---an
 approach that can be unreliable and complex.  Tor takes a
 simplified view toward distributing this information. Certain
-more trusted nodes act as \emph{directory servers}: they provide
-signed directories describing known routers and their current
-state. Users periodically download them via HTTP.
+more trusted nodes act as \emph{directory authorities}: they
+provide signed directories describing known routers and their
+current state. Users periodically download them directly from
+the authorities or from a mirror, via HTTP tunelled over a Tor
+circuit.
 % The above paragraph is almost right.  But the more trusted nodes are called
 % ``authorities'' and we use http-over-tor to fetch stuff.  There's a layer
 % of caches too. -NM
+% Believed done - SJM
 
 \textbf{Variable exit policies:} Tor provides a consistent
 mechanism for each node to advertise a policy describing the
@@ -255,6 +260,29 @@ network stands at 32 nodes spread over two continents.
 % The above figure is wrong; the above paragraph doesn't summarize our status
 % well -NM
 
+\textbf{Censorship resistance:} A growing number of Tor users
+require not only anonymous communications but also censorship
+resistance. Tor circumvents attempts to block access to the
+network by allowing users to access the network via a ``bridge''
+-- a special purpose Tor node which does not appear in the
+directory and whose IP address is only known by a small number
+of individuals to reduce the chance of it being blocked by IP
+address. The Tor protocol has also been designed to be similar
+to HTTPS such that blocking Tor, without blocking HTTPS, is made
+more difficult.
+
+\textbf{Modular architecture:} The Tor program is only one part
+of an effective anonymous communication system and Tor provides
+functionality to integrate with other components to fulfil a
+wide variety of user requirements. The graphical user interface
+is a separate program (Vidalia, in the Tor Browser Bundle, but
+alternatives exist) which communicates with Tor via a local
+socket -- the ``control port''. Special-purpose controllers have
+also been developed by researchers to analyse Tor and prototype
+modifications.  Additional resistance against protocol
+fingerprinting, for the purposes of censorship resistance, may
+be provided by an external ``pluggable transport'' obfuscator. 
+
 We review previous work in Section~\ref{sec:related-work},
 describe our goals and assumptions in
 Section~\ref{sec:assumptions}, and then address the above list
@@ -485,6 +513,15 @@ that integrates the best accepted approaches to protecting
 anonymity.\\
 % Do we keep the above? -NM
 
+\textbf{Resistant to censorship:} Many users will be using an
+anonymous communication system because they are accessing
+websites which may be frowned upon by their country, and so are
+blocked.  Consequently countries may choose to block access to
+the Tor network in order to meet their goal of blocking access
+to the sites in question. Tor should therefore be resistant to
+censorship, both blocking by IP address and blocking as a result
+of protocol fingerprinting.
+
 \noindent{\large\bf Non-goals}\label{subsec:non-goals}\\
 In favoring simple, deployable designs, we have explicitly
 deferred several possible goals, either because they are solved
@@ -505,19 +542,22 @@ Section~\ref{sec:maintaining-anonymity} for more discussion.
 \textbf{No protocol normalization:} Tor does not provide
 \emph{protocol normalization} like Privoxy or the Anonymizer. If
 senders want anonymity from responders while using complex and
-variable protocols like HTTP, Tor must be layered with a
-filtering proxy such as Privoxy to hide differences between
-clients, and expunge protocol features that leak identity.  Note
-that by this separation Tor can also provide services that are
-anonymous to the network yet authenticated to the responder,
-like SSH. Similarly, Tor does not integrate tunneling for
-non-stream-based protocols like UDP; this must be provided by an
-external service if appropriate.
+variable protocols like HTTP or HTTPS, Tor must be layered with a
+specialized web browser to hide differences between clients, and
+expunge protocol features that leak identity.  Note that by this
+separation Tor can also provide services that are anonymous to
+the network yet authenticated to the responder, like SSH.
+Similarly, Tor does not integrate tunneling for non-stream-based
+protocols like UDP; this must be provided by an external service
+if appropriate.
 % Filtering proxies: no!  Specialized browsers: yes! -NM
+% Believed done -SJM
 
-\textbf{Not steganographic:} Tor does not try to conceal who is
-connected to the network.
+%\textbf{Not steganographic:} Tor does not try to conceal who is
+%connected to the network.
 % This is no longer a goal. -NM
+% In fact it is contradictory to ``Resistant to censorship''.
+% Removed -SJM
 
 \subsection{Threat Model}
 \label{subsec:threat-model}
@@ -579,15 +619,17 @@ well the Tor design defends against each of these attacks.
 The Tor network is an overlay network; each onion router (OR)
 runs as a normal user-level process without any special
 privileges.  Each onion router maintains a TLS~\cite{TLS}
-connection to every other onion router.  Each user runs local
-software called an onion proxy (OP) to fetch directories,
-establish circuits across the network, and handle connections
-from user applications.  These onion proxies accept TCP streams
-and multiplex them across the circuits. The onion router on the
-other side of the circuit connects to the requested destinations
-and relays data.
-% Is our topology actually clique any longer? -NM
-% Perhaps mention that the OR and the OP are the same software. -NM
+connection to onion routers to which it has been recently
+communicating with.  Each user runs local software called an
+onion proxy (OP) to fetch directories, establish circuits across
+the network, and handle connections from user applications.
+These onion proxies accept TCP streams and multiplex them across
+the circuits. The onion router on the other side of the circuit
+connects to the requested destinations and relays data.
+% Is our topology actually clique any longer? -NM Perhaps
+% I've changed this to indicate the fact that unused links are
+% timed out -SJM
+% mention that the OR and the OP are the same software. -NM
 
 Each onion router maintains a long-term identity key and a
 short-term onion key. The identity key is used to sign TLS
@@ -2053,3 +2095,5 @@ overall usability.
 %     'Substitute ``Damn'' every time you're inclined to write ``very;'' your
 %     editor will delete it and the writing will be just as it should be.'
 %     -- Mark Twain
+
+% vim:tw=64:ruler





More information about the tor-commits mailing list