[or-cvs] r10169: a bit of that manual hacking for tor-design.html too (tor/trunk/doc/design-paper)
arma at seul.org
arma at seul.org
Sat May 12 02:29:16 UTC 2007
Author: arma
Date: 2007-05-11 22:29:10 -0400 (Fri, 11 May 2007)
New Revision: 10169
Modified:
tor/trunk/doc/design-paper/tor-design.html
Log:
a bit of that manual hacking for tor-design.html too
Modified: tor/trunk/doc/design-paper/tor-design.html
===================================================================
--- tor/trunk/doc/design-paper/tor-design.html 2007-05-12 02:26:46 UTC (rev 10168)
+++ tor/trunk/doc/design-paper/tor-design.html 2007-05-12 02:29:10 UTC (rev 10169)
@@ -49,8 +49,8 @@
<div class="p"><!----></div>
<h2><a name="tth_sEc1">
+<a name="sec:intro">
1</a> Overview</h2>
-<a name="sec:intro">
</a>
<div class="p"><!----></div>
@@ -92,7 +92,7 @@
<div class="p"><!----></div>
<b>Separation of "protocol cleaning" from anonymity:</b>
Onion Routing originally required a separate "application
-proxy" for each supported application protocol-most of which were
+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 [<a href="#socks4" name="CITEsocks4">32</a>] proxy interface, allowing
us to support most TCP-based programs without modification. Tor now
@@ -130,7 +130,7 @@
<b>Leaky-pipe circuit topology:</b> Through in-band signaling
within the circuit, Tor initiators can direct traffic to nodes partway
down the circuit. This novel approach
-allows traffic to exit the circuit from the middle-possibly
+allows traffic to exit the circuit from the middle — possibly
frustrating traffic shape and volume attacks based on observing the end
of the circuit. (It also allows for long-range padding if
future research shows this to be worthwhile.)
@@ -146,7 +146,7 @@
<div class="p"><!----></div>
<b>Directory servers:</b> The earlier Onion Routing design
-planned to flood state information through the network-an approach
+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 <em>directory
servers</em>: they provide signed directories describing known
@@ -164,7 +164,7 @@
<div class="p"><!----></div>
<b>End-to-end integrity checking:</b> The original Onion Routing
design did no integrity checking on data. Any node on the
-circuit could change the contents of data cells as they passed by-for
+circuit could change the contents of data cells as they passed by — for
example, to alter a connection request so it would connect
to a different webserver, or to `tag' encrypted traffic and look for
corresponding corrupted traffic at the network edges [<a href="#minion-design" name="CITEminion-design">15</a>].
@@ -218,8 +218,8 @@
<div class="p"><!----></div>
<h2><a name="tth_sEc2">
+<a name="sec:related-work">
2</a> Related work</h2>
-<a name="sec:related-work">
</a>
<div class="p"><!----></div>
@@ -377,8 +377,8 @@
<div class="p"><!----></div>
<h2><a name="tth_sEc3">
+<a name="sec:assumptions">
3</a> Design goals and assumptions</h2>
-<a name="sec:assumptions">
</a>
<div class="p"><!----></div>
@@ -404,7 +404,7 @@
however; see Section <a href="#sec:rendezvous">5</a>.)
<div class="p"><!----></div>
-<b>Usability:</b> A hard-to-use system has fewer users-and because
+<b>Usability:</b> A hard-to-use system has fewer users — and because
anonymity systems hide users among users, a system with fewer users
provides less anonymity. Usability is thus not only a convenience:
it is a security requirement [<a href="#econymics" name="CITEeconymics">1</a>,<a href="#back01" name="CITEback01">5</a>]. Tor should
@@ -474,8 +474,8 @@
<div class="p"><!----></div>
<h3><a name="tth_sEc3.1">
+<a name="subsec:threat-model">
3.1</a> Threat Model</h3>
-<a name="subsec:threat-model">
</a>
<div class="p"><!----></div>
@@ -504,7 +504,7 @@
Our adversary might try to link an initiator Alice with her
communication partners, or try to build a profile of Alice's
behavior. He might mount passive attacks by observing the network edges
-and correlating traffic entering and leaving the network-by
+and correlating traffic entering and leaving the network — by
relationships in packet timing, volume, or externally visible
user-selected
options. The adversary can also mount active attacks by compromising
@@ -516,7 +516,7 @@
detected. The adversary might subvert the directory servers to give users
differing views of network state. Additionally, he can try to decrease
the network's reliability by attacking nodes or by performing antisocial
-activities from reliable nodes and trying to get them taken down-making
+activities from reliable nodes and trying to get them taken down — making
the network unreliable flushes users to other less anonymous
systems, where they may be easier to attack. We summarize
in Section <a href="#sec:attacks">7</a> how well the Tor design defends against
@@ -526,8 +526,8 @@
<div class="p"><!----></div>
<h2><a name="tth_sEc4">
+<a name="sec:design">
4</a> The Tor Design</h2>
-<a name="sec:design">
</a>
<div class="p"><!----></div>
@@ -570,8 +570,8 @@
<div class="p"><!----></div>
<h3><a name="tth_sEc4.1">
+<a name="subsec:cells">
4.1</a> Cells</h3>
-<a name="subsec:cells">
</a>
<div class="p"><!----></div>
@@ -627,8 +627,8 @@
</center>
<div class="p"><!----></div>
<h3><a name="tth_sEc4.2">
+<a name="subsec:circuits">
4.2</a> Circuits and streams</h3>
-<a name="subsec:circuits">
</a>
<div class="p"><!----></div>
@@ -662,8 +662,9 @@
</a>
</center>
<div class="p"><!----></div>
-<font size="+1"><b>Constructing a circuit</b></font><a name="subsubsec:constructing-a-circuit">
-</a><br />
+<a name="subsubsec:constructing-a-circuit"></a>
+<font size="+1"><b>Constructing a circuit</b></font>
+<br />
A user's OP constructs circuits incrementally, negotiating a
symmetric key with each OR on the circuit, one hop at a time. To begin
creating a new circuit, the OP (call her Alice) sends a
@@ -704,7 +705,7 @@
<div class="p"><!----></div>
This circuit-level handshake protocol achieves unilateral entity
authentication (Alice knows she's handshaking with the OR, but
-the OR doesn't care who is opening the circuit-Alice uses no public key
+the OR doesn't care who is opening the circuit — Alice uses no public key
and remains anonymous) and unilateral key authentication
(Alice and the OR agree on a key, and Alice knows only the OR learns
it). It also achieves forward
@@ -797,8 +798,8 @@
<div class="p"><!----></div>
<h3><a name="tth_sEc4.3">
+<a name="subsec:tcp">
4.3</a> Opening and closing streams</h3>
-<a name="subsec:tcp">
</a>
<div class="p"><!----></div>
@@ -818,7 +819,7 @@
the chosen OR.
<div class="p"><!----></div>
-There's a catch to using SOCKS, however-some applications pass the
+There's a catch to using SOCKS, however — some applications pass the
alphanumeric hostname to the Tor client, while others resolve it into
an IP address first and then pass the IP address to the Tor client. If
the application does DNS resolution first, Alice thereby reveals her
@@ -855,8 +856,8 @@
<div class="p"><!----></div>
<h3><a name="tth_sEc4.4">
+<a name="subsec:integrity-checking">
4.4</a> Integrity checking on streams</h3>
-<a name="subsec:integrity-checking">
</a>
<div class="p"><!----></div>
@@ -920,8 +921,8 @@
<div class="p"><!----></div>
<h3><a name="tth_sEc4.5">
+<a name="subsec:rate-limit">
4.5</a> Rate limiting and fairness</h3>
-<a name="subsec:rate-limit">
</a>
<div class="p"><!----></div>
@@ -955,8 +956,8 @@
<div class="p"><!----></div>
<h3><a name="tth_sEc4.6">
+<a name="subsec:congestion">
4.6</a> Congestion control</h3>
-<a name="subsec:congestion">
</a>
<div class="p"><!----></div>
@@ -1018,8 +1019,8 @@
<div class="p"><!----></div>
<h2><a name="tth_sEc5">
+<a name="sec:rendezvous">
5</a> Rendezvous Points and hidden services</h2>
-<a name="sec:rendezvous">
</a>
<div class="p"><!----></div>
@@ -1144,7 +1145,7 @@
the Tor rendezvous system.
<div class="p"><!----></div>
-Bob's introduction points are themselves subject to DoS-he must
+Bob's introduction points are themselves subject to DoS — he must
open many introduction points or risk such an attack.
He can provide selected users with a current list or future schedule of
unadvertised introduction points;
@@ -1170,7 +1171,7 @@
and doesn't even know that it's hidden behind the Tor network.
<div class="p"><!----></div>
-Alice's applications also work unchanged-her client interface
+Alice's applications also work unchanged — her client interface
remains a SOCKS proxy. We encode all of the necessary information
into the fully qualified domain name (FQDN) Alice uses when establishing her
connection. Location-hidden services use a virtual top level domain
@@ -1205,20 +1206,20 @@
services. Tor's introduction points do not output any bytes to the
clients; the rendezvous points don't know the client or the server,
and can't read the data being transmitted. The indirection scheme is
-also designed to include authentication/authorization-if Alice doesn't
+also designed to include authentication/authorization — if Alice doesn't
include the right cookie with her request for service, Bob need not even
acknowledge his existence.
<div class="p"><!----></div>
<h2><a name="tth_sEc6">
+<a name="sec:other-design">
6</a> Other design decisions</h2>
-<a name="sec:other-design">
</a>
<div class="p"><!----></div>
<h3><a name="tth_sEc6.1">
+<a name="subsec:dos">
6.1</a> Denial of service</h3>
-<a name="subsec:dos">
</a>
<div class="p"><!----></div>
@@ -1270,8 +1271,8 @@
<div class="p"><!----></div>
<h3><a name="tth_sEc6.2">
+<a name="subsec:exitpolicies">
6.2</a> Exit policies and abuse</h3>
-<a name="subsec:exitpolicies">
</a>
<div class="p"><!----></div>
@@ -1304,7 +1305,7 @@
nodes that only relay traffic to other Tor nodes, and <em>private exit</em>
nodes that only connect to a local host or network. A private
exit can allow a client to connect to a given host or
-network more securely-an external adversary cannot eavesdrop traffic
+network more securely — an external adversary cannot eavesdrop traffic
between the private exit and the final destination, and so is less sure of
Alice's destination and activities. Most onion routers in the current
network function as
@@ -1348,7 +1349,7 @@
greater burden on the exit nodes. This tension can be seen in the
Java Anon Proxy
cascade model, wherein only one node in each cascade needs to handle
-abuse complaints-but an adversary only needs to observe the entry
+abuse complaints — but an adversary only needs to observe the entry
and exit of a cascade to perform traffic analysis on all that
cascade's users. The hydra model (many entries, few exits) presents a
different compromise: only a few exit nodes are needed, but an
@@ -1367,8 +1368,8 @@
<div class="p"><!----></div>
<h3><a name="tth_sEc6.3">
+<a name="subsec:dirservers">
6.3</a> Directory Servers</h3>
-<a name="subsec:dirservers">
</a>
<div class="p"><!----></div>
@@ -1403,7 +1404,7 @@
<div class="p"><!----></div>
When a directory server receives a signed statement for an OR, it
checks whether the OR's identity key is recognized. Directory
-servers do not advertise unrecognized ORs-if they did,
+servers do not advertise unrecognized ORs — if they did,
an adversary could take over the network by creating many
servers [<a href="#sybil" name="CITEsybil">22</a>]. Instead, new nodes must be approved by the
directory
@@ -1414,7 +1415,7 @@
<div class="p"><!----></div>
Of course, a variety of attacks remain. An adversary who controls
a directory server can track clients by providing them different
-information-perhaps by listing only nodes under its control, or by
+information — perhaps by listing only nodes under its control, or by
informing only certain clients about a given node. Even an external
adversary can exploit differences in client knowledge: clients who use
a node listed on one directory server but not the others are vulnerable.
@@ -1460,8 +1461,8 @@
<div class="p"><!----></div>
<h2><a name="tth_sEc7">
+<a name="sec:attacks">
7</a> Attacks and Defenses</h2>
-<a name="sec:attacks">
</a>
<div class="p"><!----></div>
@@ -1558,7 +1559,7 @@
keys, the attacker cannot force nodes to decrypt recorded
traffic once the circuits have been closed.) Additionally, building
circuits that cross jurisdictions can make legal coercion
-harder-this phenomenon is commonly called "jurisdictional
+harder — this phenomenon is commonly called "jurisdictional
arbitrage." The Java Anon Proxy project recently experienced the
need for this approach, when
a German court forced them to add a backdoor to
@@ -1580,7 +1581,7 @@
<em>Run an onion proxy.</em> It is expected that end users will
nearly always run their own local onion proxy. However, in some
settings, it may be necessary for the proxy to run
-remotely-typically, in institutions that want
+remotely — typically, in institutions that want
to monitor the activity of those connecting to the proxy.
Compromising an onion proxy compromises all future connections
through it.
@@ -1603,7 +1604,7 @@
some user will choose one of those ORs for the start and another
as the end of a circuit. If an adversary
controls m > 1 of N nodes, he can correlate at most
-([m/N])<sup>2</sup> of the traffic-although an
+([m/N])<sup>2</sup> of the traffic — although an
adversary
could still attract a disproportionately large amount of traffic
by running an OR with a permissive exit policy, or by
@@ -1644,7 +1645,7 @@
<div class="p"><!----></div>
<em>Distribute hostile code.</em> An attacker could trick users
into running subverted Tor software that did not, in fact, anonymize
-their connections-or worse, could trick ORs into running weakened
+their connections — or worse, could trick ORs into running weakened
software that provided users with less anonymity. We address this
problem (but do not solve it completely) by signing all Tor releases
with an official public key, and including an entry in the directory
@@ -1741,8 +1742,8 @@
<div class="p"><!----></div>
<h2><a name="tth_sEc8">
+<a name="sec:in-the-wild">
8</a> Early experiences: Tor in the Wild</h2>
-<a name="sec:in-the-wild">
</a>
<div class="p"><!----></div>
@@ -1751,7 +1752,7 @@
matures. (For comparison, the current remailer network
has about 40 nodes.) Each node has at least a 768Kb/768Kb connection, and
many have 10Mb. The number of users varies (and of course, it's hard to
-tell for sure), but we sometimes have several hundred users-administrators at
+tell for sure), but we sometimes have several hundred users — administrators at
several companies have begun sending their entire departments' web
traffic through Tor, to block other divisions of
their company from reading their traffic. Tor users have reported using
@@ -1766,7 +1767,7 @@
of each 498-byte payload is full for cells going back to the client,
whereas about 40% is full for cells coming from the client. (The difference
arises because most of the network's traffic is web browsing.) Interactive
-traffic like SSH brings down the average a lot-once we have more
+traffic like SSH brings down the average a lot — once we have more
experience, and assuming we can resolve the anonymity issues, we may
partition traffic into two relay cell sizes: one to handle
bulk traffic and one for interactive traffic.
@@ -1779,7 +1780,7 @@
resolve bugs, and get a feel for what users actually want from an
anonymity system. Even though having more users would bolster our
anonymity sets, we are not eager to attract the Kazaa or warez
-communities-we feel that we must build a reputation for privacy, human
+communities — we feel that we must build a reputation for privacy, human
rights, research, and other socially laudable activities.
<div class="p"><!----></div>
@@ -1816,8 +1817,8 @@
<div class="p"><!----></div>
<h2><a name="tth_sEc9">
+<a name="sec:maintaining-anonymity">
9</a> Open Questions in Low-latency Anonymity</h2>
-<a name="sec:maintaining-anonymity">
</a>
<div class="p"><!----></div>
@@ -1913,7 +1914,7 @@
does the method in Section <a href="#subsec:dos">6.1</a> allow streams to survive
node failure? If affected users rebuild circuits immediately, how much
anonymity is lost? It seems the problem is even worse in a peer-to-peer
-environment-such systems don't yet provide an incentive for peers to
+environment — such systems don't yet provide an incentive for peers to
stay connected when they're done retrieving content, so we would expect
a higher churn rate.
@@ -1921,8 +1922,8 @@
<div class="p"><!----></div>
<h2><a name="tth_sEc10">
+<a name="sec:conclusion">
10</a> Future Directions</h2>
-<a name="sec:conclusion">
</a>
<div class="p"><!----></div>
@@ -1955,7 +1956,7 @@
why most people don't bother using privacy systems.
<div class="p"><!----></div>
-<em>Cover traffic:</em> Currently Tor omits cover traffic-its costs
+<em>Cover traffic:</em> Currently Tor omits cover traffic — its costs
in performance and bandwidth are clear but its security benefits are
not well understood. We must pursue more research on link-level cover
traffic and long-range cover traffic to determine whether some simple padding
@@ -2484,3 +2485,4 @@
T<sub><font size="-1">T</font></sub>H</a>,
version 3.59.<br />On 18 May 2004, 10:45.</small>
</body></html>
+
More information about the tor-commits
mailing list