21/10/12 10:06, intrigeri wrote:
> Hi,
>
> anonym wrote (16 Oct 2012 13:17:06 GMT) :
>
>> commit 87622e4c7e1a3b5c80e67141de7947d0304b6f31
>> Author: Nick Mathewson <nickm@???>
>> Date: Mon Nov 14 22:21:45 2011 -0500
>
>> Allow up to a 30 days future skew, 48 hours past skew in certs.
>
>> In other words, Tor will now back off on the TLS level when
>> contacting the dir servers, so if the clock is more than 30 days in
>> the past or 2 days in the future, Tor won't download any consensus.
>
> Just curious: this commit makes Tor tolerate servers with *more* clock
> skew than previously, so I'm wondering -- did a previous commit, in
> the 0.2.3 cycle, introduce this class of checks entirely?
> In other words, does Tor 0.2.2 ignore TLS certificates' valid-until?
If you look at my email again and read what I wrote about commit f4c1fa2
you'll see that: No, Tor didn't care a bout TLS certificate lifetime
prior to 0.2.3.x.
>> It's quite clear that we need to find a real long-term solution,
>> perhaps an option
>> SetSystemTimeToMedianOfAllDirectoryAuthoritiesOnBootstrap in
>> upstream Tor. But that's a concern we'll have to tackle later.
>
> Yeah. TODO++?
todo/robust_time_syncing
>> The only other quick fix I can come up with is using Jacob's tlsdate
>> in the clear to set the time (which effectively broadcasts to the
>> world "Hey! I'm using Tails!" :/). Well, I suppose the last
>> alternative is to not care and ship Tails
>> 0.14 with a broken tordate.
>
> Worst case is: not supporting clocks that are more than 30 days in the
> past of 2 days in the future, and documenting it in Known Issues.
>
> That would not be very nice, but still, it seems much better to me
> than introducing a new piece of software in a hurry: we might want to
> use tlsdate at some point, within a rethought time sync' system, but
> I'd want to see it live in experimental for a while before we ship it
> in a stable Tails release. BTW, I'm happy I've seen a lot of work
> being done on tlsdate recently, which probably means a least a few
> users / testers, and possibly new features that might be useful in the
> context of Tails :)
>
> IMHO: either we manage to implement the proposed ugly hack in a sane
> way, or we walk the "Known Issues" way.
Agreed.
Cheers!