[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: Uptime Sanity Checking



On Thu, Mar 08, 2007 at 11:50:44PM +0100, Peter Palfrader wrote:
> >    We propose that uptime be capped at two months.
> >    Currently there are approximetly 50 nodes with this
> >    amount of uptime, and the average uptime is around 9
> >    days. This cap would prevent these 50 nodes from
> >    being displaced by an attacker.
> 
> Could you please explain to me what the point of this change is?
> Especially in the light that - to my understanding - Tor only ever uses
> the median of the uptime values, never the average.  Assuming my
> understanding is correct this would effectively be a non-op, isn't that
> so?

It wouldn't be a noop. Right now we're vulnerable to the situation where
an attacker signs up 1000 servers with uptimes of 2 years, and suddenly
his nodes are the only ones who are allowed to be called Stable, and
therefore the only ones who are allowed to be called Guard.

With this proposed change, there would be 1050 servers called Stable
and potentially called Guard.

This is more important than it seems, due to a "bugfix" introduced in
0.1.2.2-alpha:

    - If one of our entry guards is on the ExcludeNodes list, or the
      directory authorities don't think it's a good guard, treat it as
      if it were unlisted: stop using it as a guard, and throw it off
      the guards list if it stays that way for a long time.

That is, if Alice has chosen a set of three entry guards, but somebody
causes them to no longer have the Guard flag, then she'll abandon them
while they are missing the Guard flag -- and pick new ones in the
meantime. (We introduced the bugfix for the case where a previously
fine guard decides to add "BandwidthRate 5KB" to his torrc tomorrow.
We should stop thinking it's a fine guard.)

Of course, there are 250 guards in the network right now, and if only
50 of them have been up for 2 months, the attacker can still do this
attack against the other 80% of the guards. So how much is this proposal
actually saving us?

More generally, is it possible to come up with a dynamic value of "2
months" that is a function of the current network, so we will also see
some protection when there are no nodes that have been up for that long,
or when nearly all the nodes have been up for that long? Or is the whole
point that we're vulnerable to attack if we don't use a fixed cap?

Thanks!
--Roger