Opened 7 years ago

Closed 3 years ago

#8766 closed defect (fixed)

Tor never recovers when started with skewed clock

Reported by: proper Owned by:
Priority: Very Low Milestone: Tor: unspecified
Component: Core Tor/Tor Version: Tor: 0.2.7
Severity: Normal Keywords: tor-client
Cc: ioerror, proper Actual Points:
Parent ID: Points: small
Reviewer: Sponsor:

Description

How to reproduce...

Start Tor with a skewed clock. For example, +/- one week.

Tor will detect, that the clock is skewed.

Received directory with skewed time (server '...'):
It seems that our clock is ahead by 6 days, 23 hours,
59 minutes, or that theirs is behind. Tor requires an
accurate clock to work: please check your time,
timezone, and date settings.

I learned some more directory information, but not
enough to build a circuit: We have no recent usable
consensus.

Then reset clock back to correct time. Tor will also detect that.

Your system clock just jumped 604800 seconds backward;
assuming established circuits no longer work.

Result:

Tor still won't work (no connections possible).

Expected result:

Tor recovers and can now connect.

Version:

getinfo version: 250-version=0.2.3.25 (git-3fed5eb096d2d187)
(On Debian Wheezy.)

Child Tickets

Change History (20)

comment:1 Changed 7 years ago by nickm

Keywords: tor-client added
Priority: majornormal

I'm downgrading the priority to "normal" since the workaround (restart Tor) is pretty easy.

comment:2 Changed 6 years ago by nickm

Milestone: Tor: 0.2.5.x-finalTor: 0.2.???

comment:3 Changed 5 years ago by mikeperry

Parent ID: #3059

comment:4 Changed 5 years ago by arma

This is related to the comment in main.c, around the clock jump message:

    /* XXX if the time jumps *back* many months, do our events in
     * run_scheduled_events() recover? I don't think they do. -RD */

And even if we fix those static time_t's, we have other places in the code where e.g. time_to_download_next_consensus[] is full of times from the distant future.

This is going to be rough to fix. But it sure would be nice to fix.

comment:5 Changed 5 years ago by arma

(What would happen if we just zeroed all the time_to_foo's on clock jump?)

comment:6 in reply to:  5 Changed 5 years ago by arma

Milestone: Tor: 0.2.???Tor: 0.2.7.x-final
Status: newneeds_review

Replying to arma:

(What would happen if we just zeroed all the time_to_foo's on clock jump?)

My ticket8766 branch does this, and it works -- you can start your Tor a week in the future, then fix the clock, and it will pretty speedily catch up and finish bootstrapping.

There are still plenty of components of Tor that haven't been fixed here though -- the addressmaps come to mind, some of the cell timer statistics, maybe the circuit and channel lifetime checks, maybe the relay bandwidth and geoip histories, the time_to_download_next_consensus[] as mentioned above, a hidden service's next_upload_time, are probably all worth exploring too. And god only knows what happens to libevent event timers when the clock goes back a week.

But all of this said, for the "Tails or Whonix first start" use case, maybe few of those matter in practice. I think this patch as-is helps in some cases and doesn't hurt in any.

comment:7 Changed 5 years ago by nickm

Keywords: 027-triaged-1-in added

Marking some tickets as triaged-in for 0.2.7 based on early triage

comment:8 Changed 5 years ago by nickm

Merged, plus some tweaking.

comment:9 Changed 5 years ago by nickm

Resolution: implemented
Status: needs_reviewclosed

comment:10 Changed 5 years ago by nickm

Resolution: implemented
Status: closedreopened

comment:11 Changed 5 years ago by nickm

Milestone: Tor: 0.2.7.x-finalTor: 0.2.8.x-final

I've merged roger's "good-enough-for-now" fix here, but I suspect that there are more timers that need to be cleared in this case.

git grep 'static time'

is a good place to start looking for some of them.

comment:12 Changed 5 years ago by isabela

Points: small
Priority: normaltrivial
Version: Tor: 0.2.7

comment:13 Changed 4 years ago by nickm

Milestone: Tor: 0.2.8.x-finalTor: 0.2.???

It is impossible that we will fix all 277 currently open 028 tickets before 028 releases. Time to move some out. This is my first pass through the "new" and "reopened" tickets, looking for things to move to ???.

comment:14 Changed 3 years ago by teor

Milestone: Tor: 0.2.???Tor: 0.3.???

Milestone renamed

comment:15 Changed 3 years ago by nickm

Keywords: tor-03-unspecified-201612 added
Milestone: Tor: 0.3.???Tor: unspecified

Finally admitting that 0.3.??? was a euphemism for Tor: unspecified all along.

comment:16 Changed 3 years ago by nickm

Keywords: tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:17 Changed 3 years ago by nickm

Keywords: 027-triaged-in added

comment:18 Changed 3 years ago by nickm

Keywords: 027-triaged-in removed

comment:19 Changed 3 years ago by nickm

Keywords: 027-triaged-1-in removed

comment:20 Changed 3 years ago by nickm

Resolution: fixed
Severity: Normal
Status: reopenedclosed

Calling the actual reported bug fixed here in 0.2.7. We should still fix other time issues as we encounter them, but this ticket isn't really about that.

Note: See TracTickets for help on using tickets.