mirror of
https://gitlab.torproject.org/tpo/core/tor.git
synced 2024-11-30 15:43:32 +01:00
a bit of that manual hacking for tor-design.html too
svn:r10169
This commit is contained in:
Roger Dingledine
parent
7218188157
commit
6c7ae20ca8
@ -49,8 +49,8 @@ more than 30 nodes. We close with a list of open problems in anonymous communica
|
||||
|
||||
<div class="p"><!----></div>
|
||||
<h2><a name="tth_sEc1">
|
||||
1</a> Overview</h2>
|
||||
<a name="sec:intro">
|
||||
1</a> Overview</h2>
|
||||
</a>
|
||||
|
||||
<div class="p"><!----></div>
|
||||
@ -92,7 +92,7 @@ extending to a new node.
|
||||
<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 @@ streams along each circuit to improve efficiency and anonymity.
|
||||
<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 @@ or flooding and send less data until the congestion subsides.
|
||||
|
||||
<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 @@ from his node.
|
||||
<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 @@ Routing project in Section <a href="#sec:conclusion">10</a>.
|
||||
|
||||
<div class="p"><!----></div>
|
||||
<h2><a name="tth_sEc2">
|
||||
2</a> Related work</h2>
|
||||
<a name="sec:related-work">
|
||||
2</a> Related work</h2>
|
||||
</a>
|
||||
|
||||
<div class="p"><!----></div>
|
||||
@ -377,8 +377,8 @@ Eternity and Free Haven.
|
||||
|
||||
<div class="p"><!----></div>
|
||||
<h2><a name="tth_sEc3">
|
||||
3</a> Design goals and assumptions</h2>
|
||||
<a name="sec:assumptions">
|
||||
3</a> Design goals and assumptions</h2>
|
||||
</a>
|
||||
|
||||
<div class="p"><!----></div>
|
||||
@ -404,7 +404,7 @@ this goal for non-anonymous users talking to hidden servers,
|
||||
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 @@ to the network.
|
||||
|
||||
<div class="p"><!----></div>
|
||||
<h3><a name="tth_sEc3.1">
|
||||
3.1</a> Threat Model</h3>
|
||||
<a name="subsec:threat-model">
|
||||
3.1</a> Threat Model</h3>
|
||||
</a>
|
||||
|
||||
<div class="p"><!----></div>
|
||||
@ -504,7 +504,7 @@ which points in the network he should attack.
|
||||
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 @@ network stops; or by introducing patterns into traffic that can later be
|
||||
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 @@ each of these attacks.
|
||||
|
||||
<div class="p"><!----></div>
|
||||
<h2><a name="tth_sEc4">
|
||||
4</a> The Tor Design</h2>
|
||||
<a name="sec:design">
|
||||
4</a> The Tor Design</h2>
|
||||
</a>
|
||||
|
||||
<div class="p"><!----></div>
|
||||
@ -570,8 +570,8 @@ fairness issues.
|
||||
|
||||
<div class="p"><!----></div>
|
||||
<h3><a name="tth_sEc4.1">
|
||||
4.1</a> Cells</h3>
|
||||
<a name="subsec:cells">
|
||||
4.1</a> Cells</h3>
|
||||
</a>
|
||||
|
||||
<div class="p"><!----></div>
|
||||
@ -627,8 +627,8 @@ in more detail below.
|
||||
</center>
|
||||
<div class="p"><!----></div>
|
||||
<h3><a name="tth_sEc4.2">
|
||||
4.2</a> Circuits and streams</h3>
|
||||
<a name="subsec:circuits">
|
||||
4.2</a> Circuits and streams</h3>
|
||||
</a>
|
||||
|
||||
<div class="p"><!----></div>
|
||||
@ -662,8 +662,9 @@ without harming user experience.<br />
|
||||
</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 @@ extend one hop further.
|
||||
<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 @@ attack [<a href="#freedom21-security" name="CITEfreedom21-security">4</a>]
|
||||
|
||||
<div class="p"><!----></div>
|
||||
<h3><a name="tth_sEc4.3">
|
||||
4.3</a> Opening and closing streams</h3>
|
||||
<a name="subsec:tcp">
|
||||
4.3</a> Opening and closing streams</h3>
|
||||
</a>
|
||||
|
||||
<div class="p"><!----></div>
|
||||
@ -818,7 +819,7 @@ now accepts data from the application's TCP stream, packaging it into
|
||||
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 @@ connections.
|
||||
|
||||
<div class="p"><!----></div>
|
||||
<h3><a name="tth_sEc4.4">
|
||||
4.4</a> Integrity checking on streams</h3>
|
||||
<a name="subsec:integrity-checking">
|
||||
4.4</a> Integrity checking on streams</h3>
|
||||
</a>
|
||||
|
||||
<div class="p"><!----></div>
|
||||
@ -920,8 +921,8 @@ receive a bad hash.
|
||||
|
||||
<div class="p"><!----></div>
|
||||
<h3><a name="tth_sEc4.5">
|
||||
4.5</a> Rate limiting and fairness</h3>
|
||||
<a name="subsec:rate-limit">
|
||||
4.5</a> Rate limiting and fairness</h3>
|
||||
</a>
|
||||
|
||||
<div class="p"><!----></div>
|
||||
@ -955,8 +956,8 @@ attacks.
|
||||
|
||||
<div class="p"><!----></div>
|
||||
<h3><a name="tth_sEc4.6">
|
||||
4.6</a> Congestion control</h3>
|
||||
<a name="subsec:congestion">
|
||||
4.6</a> Congestion control</h3>
|
||||
</a>
|
||||
|
||||
<div class="p"><!----></div>
|
||||
@ -1018,8 +1019,8 @@ and delay; see Section <a href="#sec:in-the-wild">8</a>.
|
||||
|
||||
<div class="p"><!----></div>
|
||||
<h2><a name="tth_sEc5">
|
||||
5</a> Rendezvous Points and hidden services</h2>
|
||||
<a name="sec:rendezvous">
|
||||
5</a> Rendezvous Points and hidden services</h2>
|
||||
</a>
|
||||
|
||||
<div class="p"><!----></div>
|
||||
@ -1144,7 +1145,7 @@ those users can switch to accessing Bob's service via
|
||||
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 @@ by the hash of his public key. Bob's webserver is unmodified,
|
||||
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 @@ service, to encourage volunteers to offer introduction and rendezvous
|
||||
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">
|
||||
6</a> Other design decisions</h2>
|
||||
<a name="sec:other-design">
|
||||
6</a> Other design decisions</h2>
|
||||
</a>
|
||||
|
||||
<div class="p"><!----></div>
|
||||
<h3><a name="tth_sEc6.1">
|
||||
6.1</a> Denial of service</h3>
|
||||
<a name="subsec:dos">
|
||||
6.1</a> Denial of service</h3>
|
||||
</a>
|
||||
|
||||
<div class="p"><!----></div>
|
||||
@ -1270,8 +1271,8 @@ extra complexity still require investigation.
|
||||
|
||||
<div class="p"><!----></div>
|
||||
<h3><a name="tth_sEc6.2">
|
||||
6.2</a> Exit policies and abuse</h3>
|
||||
<a name="subsec:exitpolicies">
|
||||
6.2</a> Exit policies and abuse</h3>
|
||||
</a>
|
||||
|
||||
<div class="p"><!----></div>
|
||||
@ -1304,7 +1305,7 @@ nodes that will connect anywhere. On the other end are <em>middleman</em>
|
||||
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 @@ an adversary needs to monitor for traffic analysis, and places a
|
||||
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 @@ project [<a href="#darkside" name="CITEdarkside">37</a>] give us a glimpse
|
||||
|
||||
<div class="p"><!----></div>
|
||||
<h3><a name="tth_sEc6.3">
|
||||
6.3</a> Directory Servers</h3>
|
||||
<a name="subsec:dirservers">
|
||||
6.3</a> Directory Servers</h3>
|
||||
</a>
|
||||
|
||||
<div class="p"><!----></div>
|
||||
@ -1403,7 +1404,7 @@ to bootstrap each client's view of the network.
|
||||
<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 @@ in Section <a href="#sec:maintaining-anonymity">9</a>.
|
||||
<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 @@ central point.
|
||||
|
||||
<div class="p"><!----></div>
|
||||
<h2><a name="tth_sEc7">
|
||||
7</a> Attacks and Defenses</h2>
|
||||
<a name="sec:attacks">
|
||||
7</a> Attacks and Defenses</h2>
|
||||
</a>
|
||||
|
||||
<div class="p"><!----></div>
|
||||
@ -1558,7 +1559,7 @@ be completed. (Thanks to the perfect forward secrecy of session
|
||||
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 @@ to solve this latter problem.
|
||||
<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 @@ that those ORs are trustworthy and independent, then occasionally
|
||||
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 @@ some political heat.
|
||||
<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 @@ with a session key shared by Alice and Bob.
|
||||
|
||||
<div class="p"><!----></div>
|
||||
<h2><a name="tth_sEc8">
|
||||
8</a> Early experiences: Tor in the Wild</h2>
|
||||
<a name="sec:in-the-wild">
|
||||
8</a> Early experiences: Tor in the Wild</h2>
|
||||
</a>
|
||||
|
||||
<div class="p"><!----></div>
|
||||
@ -1751,7 +1752,7 @@ As of mid-May 2004, the Tor network consists of 32 nodes
|
||||
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 @@ cells (a bit under half a gigabyte) per week. On average, about 80%
|
||||
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 @@ issues since the network was deployed in October
|
||||
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 @@ topology will help us choose among alternatives when the time comes.
|
||||
|
||||
<div class="p"><!----></div>
|
||||
<h2><a name="tth_sEc9">
|
||||
9</a> Open Questions in Low-latency Anonymity</h2>
|
||||
<a name="sec:maintaining-anonymity">
|
||||
9</a> Open Questions in Low-latency Anonymity</h2>
|
||||
</a>
|
||||
|
||||
<div class="p"><!----></div>
|
||||
@ -1913,7 +1914,7 @@ Will users abandon the system because of this brittleness? How well
|
||||
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 @@ a higher churn rate.
|
||||
|
||||
<div class="p"><!----></div>
|
||||
<h2><a name="tth_sEc10">
|
||||
10</a> Future Directions</h2>
|
||||
<a name="sec:conclusion">
|
||||
10</a> Future Directions</h2>
|
||||
</a>
|
||||
|
||||
<div class="p"><!----></div>
|
||||
@ -1955,7 +1956,7 @@ we need to explore more approaches to limiting abuse, and understand
|
||||
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 @@ by <a href="http://hutchinson.belmont.ma.us/tth/">
|
||||
T<sub><font size="-1">T</font></sub>H</a>,
|
||||
version 3.59.<br />On 18 May 2004, 10:45.</small>
|
||||
</body></html>
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user