commit f77b7a6e255319c259daf0d060444d2909fd8d3e Author: Nick Mathewson <nickm@torproject.org> Date: Wed Nov 14 01:13:57 2012 -0500 Quick pass to revise the rest of the tor-design section --- tor-design-2012.tex | 57 +++++++++++++++++++++++++-------------------------- 1 files changed, 28 insertions(+), 29 deletions(-) diff --git a/tor-design-2012.tex b/tor-design-2012.tex index 38a6eed..43cf08b 100644 --- a/tor-design-2012.tex +++ b/tor-design-2012.tex @@ -1140,8 +1140,11 @@ reply to notify the application of its success. The OP now accepts data from the application's TCP stream, packaging it into \emph{relay data} cells and sending those cells along the circuit to the chosen OR. -% Mention the optimistic data extension: clients can send data before getting -% a relay_connected cell. -NM + +(As an optimization, to avoid a round-trip while waiting for a +connected reply, clients may send data immediately after the +connected cell. The need to be ready to send the same data to +another stream, though, if no connected cell arrives.) There's a catch to using SOCKS, however---some applications pass the alphanumeric hostname to the Tor client, while others @@ -1153,8 +1156,6 @@ resolved at the far end. Common applications like Firefox and SSH need to be configured to use SOCKS4A or SOCKS5 (with the option to send hostnames rather than IP address) to avoid this vulnerability. -% No longer true wrt mozilla and SSH. -NM -% Believed done -SJM With Firefox, the Torbutton add-on ensures that the browser sends requests via Tor by configuring Firefox to correctly use a @@ -1177,12 +1178,10 @@ Other applications, which can be configured to use SOCKS (and send the proxy a hostname rather than IP address), may be connected directly to Tor. Other options available are to intercept calls to the resolver and sockets libraries with -\emph{torsocks} or to use a firewall (Tor supports BSD and -Linux's in-built firewall) to intercept outgoing DNS requests +\emph{torsocks} or to use an operating system firewall's transparent +port-forwarding mechanism (Tor supports BSD and +Linux's in-built port-forwarding) to intercept outgoing DNS requests and TCP connections, sending them via Tor. -% We don't recommend privoxy any more. Proxies are one solution though. But -% for web, we think you need a custom browser. -NM -% Believed done -SJM Closing a Tor stream is analogous to closing a TCP stream: it uses a two-step handshake for normal operation, or a one-step @@ -1216,8 +1215,8 @@ modify data. Addressing the insider malleability attack, however, is more complex. We could do integrity checking of the relay cells at each hop, -either by including hashes or by using an authenticating cipher -mode like EAX~\cite{eax}, but there are some problems. First, +either by including MACs or by using an authenticating cipher +mode like GCM~\cite{gcm}, but there are some problems. First, these approaches impose a message-expansion overhead at each hop, and so we would have to either leak the path length or waste bytes by padding to a maximum path length. Second, these @@ -1228,10 +1227,6 @@ session keys. Third, we have already accepted that our design is vulnerable to end-to-end timing attacks; so tagging attacks performed within the circuit provide no additional information to the attacker. -% This "no additional information to the attacker" claim is less great than -% it might have seemed in 2004. We're looking towards wide-block approaches -% here instead. Also we should really not cite EAX and hashes but probably -% GCM and MACs as the likelier alternatives. -NM Thus, we check integrity only at the edges of each stream. (Remember that in our leaky-pipe circuit topology, a @@ -1244,8 +1239,6 @@ cells they create, and include with each relay cell the first four bytes of the current digest. Each also keeps a SHA-1 digest of data received, to verify that the received hashes are correct. -% Mention that sha-1 is showing its age, and we're moving away from it in our -% next relay protocol. -NM To be sure of removing or modifying a cell, the attacker must be able to deduce the current digest state (which depends on all @@ -1260,6 +1253,17 @@ overhead; the chance that an adversary will correctly guess a valid hash is acceptably low, given that the OP or OR tear down the circuit if they receive a bad hash. +This approach has, however, appeared less robust than we hoped; +while tagging attacks don't provide more information than an +end-to-end attacker could get through passive correlation attacks, +they succeed more quickly. Even that isn't such a big deal, were +it not for a class of attacks that become possible if an attacker +can detect non-corelatable circuits early and kill them (see +\ref{???XXXsomewhere-in-attacks-and-defenses}). We are therefore looking +into improved constructions for integrity, especially ones based +on wide-block ciphers. We hope to also take the opportunity to +move the authentication mechanism away from the moribund SHA-1. + \subsection{Rate limiting and fairness} \label{subsec:rate-limit} @@ -1348,9 +1352,10 @@ cell only when the number of bytes pending to be flushed is under some threshold (currently 10 cells' worth). % I don't believe that the numbers are 1000 and 100 any more. Must check -NM -These arbitrarily chosen parameters seem to give tolerable -throughput and delay; see Section~\ref{sec:in-the-wild}. -% The above paragraph has not held up over time -NM +These arbitrarily chosen parameters give tolerable but not great +throughput and delay; see Section~\ref{sec:in-the-wild}. See also +Section~\ref{????:how-to-really-ratelim} for discussion of future +work directions on the topic. \section{Rendezvous Points and hidden services} \label{sec:rendezvous} @@ -1405,9 +1410,6 @@ community finds objectionable, or if Bob's service tends to get attacked by network vandals). The extra level of indirection also allows Bob to respond to some requests and ignore others. -% Mention that the list of introduction points can now be encrypted. -NM -% Mention user authentication? -NM -% Believed done -SJM \subsection{Rendezvous points in Tor} @@ -1481,7 +1483,7 @@ points available. Bob could also give secret public keys for consulting the lookup service. All of these approaches limit exposure even when some selected users collude in the DoS\@. -% Thiss whole section is dated in ways I don't know off the top of my head. +% Thiss whole section may be dated in ways I don't know off the top of my head. % Gotta review the protocol revisions over the years. -NM @@ -1501,15 +1503,12 @@ 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 called {\tt .onion}: thus -hostnames take the form {\tt x.y.onion} where {\tt x} is the -authorization cookie and {\tt y} encodes the hash of the public +hostnames take the form {\tt y.onion} where +\tt y} encodes the hash of the public key. Alice's onion proxy examines addresses; if they're destined for a hidden server, it decodes the key and starts the rendezvous as described above. -% Authorization cookies never got built, right? it turns out that -% ``x.y.onion'' as a format for conveying them is a bad idea, due to the -% referer headers and stuff like that -NM \subsection{Previous rendezvous work}