Secure, Distribiuted TimeSync on the Host, any Host, not just Whonix

[Patrick]

Even if we had a Whonix host additions (https://phabricator.whonix.org/T21) package, it would still be unclear on how to securely sync the time on the host. Conceptually unclear.

Running sdwdate, distributed fetching time from Tor hidden services isn’t possible for users in censored areas. They might even want to avoid connecting to the Tor public network.

Trying to find a solution here that works for any host. Not just for Whonix, Tor users.

Any “check if connecting to the public Tor network is okay for you or dangerous, even though you might not care about Tor” + “oh well, there are also all sorts of bridges stuff” seems awful.

Current user documentation:

• https://www.whonix.org/wiki/Post_Install_Advice#Network_Time_Syncing
• https://www.whonix.org/wiki/Advanced_Security_Guide#Network_Time_Synchronization

Current design documentation:

• https://www.whonix.org/wiki/Dev/TimeSync

Related ticket:
reorganize Pre Install Advice vs Post Install Advice vs Security Guide vs Advanced Security Guide
https://phabricator.whonix.org/T141

The latest plan by Tails ‘Ask the user what time it is’:
https://tails.boum.org/blueprint/robust_time_syncing/

[HulaHoop]

I think that’s really a Tor problem and how well it handles initial connection decisions with the Tor-launcher wizard. sdwdate shouldn’t have to ask these questions.

[Patrick]

We want a reasonable correct time on the host so or so. It’s important for (package upgrade) verification purposes. And a secure way to obtain the time. Whonix/Tor/anonymity is not the main reason for this.

This most likely doesn’t belong into sdwdate, which is a (terminal-only) daemon, which in essence fetches time from Tor hidden services. Having sdwdate include a gui tool to ask the time would be awful. Maybe using a plugin that calls a separate project, but probably not. As said above, sdwdate on the host is problematic, because not everyone can/wants/should use it.

Any ‘Ask the user what time it is’ [on the host] solution, if that’s any good/useful one, would be a separate project.

[HulaHoop]

Yes it should be its own project but the question is how will it know that the system time is wrong to begin with to warrant prompting the user for a manual adjustment?

I don’t think this is really a big problem because time is set during system install and the hardware clock has its own battery to keep the time persistent across reboots.

[Patrick]

Yes it should be its own project but the question is how will it know that the system time is wrong to begin with to warrant prompting the user for a manual adjustment?

Maybe it should not run on it’s own. Only started by triggers. Using .d-style drop-in files. When? Distributions decide. Examples:

• after installation, at first boot
• when Tor fails for time syncing related reasons

[HulaHoop]

Yes all good ideas for triggering. The Tor one might be the easier to write for but they all make sense especially for distro integration choices.