From c928b85cfa17c6f03aeeaa10fd284b0cc15bcf93 Mon Sep 17 00:00:00 2001 From: Roger Dingledine Date: Wed, 25 Oct 2006 04:30:58 +0000 Subject: [PATCH] another paragraph of pessimism for the network signature section svn:r8827 --- doc/design-paper/blocking.tex | 21 ++++++++++++++++++--- 1 file changed, 18 insertions(+), 3 deletions(-) diff --git a/doc/design-paper/blocking.tex b/doc/design-paper/blocking.tex index 9ff7d25589..4ac5edd17a 100644 --- a/doc/design-paper/blocking.tex +++ b/doc/design-paper/blocking.tex @@ -574,8 +574,9 @@ for all transactions (and how to know that the pages you get have not been modified by the local attacker) to how to learn about a working bridge relay. -There's another catch though. We need to make sure that simply connecting -to a bridge relay doesn't set off red flags. +There's another catch though. We need to make sure that the network +traffic we generate by simply connecting to a bridge relay doesn't stand +out too much. %The following section describes ways to bootstrap knowledge of your first %bridge relay, and ways to maintain connectivity once you know a few @@ -633,7 +634,7 @@ in the certificate headers, yet it remains secure. Should we replace it with blank entries for each field, or should we research the common values that Firefox and Internet Explorer use and try to imitate those? -Lastly, Tor's TLS handshake involves sending two certificates in each +Worse, Tor's TLS handshake involves sending two certificates in each direction: one certificate contains the self-signed identity key for the router, and the second contains the current link key, signed by the identity key. We use these to authenticate that we're talking to the right @@ -646,6 +647,20 @@ certificates we present for each side. % for really, and how much work would it be to start acting like a normal % browser? -RD +Lastly, what if the adversary starts observing the network traffic even +more closely? Even if our TLS handshake looks innocent, our traffic timing +and volume still look different than a user making a secure web connection +to his bank. The same techniques used in the growing trend to build tools +to recognize encrypted Bittorrent traffic~\cite{bt-traffic-shaping} +could be used to identify Tor communication and recognize bridge +relays. Rather than trying to look like encrypted web traffic, we may be +better off trying to blend with some other encrypted network protocol. The +first step is to compare typical network behavior for a Tor client to +typical network behavior for various other protocols. This statistical +cat-and-mouse game is made more complex by the fact that Tor transports a +variety of protocols, and we'll want to automatically handle web browsing +differently from, say, instant messaging. + \subsection{Identity keys as part of addressing information} We have described a way for the blocked user to bootstrap into the -- 2.11.4.GIT