Re: Tor 0.1.0.1-rc is out

[Mike Perry <mikepery@xxxxxxxxxx>]

Thus spake Roger Dingledine (arma@xxxxxxx):

> This release incorporates automatic reachability testing for servers (the
> first step to getting rid of the 'verified servers' notion), uses pthreads
> if available to reduce server memory footprint, uses libevent so we can
> use better polling interfaces when available, handles slow/busy hidden
> services better, supports https proxies for clients, and fleshes out our
> controller interface. It also fixes a bunch of minor but annoying bugs.

Awesome. Hidden services are a *LOT* quicker. At least for web.

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?

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?

>       - This means that every single node in an intro rend circuit,
>         not just the last one, will have a minimum uptime.
>       - New config option LongLivedPorts to indicate application streams
>         that will want high uptime circuits.
>       - Servers reset uptime when a dir fetch entirely fails. This
>         hopefully reflects stability of the server's network connectivity.
>       - If somebody starts his tor server in Jan 2004 and then fixes his
>         clock, don't make his published uptime be a year.

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.

>     - 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?


-- 
Mike Perry
Mad Computer Scientist
fscked.org evil labs