Re: The "de-Tor-iorate Anonymity" talk by Nathan Evans at DEFCON 16

[Roger Dingledine <arma@xxxxxxx>]

On Fri, Aug 15, 2008 at 02:58:51PM -0400, Rochester TOR Admin wrote:
> I'll comment on that but I know Roger and others were there that might be
> able to explain it better.

Yep. I talked to Nate about it earlier that day, and also talked to
Christian (his advisor) beforehand.

> The idea is that Tor _used to_ allow a user to define an infinite path when
> creating circuits so an attacker could generate circular circuits causing
> the queue on those circuits to go up, using up processing power, causing
> latency etc.

Actually, Tor still allows this attack. In 0.2.1.3-alpha, we fixed most
of the problem:
    - Implement most of proposal 110: The first K cells to be sent
      along a circuit are marked as special "early" cells; only K "early"
      cells will be allowed. Once this code is universal, we can block
      certain kinds of DOS attack by requiring that EXTEND commands must
      be sent using an "early" cell.
but the current plan is to wait until 0.1.2.x and 0.2.0.x are obsolete
before doing the last step. That means the attack will still work for
the next 6-9 months.

The reasoning for why this delay is acceptable is that there are (alas)
plenty of other attacks we're still working on that might be just as
effective as this one.

>  This was done using a what he define as "DoS Client" and "DoS
> Server".  So he would attempt to DoS partitions of the Tor network causing
> slow downs for all Tor servers involved.
> 
> At the same time an attacker would run a malicious Tor exit node that would
> inject a <javascript ping> into the traffic which would connect back to a
> server which then records how often that ping is received which effectively
> measured the latency on that circuit.  So if a client was not using one of
> the relays that was affected by the circular circuit, the latency would be
> normal.  If the client _did_ use one of the nodes that were being DoS'd, the
> latency would suddenly spike thus proving that the entry node was a member
> of the DoS'd circuit.
> 
> The DoS attack would be done on different circuits until they finally found
> one that would slow down the latency of the attacked client which would show
> 1) the exit node (since it was owned by the attacker), 2) the relay node
> that was used,(again because the attacker owned the exit), and 3) the entry
> node (because it was affected by the DoS) turning Tor into the single proxy
> as it proposed to do.

Right. Note that in this particular version of the attack, they assumed
that the attacker runs the website and the exit relay, so they learn
the middle relay for free, and they're only aiming to uncover the entry
relay. The original attack (from 2005) just assumed that the attacker
runs the website. I bet this version could be adapted to find multiple
relays, but this particular paper didn't do that.

Also note that the attack turns Tor into a *network* of single-hop
proxies. If there's only one single-hop proxy, then it can be more readily
attacked than if there are 500 single-hop proxies and you don't know
which one your target will pick. It's a subtle distinction but still
one worth clarifying.

> Nathan Evans recommended not using fixed path lengths (>3 nodes in a
> circuit),

I think using 4 nodes in a circuit would foil this particular variation
of the attack, but adapting the attack to handle it wouldn't be so
hard. Using a variable number of nodes in the circuit could help though,
because the attacker wouldn't know how many matches they're hunting for.

As far as I know, the only analysis that has happened for this class of
attacks is building your own circuit (so you already know which relay is
the one you're supposed to find), then measuring the relays and showing
that the relay you were looking at scores high in terms of a match.

Nobody to my knowledge has done the analysis to measure them all and
look at false positives, false negatives, etc. That would be good to do.

> don't allow infinite path lengths which is fixed in the newest
> version of Tor

(Actually, not til 0.2.1.x or 0.2.2.x probably)

>, induce delays which is not going to happen, and then the
> rest we know - disable javascript,

Disabling javascript wouldn't do it, since the "generate a recognizable
signal" step could be done using refreshes, just a single large file
sent in a certain traffic pattern, or probably other ways.

> use SSL, and monitor exit nodes (see
> TorFlow).

Similarly, I don't think these would do it.

> The presentation was kind of crappy and it's a complicated attack so correct
> any of this if I"m wrong.

Good summary.

Thanks!
--Roger