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

[bev]

I can't unsubscribe from this group - help! 

-----Original Message-----
From: owner-or-talk at freehaven.net [mailto:owner-or-talk at freehaven.net] On
Behalf Of Roger Dingledine
Sent: Sunday, August 17, 2008 2:03 AM
To: or-talk at freehaven.net
Subject: Re: The "de-Tor-iorate Anonymity" talk by Nathan Evans at DEFCON 16

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