Sniffing OR-OR connections by rerouting them

[dvorak <dvorak@xxxxxxxxx>]

Hi,

One of the stated vulnerabilities in tor is traffic//timing analysis.
However this requires being able to watch a significant amount of
the traffic in the tor network, which is hard. Below is a description
of a weakness in the tor implementation that makes a traffic//timing
analysis feasable without sniffing a lot of internet nodes.

Tor circuits are build based on OR (Onion router) to OR connections.
An OP (onion proxy) that wants to connect to a webserver through the
tor network selects n (3 in the default configuration) OR's through 
which to route the traffic. For traffic analysis to be feasable we 
need to be able to watch the connection from the OP to the first OR,
the connections from the OR's to each other and the connection from 
the last OR to the webserver.

This attack makes it possible to watch the traffic at the OR to OR
connections (not the OP to the first OR neither from the last OR to
the webserver), so the impact is limited. (We can see all the traffic
inside the tor network but not the connections from the OPs to the ORs
neither that from the OR's to their final destination, so we don't know
who is accessing what).

An OR((I)nitiator) connect to another OR((R)eceiver) on request of the
OP((C)lient). I first checks if it has already a connection to R, by
checking the digest_id of all the OR's I is connected to. If I is
not already connected to R I connects to the host and port specified by C
in the expectation that R is running there. We can let I make an
OR connection to us ((A)ttacker) by specified the host+port of
A instead of the host+port of R. Since I will authenticate R we cannot
imitate R, however we can just relay all the traffic to R so that we
can watch the volumes and timing of the packets going in both directions.

Any other client that builds a circuit going from I to R or in the other
direction will reuse the connection I just build, so we can watch all the 
traffic flowing between them (which is encrypted, but we can see volumes
and timing).

An additional possibility of this attack is to determine whether a given
OR is connected to another OR by asking it to connected to that OR and
telling that OR is on A's ip+port, if A does not receive a connection 
request we know the 2 OR's already had a connection with each other.

Preventing this attack is rather easy, check if the ip+port of the
OR we should be connecting to is listed as an ip+port for this OR.

Hopefully this quick write down is enough information, in case additional
or clearer information is needed or you have a comment about the above
information, please don't hesitate to contact me.

gtx,
        dvorak AT xs4all DOT nl