01/27/2012 04:39 PM, Maxim Kammerer:
> 2. Isn't it best to use fresh-until instead of valid-until for vend as
> well (and adjust vendchk accordingly)? I.e., if user's time is 1.5
> hours off forward, you still want to put their time before
> fresh-until, in case htpdate fails later (do hidden services want time
> in valid-after..fresh-until range?)
Those values are only used for sanity checking, so I don't see this as
something essential.
> 3. If >50% of directory authorities die (as happened couple of weeks
> ago), does it complicate the situation? I don't see how — remaining
> authorities still have the old consensus, but thought to point out
> this possibility anyway.
In this situation I'd guess that the authorities can't even generate new
consensuses because they can't get enough votes, but I'm not sure.
01/27/2012 05:03 PM, Maxim Kammerer:
> On Fri, Jan 27, 2012 at 17:39, Maxim Kammerer wrote:
>> When writing and testing that script, I noticed that the incoming
>> valid-after is never more than an hour earlier from the current
>> (correct) time, but at that point it was all kind of black magic, and
>> I didn't know that (as you say) the reason is that the directory
>> authorities agree on a new consensus each hour.
>
> I think I now recalled the actual reason that stopped me from doing
> more research on whether it is possible to rely on hourly new
> consensus: fringe conditions. Say at 13:59 (correct time), Tor gets a
> 13:00-14:00-16:00 (valid-after, fresh-until, valid-until) consensus,
> the computer's time is off, and tordate sets the time to 13:30. But
> shortly after (maybe even before Tor has established a circuit — not
> sure whether that matters), the directory authorities agree on a new
> 14:00-15:00-17:00 consensus, and 13:30 is now out of that window, so
> Tor won't work (will it? The consensus is not yet valid — i.e.,
> unverified), and htpdate will fail. With 14:30 estimate that problem
> wouldn't have happened.
This isn't an issue as far as I can tell. What happens is: we set the
time to 13:30 and restart Tor (since it can't handle clock jumps well).
When Tor shuts down it writes the consensus to the data dir even if it
is unverified. When Tor starts it will load the saved consensus, and now
it will find that it's valid, and hence *NOT* download a new consensus.
All should be well from here on.
Cheers!
signature.asc
Description: OpenPGP digital signature
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
