mirror of
https://gitlab.torproject.org/tpo/core/tor.git
synced 2024-12-06 19:41:15 +01:00
another paragraph of pessimism for the network signature section
svn:r8827
This commit is contained in:
@@ -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
|
||||
|
||||
Reference in New Issue
Block a user