sdwdate Tor Consensus Time Sanity Check

phabricator-migrator · February 19, 2024, 5:52pm

Information

ID: 151
PHID: PHID-TASK-n2ig3pwvolnn67iytzlw
Author: Patrick
Status at Migration Time: resolved
Priority at Migration Time: Normal

Description

problem description:

When the host’s system clock is too much off, Tor won’t be able to connect and since sdwdate runs through Tor, it won’t be able to fix the clock. At the moment in such situations there is no good feedback to the user.

proposal

A sdwdate sanity test could be created.
Before attempting to fetch the time from Tor hidden services, it could check what Tor is telling us about the clock.
Check if times from remote servers match Tor are within consensus/valid-after and consensus/valid-until, otherwise reject those.

caution

As per chat log with Roger directory authorities can lie about time - so we need to use this with care.
Tor consensus isn’t always downloaded from directly from directory authorities, sometimes Tor downloads the Tor consensus from directory mirrors. And the latter aren’t trusted as much as directory authorities. Those are just like normal relays.
We should have the courtesy to not explicitly download from directory authorities, because… armadev: oh. i think that would be horrible. hundreds of thousands of users doing that could overwhelm the directory authorities.

misc:

anondate
TimeSync: Whonix Time Synchronization Mechanism
anondate is a fork of tordate and already parses Tor consensus file. It’s already part of anon-shared-helper-scripts (https://github.com/Whonix/anon-shared-helper-scripts/blob/master/usr/lib/anon-shared-helper-scripts/anondate).
Why not use tordate by Tails instead of reinventing the wheel with anondate?
Another option, from control-spec.txt:

     "consensus/valid-after"
     "consensus/fresh-until"
     "consensus/valid-until"
      Each of these produces an ISOTime describing part of the lifetime of
      the current (valid, accepted) consensus that Tor has.
      [New in Tor 0.2.6.3-alpha]

Related: TimeSync: Whonix Time Synchronization Mechanism
Related: T56

Deprecated:

~~We could then inform the user and/or - if it is safe - even roughly fix the clock for the user so sdwdate can fix it. (From verified Tor consensus (vs unverified Tor consensus). Needs research.)~~
~~plugin sdwdate-plugin-anondate~~ (Not required as a plugin, because sdwdate now depends on Tor anyhow.)
~~Migrated from: https://github.com/Whonix/Whonix/issues/244 (contains extensive discussion)~~ (outdated)
~~Tails-dev - tordate: why is it safe to set time from unverified-consensus?~~ (threat model does not include fingerprinting)

credits:

Extensive research and guess work done by @HulaHoop and @Patrick.

scope:

The scope of this ticket is to create a sdwdate sanity test. It would be a user of anondate.

Comments

Patrick

2017-02-24 22:56:44 UTC

WIP WIP sdwdate Tor Consensus Time Sanity Check · Kicksecure/sdwdate@c626798 · GitHub

Done:

Checks if system clock is between consensus/valid-after and consensus/valid-until. Otherwise a warning is logged.

Disregards any remote times not between consensus/valid-after and consensus/valid-until.

Questions:

Do you think the following information from the Tor control connection is safe to have for Whonix-Workstation?
./tor_consensus_valid-after.py 
2017-02-24 22:00:00

./tor_consensus_valid-until.py 
2017-02-25 01:00:00

Patrick

2017-02-25 04:26:23 UTC

Patrick

2017-05-16 14:04:53 UTC

Patrick

2017-12-02 21:20:44 UTC