15/10/12 18:23, anonym wrote:
>
> But running that test without Host-to-Guest time syncing will fail since
> Tor won't write an unverified-microdesc-consensus like it used to write
> a unverified-consensus prior to Tor 0.2.3.x. wait_on_tor_consensus()
> will hence never succeed. The use of microdescriptors isn't the issue as
> Tor now fails earlier, right after "Bootstrapped 10%: Finished handshake
> with directory server" instead of (as earlier) "Bootstrapped 20%: Asking
> for network consensus". It gives this warning:
[...]
> I tried a small patch (see below) which, in essence, moves
> wait_on_tor_consensus() until after the "is_clock_way_off" check + fix
> (which actually makes sense in general). It worked, because the Tails
> release date (today) was close enough (but still outside, I believe) to
> the certificate's issue date. I faked the release date to that of
> 0.14~rc1 (almost a week ago) and that also worked, which is weird given
> that the certificate definitely wasn't valid then. Finally I tried
> setting the release date to something like a month back, and that made
> it fail like before.
I got the explanation while having a look in the Tor sources. These
commits are introduced in the 0.2.3.x series:
This one adds check_certs_lifetime_internal() which is used for checking
the cert's lifetime validity on TLS connections:
commit f4c1fa2a04c310c4e0274129bb2fff2aacb59248
Author: Nick Mathewson <nickm@???>
Date: Wed Sep 14 13:04:48 2011 -0400
More functions to manipulate certs received in cells
And this one should be self-explanatory in this context:
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.
This introduces the following issues with our tordate:
* When is_clock_way_off() is true, we set the time to the release date.
Hence a Tails release will only work for really inaccurate clocks for
up to a month after it was built.
* is_clock_way_off() is true iff `now < release_date` or `now >
release_date + 6 months`, where `now` is Tails' potentially incorrect
time. But it should ideally be true iff `now < real_now - 30 days` or
`now > real_now + 2 days`. It should be quite clear that
`release_date` cannot be used for approximations of `real_now` in
general, so there's a lot of room for errors here.
To fix this I propose we change our current approach in tordate. We
replace the "if is_clock_way_off ..." section of tordate with something
like this:
1. We connect to the Tor controller and use "GETINFO status/bootstrap-
phase" to know how Tor is doing (or we grep it in the log, but this
seems cleaner). If Tor reaches "Bootstrapped 20%" we should be good,
so tordate can continue as it normally does.
2. If Tor gets stuck on "Bootstrapped 10%", we grep the Tor log for a
certificate lifetime warning and extract the valid-after date T.
3. We set the time to T and let tordate continue as normal (i.e.
setting the time from the consensus, which Tor now has been able to
download).
I know it's a quite hideous beast, but that's the only way I can think
of that makes tordate behave as it does now. Also, the current state of
tordate (extracting the time from the consensus) is pretty hideous as it
is, so more hideousness maybe won't hurt :). 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.
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.
What do you think?
Cheers!
