anonym:
> Hi!
Hi, sorry for the delay in getting back to you. Being out of budget
didn't help.
I would love to see our time sync hacks go away. Redmine is down
right-now so I can't check the original tickets but I understand that
this also means, in terms of UX:
- Getting rid of the htpdate mess, the time sync notification, and their
obscure errors.
- Making obfs4 more resilient.
Correct? Both would be great UX benefits!
> 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.
Can we assume that consensus replays might not be detected if they are
replaying a consensus that is less than 24 hours old? This assumption
might simplify some corner cases.
> 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.
In both of these cases the hardware clock is too much ahead of the Tor
consensus. There's possibly a serious security threat but we can't
really know.
I'm wondering what Tor Browser does in such cases? If it does something
smart, we might get inspiration from it. If it does nothing or something
bad, we might ask Gus for how frequently people complain about it.
I mean, if people have their hardware clock too much in advance, Tails
would be affected as much as Tor Browser, right?
In your email you're not describing what happens when the clock is too
much in the past. For example, if the hardware clock is totally broken
because the battery of the hardware clock is dead. Wouldn't this be an
even more common case than clocks in the future?
> 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.
Would it be enough for the notification to display the day of the
hardware clock? Then:
- If the day is correct, then there's a consensus replay.
- If the user has Linux, then the day might be ± 1 day.
- If the day is wrong, then the user should fix it.
I'm afraid of telling people about the date of the consensus and asking
them to evaluate whether it's a replayed consensus, given the ± 24 h
approximation plus the timezone.
> 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.
I can smell some zenity here! Maybe a half-way solution could be to use
`zenity --calendar` to ask the user to change the date and try again?
https://help.gnome.org/users/zenity/stable/calendar.html.en
--
sajolida
Tails —
https://tails.boum.org/
UX · Fundraising · Technical Writing
