Tails

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.