This is about tails#5774.
- Possible solutions
- Misc. resources
With tordate we're referring to the unholy mess found in config/chroot local-includes/etc/NetworkManager/dispatcher.d/20-time.sh, whose design can be read in Time syncing (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 have no
long-term Tor Entry Guards. I'm not sure more reasons need to be
stated why we must get rid of it.
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.
valid-until fields). When Tor fails to
bootstrap, Tails is effectively useless for networking.
It should be noted that the clock just has to be off by a few hours for Tor to become completely unable to bootstrap, and that's not very uncommon. Certain OSes (including Windows up to Windows 8 at least) set the BIOS clock to the local time, and since Tails uses UTC (and assumes the BIOS clock is UTC), this becomes a problem for every user but those 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. This mechanism must not 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. Authenticated NTP (tails#6113 (closed)) is not broadly uses, so it'd become a great way to identify Tails users. There are possible mitigation measures to allow ourselves to use NTP anyway, which at least one of proposed plans uses.
Ideally, 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 requirements about this mechanism:
- A: it has to avoid the security issues that current tordate has wrt. replayed Tor consensus;
- B: it has to be more robust that the current tordate;
C: it has to be as safe as the current tordate + htpdate combination,
e.g. wrt. failing closed when facing a replayed consensus and the
time set by htpdate is out of the
valid-untilinterval (admitedly, the corresponding UX is totally miserable as of Tails 1.4, but at least we're failing closed);
- D: it has to work with pluggable transports;
E: it has to work when not doing a full bootstrap, e.g.
F: Tor is a bit fragile when it comes to time jumps during
early bootstrap stages. For instance, in
tordatewe 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;
- G: it should help improve the UX we provide while Tor is boostrapping and the time is being sync'ed, both on success and on various kinds of failures.
Some aspects of this plan are still unclear, so it's difficult to tell how much of the problem described above it will solve.
This plan reuses parts of the "Ask the user what time it is" option that's described below in more details. At this point it's not clear which problems considered in the "Ask the user what time it is" option are also handled here.
If the user chooses autoconfig, then do unsafe NTP so Tor can bootstrap. We'll decide on tails#18230 (closed) if and how we can do that. Then, once Tor has bootstrapped, do a safer time sync.
Else, when the user chooses to hide Tor, ask them fix the time zone and clock manually.
Ask the user what time it is
... when Tor fails to bootstrap for time-related reasons.
That's what ChromeOS does when the time is too wrong:
- Sadly, most of their design docs, UI mockups etc. are apparently not accessible to non-Google employees or something, so it's not easy to understand why they did what. Still, the resulting code is there: https://src.chromium.org/viewvc/chrome?revision=266431&view=revision
When I start Tails And I log into the Tails desktop with the default options And Tor fails to bootstrap for time-related reasons Then I am asked for the correct time And at the same time the corresponding UI lets me choose my preferred timezone And then, Tails Clock displays the current time with the chosen timezone And Tor bootstrap is attempted again
- What's called Tails Clock below is the widget that will display the current time within the GNOME desktop, in whatever timezone the user prefers, which we call the display timezone. The system timezone remains UTC in all cases.
- From current tordate, we keep only the mechanism that detects if Tor
fails to bootstrap due to time-related reasons. Whenever this
happens, we open a GUI that lets the user set the correct time and
choose their preferred timezone, and then we restart Tor.
- GNOME Date and Time interface is good -- according to sajolida "We could maybe reuse most of that UI"; however, it "looks like a geolocation tool" so it "should come with a clear message that this is only to set the 'clock display timezone' and not collected in any way"
- We keep htpdate as-is for now, in order to keep failing closed on replayed Tor consensus.
- We need Tails Clock: otherwise, we would let the user set the correct time in their preferred timezone, but then the feedback we would give them (in the GNOME clock display) would let them think the operation has failed, since it would still display time in UTC. We have to avoid making the UX worse this way, hence the need for Tails Clock. The config source for the timezone used by Tails Clock must be shared with the time input GUI, to provide a consistent UX. The interface used by Tails Clock and by the upcoming time input GUI could perhaps be shared; this raises privilege separation issues that need to be thought through.
- We need a persistence option for the display timezone: otherwise, it will be a pain for Windows users. If the new Greeter is ready in time for this, perfect; otherwise, we'll have to implement it in a different way, e.g. by allowing users to persist their chosen timezone when they set it from Tails Clock or from the aforementioned GUI.
We stop using htpdate to set the system clock, but we keep it around as a way to detect a replayed Tor consensus: if the time delta detected by htpdate is too big:
- we warn the user that something fishy may be going on, and try to make as actionable as realistically possible;
- we stop Tor, in order to keep failing closed in this situation.
And then, perhaps htpdate could be configured to query fewer servers, because we maybe don't need to trust the info we get from htpdate as much once we're there.
Integration with the new Greeter
We need to give the user will have the opportunity to choose their preferred timezone in the Greeter (tails#11645). And then, most likely we'll want to provide them feedback about what Tails thinks the resulting local time is. And in turn, the UI that provides that feedback can as well allow users to set the system time if it's wrong (tails#11641).
The chosen timezone information should be re-used both by Tails Clock and by the time input GUI that lets users correct the system time if Tor has failed to bootstrap for time-related reasons.
When I start Tails And I choose my preferred timezone in the Greeter Then I see the resulting system time in the chosen timezone And I am enabled to correct the system time And then, Tails Clock displays the current time with the chosen timezone And Tor has greater chances to bootstrap successfully on first try
Extend Tor some how
- like Roger suggested
- Export clock skew opinion as getinfo command and its answer network time requests duplicate
- Not maintained nor in Debian anymore.
- Used by ChromeOS on every network up event => no longer easy to fingerprint due to low usage iff we use it exactly in the same way (e.g. ask the very same HTTPS servers) as ChromeOS, and go on doing so forever.