Network Time Synchronization
A reasonably accurate host clock is crucially important. An inaccurate clock can lead to:
- A) Broken internet connectivity, and
- B) Time Attacks.
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. 
Follow the platform-specific recommendations below to avoid Tor connectivity problems and to limit possible adverse anonymity impacts.
To protect against time zone leaks, the system clock inside Whonix ™ 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!  ) 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 Whonix-Gateway ™ (
sys-whonix) and Tor should be able to reconnect.
Non-Qubes-Whonix: It is strongly discouraged to use the pause / suspend / save / hibernate features.
Qubes-Whonix ™: 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.
If you are interested in using the pause / suspend / save / hibernate features, please click the expand button for further instructions.
- Whonix-Gateway ™: It is strongly discouraged to pause / suspend / save / hibernate the Whonix-Gateway ™, because it is difficult to restore the clock after resume.  If this advice is ignored, it is easiest to shutdown and restart Whonix-Gateway ™.
- Whonix-Workstation ™: It is strongly discouraged to pause / suspend / save / hibernate the Whonix-Workstation ™. If this advice is ignored, restart sdwdate after resume. 
- Whonix-Gateway ™: It is strongly discouraged to pause Whonix-Gateway ™ (
sys-whonix) using the pause feature of Qube Manager, because it is difficult to restore the clock after resume.  If this advice is ignored, it is easiest to shutdown and restart Whonix-Gateway ™.
- Whonix-Workstation ™: It is strongly discouraged to pause Whonix-Workstation ™ (
anon-whonix) using the pause feature of Qube Manager. If this advice is ignored, restart sdwdate after resume. 
- dom0 suspend / hibernate: It is safe to use the suspend or hibernate feature of dom0 and a manual restart of sdwdate is unnecessary. 
Start Menu →
Time Synchronization Monitor (sdwdate-gui) →
Or in a terminal. 
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.
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. 
sdwdate is functional on both Whonix-Gateway ™ and Whonix-Workstation ™, 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.  In this case, the user is only left with the protections afforded by Boot Clock Randomization. 
Inside Whonix-Gateway ™ and Whonix-Workstation ™.
(Qubes-Whonix ™: It is the easiest to apply changes in the Whonix-Gateway ™ and Whonix-Workstation ™ TemplateVMs since these settings will be inherited by all TemplateBasedVMs. Alternatively, apply this setting in TemplateBasedVMs, see footnote. )
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 clock [archive] 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.  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.
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.  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.  This is easily solved by manually fixing the clock on the host, then powering the Whonix-Gateway ™ (
sys-whonix) 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
For KVM, click on Expand on the right.
<clock offset='variable' adjustment='123456' basis='utc'>
adjustment attribute takes any arbitrary value for seconds. The user must pick a random value that is unknown to others, ranging between 0 and 900 (a 15 minute range).
Unfortunately, it is not yet possible to set a random clock offset for Qubes-Whonix ™ VMs to prevent clock correlation attacks since it is unsupported by Xen [archive]. A related issue is denying Qubes-Whonix ™ access to "clocksource=xen" [archive], which may not be possible without Linux kernel and/or Xen patches. For a detailed discussion of these issues, see here [archive].
For VirtualBox, click on Expand on the right.
VirtualBox has a feature to spoof the initial virtual hardware clock offset by setting the clock X milliseconds in the future or past. The syntax is outlined below.
VBoxManage modifyvm <name> --biossystemtimeoffset -<milliseconds> VBoxManage modifyvm <name> --biossystemtimeoffset +<milliseconds>
It is recommended to add a random delay within the following range.
VBoxManage modifyvm <name> --biossystemtimeoffset -60000 VBoxManage modifyvm <name> --biossystemtimeoffset +60000
A spoofing example is below. Users should select their own unique and random values for both the past (-) and future (+) within the specified range. Different values should be used for each distinct VM (on the host).
VBoxManage modifyvm "Whonix-Gateway" --biossystemtimeoffset -35017 VBoxManage modifyvm "Whonix-Gateway" --biossystemtimeoffset +27931 VBoxManage modifyvm "Whonix-Workstation ™" --biossystemtimeoffset -35017 VBoxManage modifyvm "Whonix-Workstation ™" --biossystemtimeoffset +27931
Table: Network Time Synchonization Summary
Deactivate Automatic TimeSync
To deactivate sdwdate, run.
sudo service sdwdate stop
sudo systemctl mask sdwdate
- Due to invalid (not yet or no longer valid) TLS certificates.
To view the system time in UTC on Linux platforms, run.
- TODO: Show desktop clock in local time; keep system in UTC [archive]
- 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 Whonix-Gateway ™ 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.
Similarly, if users suspend or save the Whonix-Workstation ™ state, the clock will again lag behind the correct value. This can be manually fixed by running:
Time Synchronization Monitor (sdwdate-gui)→
Qubes does not dispatch the
/etc/qubes/suspend-pre.dhooks upon pause / resume using Qube Manager.
- https://github.com/QubesOS/qubes-issues/issues/1764 [archive]
Simplified in next upgrade.
Mon Apr 22 04:30:44 UTC 2019
A non-zero exit codes signifies an error, while
0means it succeeded.
echo "Sat Oct 26 07:18:25 UTC 2019" | /usr/bin/clock-random-manual-cli
- https://forums.whonix.org/t/testers-wanted-blocking-networking-until-sdwdate-finished-status-of-sdwdate-gui/5372 [archive]
- https://phabricator.whonix.org/T533 [archive]
The procedure can optionally be completed in select TemplateBasedVMs (AppVMs) like
- See the Fingerprint page to discover what fingerprinting means in this case.
- See Design: Dev/TimeSync.
- In this case, Tor cannot verify the Tor consensus.
biossystemtimeoffsetis used to unlink the virtualizer's initial clock synchronization of the VM from the host clock.
- After powering on a VM, it initially synchronizes the VM clock with the host clock until Whonix ™ Timesync adjusts it.
- Clock skews can lead to linkability, meaning the user would be pseudonymous rather than anonymous.