Clients with clocks skewed far enough in the future to never get a live consensus, but still have a reasonably live one, end up downloading descriptors and then getting stuck on guard selection. This is a rather bad user experience because bootstrap progress appears to get stuck at 80% or 85% even though something rather fundamental (time of day) is wrong.
It's not clear that a reasonably live consensus is dangerous to use for guard selection, so always accept a reasonably live consensus instead of a live one for guard selection.
Ticket #2878 (moved) covers the case of deferring descriptor downloads if the consensus isn't live, which would also improve the UX but might not be necessary if we implement the solution in this ticket.
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Child items
...
Show closed items
Linked items
0
Link issues together to show that they're related.
Learn more.
I think that it is fine to make this change. It's normal for clients to use guards that are chosen based on past consensuses.
It might be good to make sure that we have at least tried to fetch a live consensus before we do this, though. Maybe we should have the test be have_reasonably_live_consensus() || have_received_a_consensus_in_the_last_N_hours()?
There also seem to be other parts of tor's codebase that require a recent consensus:
Nov 05 15:29:04.000 [notice] Bootstrapped 25%: Loading networkstatus consensusNov 05 15:29:51.000 [notice] I learned some more directory information, but not enough to build a circuit: We have no usable consensus.Nov 05 15:29:52.000 [notice] Bootstrapped 40%: Loading authority key certsNov 05 15:29:55.000 [warn] Our clock is 30 minutes, 6 seconds behind the time published in the consensus network status document (2018-11-05 06:00:00 UTC). Tor needs an accurate clock to work correctly. Please check your time and date settings!Nov 05 15:29:55.000 [warn] Received microdesc flavor consensus with skewed time (CONSENSUS): It seems that our clock is behind by 30 minutes, 6 seconds, or that theirs is ahead. Tor requires an accurate clock to work: please check your time, timezone, and date settings.Nov 05 15:29:55.000 [warn] Problem bootstrapping. Stuck at 40%: Loading authority key certs. (Clock skew -1806 in microdesc flavor consensus from CONSENSUS; CLOCK_SKEW; count 1; recommendation warn; host ? at ?)Nov 05 15:29:55.000 [notice] I learned some more directory information, but not enough to build a circuit: We have no recent usable consensus.Nov 05 15:29:55.000 [notice] I learned some more directory information, but not enough to build a circuit: We have no recent usable consensus.Nov 05 17:27:43.000 [notice] Your system clock just jumped 7056 seconds forward; assuming established circuits no longer work.
Trac: Owner: catalyst to teor Milestone: Tor: unspecified to Tor: 0.3.6.x-final Version: N/Ato Tor: 0.3.0.1-alpha
The test_outdated_dirserver_exclusion unit tests fail, and I can't work out why.
make test-network-all passes, but I still need to test with clock skew.
When I set my clock 12 hours behind, I see this error with maint-0.3.5 and my branch:
$ src/app/tor Nov 23 05:07:03.296 [notice] Tor 0.3.5.5-alpha-dev (git-a9820f072bf1bd79) running on Darwin with Libevent 2.1.8-stable, OpenSSL 1.0.2p, Zlib 1.2.11, Liblzma 5.2.4, and Libzstd 1.3.7....Nov 23 05:07:03.000 [notice] Bootstrapped 0%: StartingNov 23 05:07:03.000 [notice] Starting with guard context "default"Nov 23 05:07:04.000 [notice] Bootstrapped 5%: Connecting to directory serverNov 23 05:07:05.000 [notice] Bootstrapped 10%: Finishing handshake with directory serverNov 23 05:07:06.000 [notice] Bootstrapped 15%: Establishing an encrypted directory connectionNov 23 05:07:06.000 [notice] Bootstrapped 20%: Asking for networkstatus consensusNov 23 05:07:06.000 [notice] Bootstrapped 25%: Loading networkstatus consensusNov 23 05:07:10.000 [notice] I learned some more directory information, but not enough to build a circuit: We have no usable consensus.Nov 23 05:07:10.000 [notice] Bootstrapped 40%: Loading authority key certsNov 23 05:07:12.000 [warn] Our clock is 10 hours, 52 minutes behind the time published in the consensus network status document (2018-11-23 06:00:00 UTC). Tor needs an accurate clock to work correctly. Please check your time and date settings!Nov 23 05:07:12.000 [warn] Received microdesc flavor consensus with skewed time (CONSENSUS): It seems that our clock is behind by 10 hours, 52 minutes, or that theirs is ahead. Tor requires an accurate clock to work: please check your time, timezone, and date settings.Nov 23 05:07:12.000 [warn] Problem bootstrapping. Stuck at 40%: Loading authority key certs. (Clock skew -39169 in microdesc flavor consensus from CONSENSUS; CLOCK_SKEW; count 1; recommendation warn; host ? at ?)
When I set my clock 12 hours ahead, on maint-0.3.5 I see:
$ src/app/tor Nov 24 05:09:33.482 [notice] Tor 0.3.5.5-alpha-dev (git-a9820f072bf1bd79) running on Darwin with Libevent 2.1.8-stable, OpenSSL 1.0.2p, Zlib 1.2.11, Liblzma 5.2.4, and Libzstd 1.3.7....Nov 24 05:09:33.000 [notice] Bootstrapped 0%: StartingNov 24 05:09:33.000 [notice] Starting with guard context "default"Nov 24 05:09:34.000 [notice] Bootstrapped 5%: Connecting to directory serverNov 24 05:09:35.000 [notice] Bootstrapped 10%: Finishing handshake with directory serverNov 24 05:09:36.000 [notice] Bootstrapped 15%: Establishing an encrypted directory connectionNov 24 05:09:36.000 [notice] Bootstrapped 20%: Asking for networkstatus consensusNov 24 05:09:37.000 [notice] Bootstrapped 25%: Loading networkstatus consensusNov 24 05:09:41.000 [notice] I learned some more directory information, but not enough to build a circuit: We have no usable consensus.Nov 24 05:09:42.000 [notice] Bootstrapped 40%: Loading authority key certsNov 24 05:09:44.000 [notice] The current consensus has no exit nodes. Tor can only build internal paths, such as paths to onion services.Nov 24 05:09:44.000 [notice] Bootstrapped 45%: Asking for relay descriptors for internal pathsNov 24 05:09:44.000 [notice] I learned some more directory information, but not enough to build a circuit: We need more microdescriptors: we have 0/6279, and can only build 0% of likely paths. (We have 0% of guards bw, 0% of midpoint bw, and 0% of end bw (no exits in consensus, using mid) = 0% of path bw.)...Nov 24 05:09:49.000 [notice] Bootstrapped 50%: Loading relay descriptors for internal pathsNov 24 05:09:51.000 [notice] The current consensus contains exit nodes. Tor can build exit and internal paths.Nov 24 05:09:53.000 [notice] Bootstrapped 57%: Loading relay descriptorsNov 24 05:09:57.000 [notice] Bootstrapped 65%: Loading relay descriptorsNov 24 05:10:36.000 [notice] Bootstrapped 73%: Loading relay descriptorsNov 24 05:11:08.000 [notice] Bootstrapped 78%: Loading relay descriptorsNov 24 05:11:08.000 [notice] Bootstrapped 80%: Connecting to the Tor networkNov 24 05:11:09.000 [warn] Failed to find node for hop #1 of our path. Discarding this circuit.Nov 24 05:11:09.000 [notice] Our circuit 0 (id: 34) died due to an invalid selected path, purpose General-purpose client. This may be a torrc configuration issue, or a bug....Nov 24 05:11:15.000 [notice] Bootstrapped 85%: Finishing handshake with first hopNov 24 05:11:15.000 [warn] Failed to find node for hop #1 of our path. Discarding this circuit....
And on this branch I see:
$ src/app/torNov 24 05:13:01.656 [notice] Tor 0.3.5.5-alpha-dev (git-805f75182a87286a) running on Darwin with Libevent 2.1.8-stable, OpenSSL 1.0.2p, Zlib 1.2.11, Liblzma 5.2.4, and Libzstd 1.3.7....Nov 24 05:13:02.000 [notice] Bootstrapped 0%: StartingNov 24 05:13:02.000 [notice] Starting with guard context "default"Nov 24 05:13:03.000 [notice] Bootstrapped 5%: Connecting to directory serverNov 24 05:13:03.000 [notice] Bootstrapped 10%: Finishing handshake with directory serverNov 24 05:13:04.000 [notice] Bootstrapped 15%: Establishing an encrypted directory connectionNov 24 05:13:05.000 [notice] Bootstrapped 20%: Asking for networkstatus consensusNov 24 05:13:05.000 [notice] Bootstrapped 25%: Loading networkstatus consensusNov 24 05:13:09.000 [notice] I learned some more directory information, but not enough to build a circuit: We have no usable consensus.Nov 24 05:13:09.000 [notice] Bootstrapped 40%: Loading authority key certsNov 24 05:13:11.000 [notice] The current consensus has no exit nodes. Tor can only build internal paths, such as paths to onion services.Nov 24 05:13:11.000 [notice] Bootstrapped 45%: Asking for relay descriptors for internal pathsNov 24 05:13:11.000 [notice] I learned some more directory information, but not enough to build a circuit: We need more microdescriptors: we have 0/6251, and can only build 0% of likely paths. (We have 0% of guards bw, 0% of midpoint bw, and 0% of end bw (no exits in consensus, using mid) = 0% of path bw.)Nov 24 05:13:13.000 [notice] Bootstrapped 50%: Loading relay descriptors for internal pathsNov 24 05:13:15.000 [notice] The current consensus contains exit nodes. Tor can build exit and internal paths.Nov 24 05:13:19.000 [notice] Bootstrapped 57%: Loading relay descriptorsNov 24 05:13:19.000 [notice] Bootstrapped 63%: Loading relay descriptorsNov 24 05:13:19.000 [notice] Bootstrapped 68%: Loading relay descriptorsNov 24 05:13:19.000 [notice] Bootstrapped 75%: Loading relay descriptorsNov 24 05:13:19.000 [notice] Bootstrapped 80%: Connecting to the Tor networkNov 24 05:13:19.000 [notice] Bootstrapped 90%: Establishing a Tor circuitNov 24 05:13:21.000 [notice] Bootstrapped 100%: Done
So this particular bug appears to be fixed.
I opened #28591 (moved) for the "future consensus" case.