Hi!
I am at least hoping to get an answer from sajolida here, but more perspectives are always welcome!
tl;dr: We want to drop our time synchronization hacks, which will introduce UX regressions in some cases. We wonder how we should weigh these UX regressions vs the cost of doc/code solutions so we pick the right solution.
Background and context
======================
The tor client requires a somewhat accurate clock to accept Tor network consensuses and thus be able to bootstrap. Clearly this becomes an issue when Tails users' hardware have incorrect clocks, so Tails has been fixing the clock by just setting it to the time of the Tor network consensus, essentially eliminating this time check. But it is there for a reason: checking the timestamp of consensuses with an accurate clock prevents play-back-attacks of old consensuses (e.g. ones where a large part of the network was compromised by the attacker). We have repeatedly gotten concerned looks from Tor devs when they have learned this, and been told to do something about it. Also, the piece of code that does this in Tails has historically been a huge source of bugs and pain, which in itself is a reason for it to go.
And that is exactly what we want to do: drop these time synchronization hacks. Full ticket:
https://redmine.tails.boum.org/code/issues/16471 (I hope my email is enough so you don't have to read this ticket, but if I fail comment #69 is probably the most interesting for UX people)
One thing that has changed since these hacks were developed is that the tor client is more tolerant to invalid clocks; with current tor a clock with at most ±24h scew is fine, but back in the day 3 hours were enough to prevent boostrapping. This increase in tolerance is actually huge for us: we expect that the largest amount of invalid clocks are within this range, either from drift, or from OS:es that saves their local time to the hardware clock, thus breaking our assumption that it is in UTC. A ±24h tolerance solves these situations since clock drift generally is way less than 24h, and there is no time zone that differs more than 24h from UTC. Yay!
However, there are two situations where the UX regresses and we want your help:
Good clock, replayed consensus
==============================
Assume that we have a good enough clock to bootstrap modern tor (i.e. within ±24h), and that a local attacker replays and old consensus.
For comparison, let's look at the current behavior with the time sync hacks in place: tor would happily connect using the outdated consensus, so the UX is good, but security wise we're potentially in deep shit.
By dropping the time sync hacks we get the behavior the Tor devs intended: when we are served an outdated consensus, tor won't bootstrap. But the UX is arguably bad since tor isn't working.
Clock is > 24h in the future
============================
Assume that our clock is more than 24 hours in the future compared to UTC and we receive the current, legit Tor network consensus.
For comparison, let's look at the current behavior with the time sync hacks in place: Tails would set the clock to whatever the consensus says it is so tor successfully bootstraps.
By dropping the time sync hacks, tor would then refuse this legit consensus.
How to fix the UX in these situations?
======================================
Note that both of these situations are pretty similar: Tor fails to bootstrap, and the user has to be involved to solve the situation some how. However, here "solve" doesn't necessarily mean "get Tor to bootstrap"; in the "replayed consensus" case, the correct solution for the user is to *not* use Tails (or tor in general) on this compromised network.
So we wonder what you all think we should do in this situation. We could for instance notify the user when we fail to bootstrap, suggesting them to restart + set the hardware clock to the correct time either in the BIOS config or in Tails (via the command line), and retry. The notification could contain the consensus timestamps which could help in detecting whether a consensus is replayed. And we should probably also link to some docs about all this.
What do you think? Note, however, that we are looking for a light-weight solution here and leave the heavy solution (e.g. popping up a UI to change the time) to #5774.
Cheers!
