Re: Tor 0.1.0.1-rc is out

[Roger Dingledine <arma@xxxxxxx>]

On Wed, Mar 30, 2005 at 02:32:30AM -0600, Mike Perry wrote:
> Awesome. Hidden services are a *LOT* quicker. At least for web.

Great.

> Though, as an aside, what is the potential weakness for them that was
> mentioned offhand in your latest draft paper? Is this
> exacerbated/lessened/unchanged by the changes?

Well, there are a number of problems. One of the biggest is that if the
adversary owns a few Tor servers, then over time as the hidden service
makes rendezvous circuits, the adversary's server is likely to end up
as the first hop on the path. What makes it especially bad is that the
adversary can *induce* rendezvous circuits by accessing the hidden service
as normal. If the hidden service is not a Tor server, then it's quickly
clear from timing that the guy who just launched the circuit is probably
the operator of the hidden service. And if he is a Tor server, then basic
predecessor attacks (http://freehaven.net/anonbib/author.html#wright02,
http://freehaven.net/anonbib/author.html#wright03) probably work well.

> Also, got a few other random questions:
> 
> >     - Better handling for heterogeneous / unreliable nodes:
> >       - Annotate circuits w/ whether they aim to contain high uptime nodes
> >         and/or high capacity nodes. When building circuits, choose
> >         appropriate nodes.
> 
> Are there any plans to use the ReadHistory/WriteHistory fields in the
> directory servers to also guide circuit creation? Like choosing nodes
> whose bandwidth history is less than their average?

I'm wary of doing this, because I fear oscillation. By the time clients
get ahold of server descriptors, many dozens of minutes have typically
passed. So anything that relies on being quicker than other people about
taking advantage of inefficiencies is not going to work so well.

> Do directory servers otherwise refuse to accept servers that just come
> online and immediately report high uptime? Otherwise there could be a
> possible attack to try to get more people to use a node.

No, we don't try to do any sanity checking yet. The first step is to get
things robust enough in the presence of friendly nodes. Lying nodes is
much harder.

> >     - Make hidden services try to establish a rendezvous for 30 seconds,
> >       rather than for n (where n=3) attempts to build a circuit.
> 
> Is this option tunable? Does it have any effect on hidden service
> security?

It's not tunable. Should it be?

I picked 30 seconds because that's the default timeout for clients. So
trying longer than that probably won't help because the client will have
given up on this particular rendezvous.

The timeout probably does have some effect on security, but probably not
a big one, compared e.g. to the attack I describe above.

--Roger