mirror of
https://gitlab.torproject.org/tpo/core/tor.git
synced 2024-09-20 21:16:22 +02:00
commit for nick
i'm now only working on 8-9 svn:r754
This commit is contained in:
parent
9944853468
commit
18a7e51eb2
@ -459,10 +459,6 @@ SSH.
|
|||||||
Similarly, Tor does not currently integrate
|
Similarly, Tor does not currently integrate
|
||||||
tunneling for non-stream-based protocols like UDP; this too must be
|
tunneling for non-stream-based protocols like UDP; this too must be
|
||||||
provided by an external service.
|
provided by an external service.
|
||||||
% Actually, tunneling udp over tcp is probably horrible for some apps.
|
|
||||||
% Should this get its own non-goal bulletpoint? The motivation for
|
|
||||||
% non-goal-ness would be burden on clients / portability. -RD
|
|
||||||
% No, leave it as is. -RD
|
|
||||||
|
|
||||||
\textbf{Not steganographic:} Tor does not try to conceal which users are
|
\textbf{Not steganographic:} Tor does not try to conceal which users are
|
||||||
sending or receiving communications; it only tries to conceal with whom
|
sending or receiving communications; it only tries to conceal with whom
|
||||||
@ -534,8 +530,6 @@ establish paths (called \emph{virtual circuits}) across the network,
|
|||||||
and handle connections from user applications. These onion proxies accept
|
and handle connections from user applications. These onion proxies accept
|
||||||
TCP streams and multiplex them across the virtual circuit. The onion
|
TCP streams and multiplex them across the virtual circuit. The onion
|
||||||
router on the other side
|
router on the other side
|
||||||
% I don't mean other side, I mean wherever it is on the circuit. But
|
|
||||||
% don't want to introduce complexity this early? Hm. -RD
|
|
||||||
of the circuit connects to the destinations of
|
of the circuit connects to the destinations of
|
||||||
the TCP streams and relays data.
|
the TCP streams and relays data.
|
||||||
|
|
||||||
@ -558,6 +552,7 @@ built, extended, truncated, and destroyed. Section~\ref{subsec:tcp}
|
|||||||
describes how TCP streams are routed through the network, and finally
|
describes how TCP streams are routed through the network, and finally
|
||||||
Section~\ref{subsec:congestion} talks about congestion control and
|
Section~\ref{subsec:congestion} talks about congestion control and
|
||||||
fairness issues.
|
fairness issues.
|
||||||
|
% NICK
|
||||||
% XXX \ref{subsec:integrity-checking} is missing
|
% XXX \ref{subsec:integrity-checking} is missing
|
||||||
% XXX \ref{xubsec:rate-limit is missing.
|
% XXX \ref{xubsec:rate-limit is missing.
|
||||||
|
|
||||||
@ -708,8 +703,6 @@ corresponds to an open stream at this OR for the circuit, or because
|
|||||||
it is equal to the control streamID (zero). If the OR recognizes the
|
it is equal to the control streamID (zero). If the OR recognizes the
|
||||||
streamID, it accepts the relay cell and processes it as described
|
streamID, it accepts the relay cell and processes it as described
|
||||||
below. Otherwise,
|
below. Otherwise,
|
||||||
%the relay cell must be intended for another OR on
|
|
||||||
%the circuit. In this case,
|
|
||||||
the OR looks up the circID and OR for the
|
the OR looks up the circID and OR for the
|
||||||
next step in the circuit, replaces the circID as appropriate, and
|
next step in the circuit, replaces the circID as appropriate, and
|
||||||
sends the decrypted relay cell to the next OR. (If the OR at the end
|
sends the decrypted relay cell to the next OR. (If the OR at the end
|
||||||
@ -756,9 +749,6 @@ truncate} cell to a single OR on the circuit. That node then sends a
|
|||||||
\emph{relay truncated} cell. Alice can then extend the circuit to
|
\emph{relay truncated} cell. Alice can then extend the circuit to
|
||||||
different nodes, all without signaling to the intermediate nodes (or
|
different nodes, all without signaling to the intermediate nodes (or
|
||||||
somebody observing them) that she has changed her circuit.
|
somebody observing them) that she has changed her circuit.
|
||||||
%---because
|
|
||||||
%nodes in the middle of a circuit see only the encrypted relay cells,
|
|
||||||
%they are not even aware that the circuit has been truncated.
|
|
||||||
Similarly, if a node on the circuit goes down, the adjacent
|
Similarly, if a node on the circuit goes down, the adjacent
|
||||||
node can send a \emph{relay truncated} cell back to Alice. Thus the
|
node can send a \emph{relay truncated} cell back to Alice. Thus the
|
||||||
``break a node and see which circuits go down'' attack
|
``break a node and see which circuits go down'' attack
|
||||||
@ -877,13 +867,6 @@ receive a bad hash.
|
|||||||
Volunteers are generally more willing to run services that can limit
|
Volunteers are generally more willing to run services that can limit
|
||||||
their bandwidth usage. To accommodate them, Tor servers use a
|
their bandwidth usage. To accommodate them, Tor servers use a
|
||||||
token bucket approach \cite{tannenbaum96} to
|
token bucket approach \cite{tannenbaum96} to
|
||||||
%limit the number of bytes they receive.
|
|
||||||
%Tokens are added to the bucket each second; when the bucket is
|
|
||||||
%full, new tokens are discarded. Each token represents permission to
|
|
||||||
%accept one byte from the network---to accept a byte, the connection
|
|
||||||
%must remove a token from the bucket. Thus if the bucket is empty, that
|
|
||||||
%connection must wait until more tokens arrive. The number of tokens we
|
|
||||||
%add
|
|
||||||
enforce a long-term average rate of incoming bytes, while still
|
enforce a long-term average rate of incoming bytes, while still
|
||||||
permitting short-term bursts above the allowed bandwidth. Current bucket
|
permitting short-term bursts above the allowed bandwidth. Current bucket
|
||||||
sizes are set to ten seconds' worth of traffic.
|
sizes are set to ten seconds' worth of traffic.
|
||||||
@ -899,20 +882,10 @@ sizes are set to ten seconds' worth of traffic.
|
|||||||
Because the Tor protocol generates roughly the same number of outgoing
|
Because the Tor protocol generates roughly the same number of outgoing
|
||||||
bytes as incoming bytes, it is sufficient in practice to limit only
|
bytes as incoming bytes, it is sufficient in practice to limit only
|
||||||
incoming bytes.
|
incoming bytes.
|
||||||
% Is it? Fun attack: I send you lots of 1-byte-at-a-time TCP segments.
|
|
||||||
% In response, you send lots of 256 byte cells. Can I use this to
|
|
||||||
% make you exceed your outgoing bandwidth limit by a factor of 256? -NM
|
|
||||||
% Can we resolve this by, when reading from edge connections, rounding up
|
|
||||||
% the bytes read (wrt buckets) to the nearest multiple of 256? -RD
|
|
||||||
% How's this? -NM
|
|
||||||
With TCP streams, however, the correspondence is not one-to-one:
|
With TCP streams, however, the correspondence is not one-to-one:
|
||||||
relaying a single incoming byte can require an entire 256-byte cell.
|
relaying a single incoming byte can require an entire 256-byte cell.
|
||||||
(We can't just wait for more bytes, because the local application may
|
(We can't just wait for more bytes, because the local application may
|
||||||
be waiting for a reply.)
|
be waiting for a reply.) Therefore, we treat this case as if the entire
|
||||||
%(If we waited too long for more bytes to fill the cell, we might stall
|
|
||||||
%the protocol while the local application waits for a response to the
|
|
||||||
%byte we never deliver.)
|
|
||||||
Therefore, we treat this case as if the entire
|
|
||||||
cell size had been read, regardless of the fullness of the cell.
|
cell size had been read, regardless of the fullness of the cell.
|
||||||
|
|
||||||
Further, inspired by Rennhard et al's design in \cite{anonnet}, a
|
Further, inspired by Rennhard et al's design in \cite{anonnet}, a
|
||||||
@ -1327,7 +1300,6 @@ to selected users for consulting the DHT\@. All of these approaches
|
|||||||
have the advantage of limiting the damage that can be done even if
|
have the advantage of limiting the damage that can be done even if
|
||||||
some of the selected high-priority users collude in the DoS\@.
|
some of the selected high-priority users collude in the DoS\@.
|
||||||
|
|
||||||
|
|
||||||
\SubSection{Integration with user applications}
|
\SubSection{Integration with user applications}
|
||||||
|
|
||||||
Bob configures his onion proxy to know the local IP address and port of his
|
Bob configures his onion proxy to know the local IP address and port of his
|
||||||
@ -1453,10 +1425,12 @@ current evidence of their practicality.}
|
|||||||
|
|
||||||
\subsubsection*{Active attacks}
|
\subsubsection*{Active attacks}
|
||||||
|
|
||||||
\emph{Compromise keys.} An attacker who learns the TLS session key can see
|
\emph{Compromise keys.} An attacker who learns the TLS session key can
|
||||||
the (still encrypted) relay cells on that circuit; learning the circuit
|
see control cells and encrypted relay cells on every circuit on that
|
||||||
|
connection; learning a circuit
|
||||||
session key lets him unwrap one layer of the encryption. An attacker
|
session key lets him unwrap one layer of the encryption. An attacker
|
||||||
who learns an OR's TLS private key can impersonate that OR, but he must
|
who learns an OR's TLS private key can impersonate that OR for the TLS
|
||||||
|
key's lifetime, but he must
|
||||||
also learn the onion key to decrypt \emph{create} cells (and because of
|
also learn the onion key to decrypt \emph{create} cells (and because of
|
||||||
perfect forward secrecy, he cannot hijack already established circuits
|
perfect forward secrecy, he cannot hijack already established circuits
|
||||||
without also compromising their session keys). Periodic key rotation
|
without also compromising their session keys). Periodic key rotation
|
||||||
@ -1866,12 +1840,15 @@ issues remaining to be ironed out. In particular:
|
|||||||
deployability has led us to adopt a clique topology, a
|
deployability has led us to adopt a clique topology, a
|
||||||
semi-centralized model for directories and trusts, and a
|
semi-centralized model for directories and trusts, and a
|
||||||
full-network-visibility model for client knowledge. None of these
|
full-network-visibility model for client knowledge. None of these
|
||||||
properties will scale to more than a few hundred servers, at most.
|
properties will scale to more than a few hundred servers.
|
||||||
Promising approaches to better scalability exist (see
|
Promising approaches to better scalability exist (see
|
||||||
Section~\ref{sec:maintaining-anonymity}), but more deployment
|
Section~\ref{sec:maintaining-anonymity}), but more deployment
|
||||||
experience would be helpful in learning the relative importance of
|
experience would be helpful in learning the relative importance of
|
||||||
these bottlenecks.
|
these bottlenecks.
|
||||||
|
|
||||||
|
\emph{Incentives:} Volunteers may want to run nodes for publicity
|
||||||
|
or better anonymity \cite{econymics}.
|
||||||
|
|
||||||
\emph{Cover traffic:} Currently we avoid cover traffic because
|
\emph{Cover traffic:} Currently we avoid cover traffic because
|
||||||
whereas its costs in performance and bandwidth are clear, and because its
|
whereas its costs in performance and bandwidth are clear, and because its
|
||||||
security benefits are not well understood. With more research
|
security benefits are not well understood. With more research
|
||||||
@ -1902,7 +1879,7 @@ becomes more widely deployed, more people will examine its
|
|||||||
specification.
|
specification.
|
||||||
|
|
||||||
\emph{Multisystem interoperability:} We are currently working with the
|
\emph{Multisystem interoperability:} We are currently working with the
|
||||||
designers of MorphMix to make the common elements of our two systems
|
designer of MorphMix to make the common elements of our two systems
|
||||||
share a common specification and implementation. So far, this seems
|
share a common specification and implementation. So far, this seems
|
||||||
to be relatively straightforward. Interoperability will allow testing
|
to be relatively straightforward. Interoperability will allow testing
|
||||||
and direct comparison of the two designs for trust and scalability.
|
and direct comparison of the two designs for trust and scalability.
|
||||||
|
Loading…
Reference in New Issue
Block a user