Feature #8977

Get rid of tordate

Added by anonym 2015-02-27 17:13:33 . Updated 2015-05-17 13:31:02 .

Time synchronization
Target version:
Start date:
Due date:
% Done:


Feature Branch:
Type of work:

Affected tool:
Deliverable for:


With tordate I’m referring to the unholy mess found in config/chroot_local-includes/etc/NetworkManager/dispatcher.d/20-time.sh, whose design can be read in wiki/src/contribute/design/Time_syncing.mdwn (overview, steps 1-3, more or less).

tordate is a fragile pile of hacks, and it effectively makes it possible for attackers to replay any old Tor network consensus to Tails users. Also, in at least our current understanding of things, it prevents us from making /var/lib/tor persistent, so Tails users has no long-term Tor Entry Guards. I’m not sure more reasons need to be stated why we must get rid of it.

The problem

When Tails boots on a system where the clock is incorrect, Tor will not be able to bootstrap. With “incorrect” we specifically mean when the time is outside the current Tor network consensus’ (/var/lib/tor/cached-microdesc-consensus) validity lifetime (e.g. the valid-after and valid-until fields). When Tor fails to bootstrap, Tails is effectively useless for networking (at least for what we intend with it).

It should be noted that the clock just have to be off by a few hours for Tor to become completely unable to bootstrap, and that’s not very uncommon. Certain OSes set’s the BIOS clock to the local time, and since Tails uses UTC (and assumes the BIOS clock is UTC), this becomes a problem for everyone but people living in the GMT+0/UTC timezone. Hence this is a very serious problem.

What we want

We want a mechanism to avoid the above problem that doesn’t have a network fingerprint unique to Tails. Some people may think NTP, which is widely used, but NTP is unauthenticated, so a MitM attack would let an attacker set the system time, which later may be used to fingerprint the Tails user for applications/protocols that leak the system time. And while authenticated NTP exists, it’s barely in use, so it’d become a great way to identify Tails users.

In fact, we’d prefer if the sought after “mechanism” is part of Tor’s normal bootstrap process, with no extra packets sent, so the network fingerprint becomes indistinguishable from a “normal” Tor bootstrap. That would be a very handy fact when reasoning about how Tails users can be fingerprinted.

Some other random requirements about this mechanism:

  • it has to work with pluggable transports
  • it has to work when not doing a full bootstrap, e.g. when /var/lib/tor is persistent
  • Tor is a bit fragile when it comes to time jumps when it’s at the early bootstrap stages. For instance, in tordate have to restart Tor after setting the time according to the fetched consensus, otherwise it just idles, at least sometimes. This will have to be solved too.


Related issues

Is duplicate of Tails - Feature #5774: Robust time syncing In Progress 2015-05-17


#1 Updated by anonym 2015-02-27 17:32:00

  • Description updated

#2 Updated by intrigeri 2015-02-27 18:38:25

  • Assignee set to anonym

anonym, thanks for this awesome writing! We already had Feature #5774, that has some additional resources, so this new ticket kinda feels like a duplicate. May you please merged them somehow? If you’d rather not to, just reassign to me and I’ll do it one of these months on my copious free time.

#3 Updated by intrigeri 2015-02-27 18:38:40

#4 Updated by intrigeri 2015-05-02 05:12:48

I’ve added more info to Feature #5774, and still feel these two tickets should be merged somehow.

#5 Updated by intrigeri 2015-05-17 13:30:05

#6 Updated by intrigeri 2015-05-17 13:30:16

#7 Updated by intrigeri 2015-05-17 13:30:30

  • Status changed from Confirmed to Duplicate
  • Assignee deleted (anonym)
  • Target version deleted (Hardening_M1)

#8 Updated by intrigeri 2015-05-17 13:31:02

Moved this ticket’s description to Feature #5774’s blueprint.