Network Time Synchronization

From Kicksecure
Revision as of 10:09, 15 December 2021 by Nurmagoz (talk | contribs)
Jump to navigation Jump to search

Introduction

Warning: The system clock inside Kicksecure is set to UTC to prevent against time zone leaks. This means it may be a few hours ahead or behind the user's host system clock. It is strongly recommended not to change this setting.

Warnings

A reasonably accurate host clock is crucially important. An inaccurate clock can lead to:

Therefore, at all times it is recommended to have a host clock with accuracy of up to ± 30 minutes. Clocks that are days, weeks, months or even years slow or fast can lead to many issues such as connectivity problems with Tor, inability to download operating system upgrades and inaccessible websites. [1]

Follow the platform-specific recommendations below to avoid Tor connectivity problems and to limit possible adverse anonymity impacts.

All Platforms

To protect against time zone leaks, the system clock inside Kicksecure is set to UTC. This means it may be a few hours before or ahead of your host system clock. Do not change this setting!

If the host clock (in UTC! [2] [3]) is more than 1 hour in the past or more than 3 hours in the future, Tor cannot connect. In this case, manually fix the host clock by right-clicking on it, and also check for an empty battery. Then, power off and power on the Kicksecure (kicksecure) and Tor should be able to reconnect.

Easy instructions

Kicksecure: It is strongly discouraged to use the pause / suspend / save / hibernate features.

Template:Q project name: It is strongly discouraged to use the pause feature of Qube Manager, but it is is safe to use the suspend or hibernate feature of dom0.

Advanced instructions

If you are interested in using the pause / suspend / save / hibernate features, please click the expand button for further instructions.

Restart sdwdate

To restart sdwdate.

Start Menu → Applications → System → Time Synchronization Monitor (sdwdate-gui) → restart sdwdate

Or in a terminal. [8]

Click = Copy Copied to clipboard! sudo /usr/lib/sdwdate/restart_fresh

Manually Set Clock Time and Date

Usually not required.

In case sdwdate fails to properly randomize the system clock, it is possible to manually set a random value.

The first step should be completed on the host to ensure the host clock is set to the correct time.

1. On the host ([[Kicksecure-Qubes|Template:Q project name]]: dom0), run the following command to report the time in UTC.

Click = Copy Copied to clipboard! date -u

The output should be similar to the following. [9]

Click = Copy Copied to clipboard! Apr 09 23:21:44 UTC 2025

2. Set the correct time in Kicksecure (kicksecure).

Run the following command with the correct date and time parameters. [10] [11]

  • clock-random-manual-gui: a randomized clock setting (in UTC) is entered via a GUI.
  • clock-random-manual-cli: a randomized clock setting (in UTC) is entered on the command line. For example [12]:

Click = Copy Copied to clipboard! echo "Apr 09 23:21:44 UTC 2025" | sudo clock-random-manual-cli

3. Restart sdwdate.

Click = Copy Copied to clipboard! sudo service sdwdate restart

4. If Tor is still not functional, try restarting Tor.

Click = Copy Copied to clipboard! sudo service tor restart

Tor should work once correct clock values are set, but that can be manually tested with systemcheck.

Block Networking until sdwdate Finishes

sdwdate is a Tor-friendly replacement for rdate and ntpdate that sets the system's clock by communicating via end-to-end encrypted TCP with Tor onion webservers. Since timekeeping is crucial for security and anonymity, blocking network access until sdwdate succeeds is sensible. [13]

sdwdate is functional on both Kicksecure and Kicksecure, but in some cases it is possible for the time to leak before it is changed. Potential leak channels include time or other servers, daemons, and client programs such as Tor Browser which are used before sdwdate successfully finishes. [14] In this case, the user is only left with the protections afforded by Boot Clock Randomization. [15]

Inside Kicksecure and Kicksecure.

([[Qubes|Template:Q project name]]: It is the easiest to apply changes in the Kicksecure and Kicksecure TemplateVMs since these settings will be inherited by all TemplateBasedVMs. Alternatively, apply this setting in TemplateBasedVMs, see footnote. [16])

1. Edit the Kicksecure firewall configuration.

In both Kicksecure (kicksecure-17) and Kicksecure (kicksecure-17), run.

Open file /etc/whonix_firewall.d/50_user.conf in an editor with root rights.

Kicksecure

See Open File with Root RightsOnion network Logo for detailed instructions on why to use sudoedit for better security and how to use it.

Note: Mousepad (or the chosen text editor) must be closed before running the sudoedit command.

Click = Copy Copied to clipboard! sudoedit /etc/whonix_firewall.d/50_user.conf

Kicksecure for Qubes

NOTES:

Click = Copy Copied to clipboard! sudoedit /etc/whonix_firewall.d/50_user.conf

  • After applying this change, shutdown the Template.
  • All App Qubes based on the Template need to be restarted if they were already running.
  • This is a general procedure required for Qubes and unspecific to Kicksecure for Qubes.

Others and Alternatives

  • This is just an example. Other tools could achieve the same goal.
  • If this example does not work for you or if you are not using Kicksecure, please refer to this link.

Click = Copy Copied to clipboard! sudoedit /etc/whonix_firewall.d/50_user.conf

2. Copy and paste the following text.

Click = Copy Copied to clipboard! firewall_mode=

3. Save the file and reboot.

4. Have the changes take effect.

NTP

Disabling NTP

If ISP tampering with NTP is ever confirmed, users are advised to disable NTP and manually update the host clock out-of-band. For example, a watch or atomic clockarchive.org iconarchive.today icon can be used for this purpose. If the tampering is targeted and not a widescale attack, then the user already has much bigger problems to worry about than NTP; see Confirmation Attacks.

If following the advice above -- disabling NTP on the host and adjusting the clock out-of-band -- be aware that clearnet traffic might be easier to fingerprint. [17] The reason is that it introduces a device issuing clearnet traffic (such as OS updates), but without the use of NTP. It is unknown how many people have NTP which is deactivated, broken, uninstalled, or never in fact installed in the first place. Also unknown is how many people are using alternative time synchronization methods such as authenticated NTP, tails_htp, tlsdate, sdwdate or similar. However, search engine research suggests that very few people fall into both these categories.

NTP Issues

The host system clock synchronization mechanism still uses unauthenticated NTP from a single source. This is not optimal, but there is no real solution to this problem. [18] A potential attack vector is created by this NTP behavior; the ISP and/or time server could either inadvertently or maliciously introduce a significant clock skew, or the host clock could simply malfunction.

If the host clock value is grossly inaccurate -- more than one hour in the past or more than 3 hours in future -- Tor cannot connect to the Tor network. [19] This is easily solved by manually fixing the clock on the host, then powering the Kicksecure (kicksecure) off and on again.

Another side effect of a significantly inaccurate host clock concerns operating system (OS) updates and cryptographic verification on the host. Until the host clock is manually fixed, it may no longer be possible to download updates or verify SSL certificates correctly with the host browser.

Users should always check whether a host clock defect relates to an empty battery before assuming the ISP is tampering with NTP.

Spoof the Initial Virtual Hardware Clock Offset

Info Tip: Spoofing the initial virtual hardware clock offset is useful to prevent Clock Correlation Attacks.

KVM

For KVM, click on Expand on the right.

Qubes

TODO

Unfortunately, it is not yet possible to set a random clock offset for Template:Q project name VMs to prevent clock correlation attacks since it is unsupported by Xenarchive.org iconarchive.today icon. A related issue is denying Template:Q project name access to "clocksource=xen"archive.org iconarchive.today icon, which may not be possible without Linux kernel and/or Xen patches. For a detailed discussion of these issues, see herearchive.org iconarchive.today icon.

VirtualBox

For VirtualBox, click on Expand on the right.

Summary

Table: Network Time Synchonization Summary

Platform Recommendations
All Platforms
  • Do not change system timezone.
  • Tor cannot connect if the host clock is grossly inaccurate. In this case, users should manually fix the host clock before powering the Kicksecure (kicksecure) off and on again.
  • Periodically check the host clock to ensure that it is accurate or approximately so.
  • For greater security, block networking until sdwdate finishes.
Kicksecure
Kicksecure-Qubes
  • It is strongly discouraged to use the pause feature of Qube Manager.
  • it is is safe to use the suspend or hibernate feature of dom0.

Appendix

Deactivate Automatic TimeSync

Warning: This action is recommended against and is usually not required. In all cases, first check with the Kicksecure developers.

To deactivate sdwdate, run.

Click = Copy Copied to clipboard! sudo service sdwdate stop

Click = Copy Copied to clipboard! sudo systemctl mask sdwdate

Related

Footnotes

  1. ↑ Due to invalid (not yet or no longer valid) TLS certificates.
  2. ↑ To view the system time in UTC on Linux platforms, run. Click = Copy Copied to clipboard! date --utc
  3. ↑ TODO: Show desktop clock in local time; keep system in UTCarchive.org iconarchive.today icon
  4. ↑ Jump up to: 4.0 4.1 This is because the clock will be incorrect after system resume. A correct clock is important for anonymity (see Dev/TimeSync to learn more). When a user suspends or saves the VM state, the clock will stop and continue after resuming, leading to a time that lags behind the correct value. This can cause later Tor connectivity problems or introduce possible adverse anonymity impacts. The Kicksecure state should not be suspended or saved. It is far better to power it off when it is no longer needed. If this advice is ignored, Tor can become confused if the time is more than 1 hour in the past or more than 3 hours in the future. When this happens, Tor will only reconnect to the Tor network if the clock is manually fixed or powered off and on again.
  5. ↑ Similarly, if users suspend or save the Kicksecure state, the clock will again lag behind the correct value. This can be manually fixed by running: Start Menu → Applications → System → Time Synchronization Monitor (sdwdate-gui) → restart sdwdate.
  6. ↑ Qubes does not dispatch the /etc/qubes/suspend-post.d / /etc/qubes/suspend-pre.d hooks upon pause / resume using Qube Manager.
  7. ↑ https://github.com/QubesOS/qubes-issues/issues/1764archive.org iconarchive.today icon
  8. ↑ Simplified in next upgrade. Click = Copy Copied to clipboard! sudo sdwdate-clock-jump
  9. ↑ Click = Copy Copied to clipboard! Mon Apr 22 04:30:44 UTC 2019
  10. ↑ A non-zero exit codes signifies an error, while 0 means it succeeded.
  11. ↑ Also see: Click = Copy Copied to clipboard! man clock-random-manual-gui Click = Copy Copied to clipboard! man clock-random-manual-cli
  12. ↑ Click = Copy Copied to clipboard! echo "Sat Oct 26 07:18:25 UTC 2019" | /usr/bin/clock-random-manual-cli
  13. ↑ https://forums.whonix.org/t/testers-wanted-blocking-networking-until-sdwdate-finished-status-of-sdwdate-gui/5372archive.org iconarchive.today icon
  14. ↑ https://phabricator.whonix.org/T533archive.org iconarchive.today icon
  15. ↑ Dev/TimeSync#Block_Networking_until_sdwdate_Finishes
  16. ↑

    Info [[Kicksecure-Qubes|Template:Q project name]] only.

    The procedure can optionally be completed in select TemplateBasedVMs (AppVMs) like kicksecure and kicksecure.

    1. Edit the Kicksecure firewall configuration.

    In the chosen Kicksecure TemplateBasedVMs, run.

    Open file /usr/local/etc/whonix_firewall.d/*.conf in an editor with root rights.

    Kicksecure

    See Open File with Root RightsOnion network Logo for detailed instructions on why to use sudoedit for better security and how to use it.

    Note: Mousepad (or the chosen text editor) must be closed before running the sudoedit command.

    Click = Copy Copied to clipboard! sudoedit /usr/local/etc/whonix_firewall.d/*.conf

    Kicksecure for Qubes

    NOTES:

    Click = Copy Copied to clipboard! sudoedit /usr/local/etc/whonix_firewall.d/*.conf

    • After applying this change, shutdown the Template.
    • All App Qubes based on the Template need to be restarted if they were already running.
    • This is a general procedure required for Qubes and unspecific to Kicksecure for Qubes.

    Others and Alternatives

    • This is just an example. Other tools could achieve the same goal.
    • If this example does not work for you or if you are not using Kicksecure, please refer to this link.

    Click = Copy Copied to clipboard! sudoedit /usr/local/etc/whonix_firewall.d/*.conf

    2. Copy and paste the following text.

    Click = Copy Copied to clipboard! firewall_mode=

    3. Save the file and reboot.

  17. ↑ See the Fingerprint page to discover what fingerprinting means in this case.
  18. ↑ See Design: Dev/TimeSync.
  19. ↑ In this case, Tor cannot verify the Tor consensus.
  20. ↑ biossystemtimeoffset is used to unlink the virtualizer's initial clock synchronization of the VM from the host clock.
  21. ↑ After powering on a VM, it initially synchronizes the VM clock with the host clock until Kicksecure Timesync adjusts it.
  22. ↑ Clock skews can lead to linkability, meaning the user would be pseudonymous rather than anonymous.
Notification image
Your support makes
all the difference!

We believe security software like Kicksecure needs to remain Open Source and independent. Would you help sustain and grow the project? Learn more about our 12 year success story and maybe DONATE!

Retrieved from "https://www.kicksecure.com/w/index.php?title=Network_Time_Synchronization&oldid=53725"