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

Patrick · June 25, 2015, 12:42am

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:

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 · June 25, 2015, 3:14am

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 · June 25, 2015, 11:03am

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 · June 25, 2015, 5:57pm

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 · June 25, 2015, 8:52pm

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 · June 25, 2015, 11:58pm

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.