{{Header}} {{#seo: |description=A reasonably accurate host clock is required for many general security properties. An inaccurate clock can lead to broken internet connectivity and time related security issues. |image=TineSynchronization2134234.jpg }} {{time_mininav}} [[File:TineSynchronization2134234.jpg|thumb]] {{intro| A reasonably accurate host clock is required for many general security properties. An inaccurate clock can lead to broken internet connectivity and time related security issues. }} = Introduction = {{mbox | image = [[File:Ambox_warning_pn.svg.png|40px]] | text = '''Warning:''' The system clock inside {{project_name_long}} 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 ([[timezone]]). It is strongly recommended not to change this setting. }} = Warnings = 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. Due to invalid (not yet or no longer valid) TLS certificates. Follow the platform-specific recommendations below to avoid Tor connectivity problems and to limit possible adverse anonymity impacts. = Host Clock = Your computer's host clock must have an accuracy of at least ±30 minutes, ideally better. Otherwise, connectivity can be broken. A minutes range of accuracy is more than enough for {{project_name_short}}. No need for seconds or let alone nanoseconds accuracy resolution. * '''Prerequisite knowledge:''' time formats, 12 hours AM/PM, 24 hours format, timezones. (Common knowledge. Not specific to computers.) * '''Generic task:''' Check your computer's time and make sure it is reasonably correct. * '''Operating system specific:''' Select your host operating system. {{Tab |type=controller |addToClass=tcc-indent |content= {{Tab |active=true |addToClass=margin-top-20 |title= == Linux == |image=[[File:Logo-linux-variety-500x500.png|50px]] |content= '''1.''' Host timezone. The host timezone can stay as is. There is no need at all to change the host timezone for the sake of a functional {{project_name_short}} connectivity. '''2''' Notice. This is [[Unspecific|unspecific to {{project_name_short}}]]. This wiki chapter is only about making sure the host clock is reasonably correct. There is no need to specifically follow these steps, unless difficulties are being experienced. In case of issues, contact the support of your host operating system. '''3.''' Find out the time in UTC. Any website or device can be used. '''4.''' Show the current system time in UTC using GNU date. This is useful: * To find out the current system time of your computer in UTC timezone format. * To learn the text output format of GNU date. {{CodeSelect|code= date --utc }} Sample output: 
Fri 05 May 2023 08:10:30 AM UTC
'''5.''' Fix the clock, if necessary. Choose either option '''A)''' or '''B)'''. NOTE: For the following command, use the current time. Adjust the time to the actual time. Do not use the example time used below. * '''A)''' Using any method supported by your host operating system. * '''B)''' Using command line with GNU date: {{CodeSelect|code= sudo date --utc --set "Fri 05 May 2023 11:30:50 AM UTC" }} '''6.''' Update the hardware clock. {{CodeSelect|code= sudo hwclock --utc --systohc }} (--systohc stands for system to hardware clock.) '''7.''' Show the current system time in UTC using GNU date. {{CodeSelect|code= date --utc }} '''8.''' Compare the system clock with the hardware clock. Time formats might be different, but the time should be the same or very similar. {{CodeSelect|code= sudo date --utc && sudo hwclock --utc }} '''9.''' Reboot. Optional. Reboot and recheck if the clock is correct. Usually should be. Only in rare cases of broken hardware clocks, the time might be wrong. '''9.''' Done. The process of correcting the host clock has been completed. }} {{Tab |addToClass=margin-top-20 |title= == Qubes == |image=[[File:Qubes-logo-icon.png|50px]] |content= Related Qubes upstream bugs: * [https://github.com/QubesOS/qubes-issues/issues/8173 Qubes dom0 clock fix difficult, ClockVM does not fix its own clock] Instructions: '''1.''' [[Unspecific|Unspecific to {{project_name_short}}]]. [[Undocumented]]. '''2.''' Same instructions as under the 'Linux' tab can be used. '''3.''' Use [https://www.qubes-os.org/support/ Qubes support]. '''4.''' Done. }} {{Tab |addToClass=margin-top-20 |title= == Windows == |image=[[File:Logo-windows-500x500.png|50px]] |content= [[Unspecific|Unspecific to {{project_name_short}}]]. [[Undocumented]]. Contact the support of your host operating system. }} }} = All Platforms = To protect against time zone leaks, the system clock inside {{project_name_short}} 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! To view the system time in UTC on Linux platforms, run: {{CodeSelect|code= date --utc }} TODO: [https://phabricator.whonix.org/T71 Show desktop clock in local time; keep system in UTC] ) is more than 1 hour in the past or more than 3 hours in the future, '''Tor cannot connect'''. In this case, '''1.''' Manually fix the host clock by right-clicking on it. See detailed instructions [[#Host_Clock|Host Clock]], '''2.''' Check for an empty BIOS (computer motherboard) battery. '''3.''' Power off {{project_name_gateway_short}}. '''4.''' Power on {{project_name_gateway_short}}. '''5.''' Done. Tor should be able to reconnect. = Clock Accuracy = A number of things influences clock accuracy inside {{project_name_short}} VMs. * {{kicksecure_wiki |wikipage=Boot_Clock_Randomization |text=Boot Clock Randomization }} * [[sdwdate]]: {{kicksecure_wiki |wikipage=Sdwdate#sdwdate_Clock_Randomization |text=sdwdate Clock Randomization }} * Generally, sdwdate accuracy is limited because it fetches time over Tor from onions. * [[Timezone]]: While not influencing clock accuracy, this can lead to confusion. **
To protect against time zone leaks, the system clock inside {{project_name_short}} 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!
= Easy instructions = '''1.''' Select your platform. {{Tab |type=controller |linkid=platform |content= {{Tab| |active=true |title= == {{non_q_project_name_short}} == |content= Recommendation: It is strongly discouraged to use the pause / suspend / save / hibernate features. VirtualBox does not provide notifications to VMs upon resume. }} {{Tab| |title= == {{q_project_name_short}} == |content= Recommendation: 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. This is because dom0 will notify VMs upon resume. This will result in sdwdate restarting and fixing the clock. }} }} '''2.''' Background information. Rationale: The clock will be slow after resume. This can break Tor connectivity. '''3.''' Fix. How to fix if you did this anyhow? Power off the VMs and restart these. Really power off. Not only Reboot. Then everything will be back to normal. '''4.''' Done. = Advanced instructions =
If you are interested in using the pause / suspend / save / hibernate features, please click the expand button for further instructions.
{{Tab |type=controller |linkid=platform |content= Select your platform. {{Tab| |active=true |title= == {{non_q_project_name_short}} == |content= * {{project_name_gateway_short}}: It is strongly discouraged to pause / suspend / save / hibernate the {{project_name_gateway_short}}, because it is difficult to restore the clock after resume. 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 {{project_name_gateway_short}} 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. If this advice is ignored, it is easiest to shutdown and restart {{project_name_gateway_short}}. * {{project_name_workstation_long}}: It is strongly discouraged to pause / suspend / save / hibernate the {{project_name_workstation_long}}. If this advice is ignored, [[#Restart sdwdate|restart sdwdate]] after resume. Similarly, if users suspend or save the {{project_name_workstation_short}} 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. }} {{Tab| |title= == {{q_project_name_short}} == |content= * {{project_name_gateway_short}}: It is strongly discouraged to pause {{project_name_gateway_short}} ({{project_name_gateway_vm}}) 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 {{project_name_gateway_short}}. * {{project_name_workstation_short}}: It is strongly discouraged to pause {{project_name_workstation_short}} ({{project_name_workstation_vm}}) using the pause feature of Qube Manager. If this advice is ignored, [[#Restart sdwdate|restart sdwdate]] after resume. Qubes does not dispatch the /etc/qubes/suspend-post.d / /etc/qubes/suspend-pre.d hooks upon pause / resume using Qube Manager. * dom0 suspend / hibernate: It is safe to use the suspend or hibernate feature of dom0 and a manual restart of sdwdate is unnecessary. https://github.com/QubesOS/qubes-issues/issues/1764 }} }}
= Restart sdwdate = To restart sdwdate chose either option A or B. * '''A)''' {{Gui}}: Start Menu → Applications → System → Time Synchronization Monitor (sdwdate-gui) → restart sdwdate * '''B)''' {{Cli}}: {{CodeSelect|inline=true|code= sudo sdwdate-clock-jump }} = Manually Set Clock Time and Date = Usually not required. In case [[Sdwdate|sdwdate]] fails to properly randomize the system clock, it is possible to manually set a random value. This simulates what sdwdate would have done. The first step should be completed on the host to ensure the host clock is set to the correct time. The next step will be to correct the time inside the {{VM}}. {{Box|text= '''1.''' Platform specific notice. * [[Non-Qubes-Whonix|{{non_q_project_name_short}}]]: On the host * [[Qubes|{{q_project_name_short}}]]: dom0 '''2.''' Run the following command to report the time in UTC. {{CodeSelect|code= date --utc }} The output should be similar to the following. {{CodeSelect|code= Mon Apr 22 04:30:44 UTC 2019 }} {{CodeSelect|code= {{CURRENTMONTHABBREV}} {{CURRENTDAY2}} {{CURRENTTIME}}:44 UTC {{CURRENTYEAR}} }} '''3.''' Set the correct time inside the VM Such as {{project_name_gateway_short}} ({{project_name_gateway_vm}}). Run the following command with the correct date and time parameters. A non-zero exit codes signifies an error, while 0 means it succeeded. Also see: {{CodeSelect|code= man clock-random-manual-gui }} {{CodeSelect|code= man clock-random-manual-cli }} * 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 {{CodeSelect|code= echo "Sat Oct 26 07:18:25 UTC 2019" {{!}} /usr/bin/clock-random-manual-cli }} : {{CodeSelect|code= echo "{{CURRENTMONTHABBREV}} {{CURRENTDAY2}} {{CURRENTTIME}}:44 UTC {{CURRENTYEAR}}" {{!}} sudo clock-random-manual-cli }} '''4.''' Restart sdwdate. {{CodeSelect|code= sudo service sdwdate restart }} '''5.''' If Tor is still not functional, try restarting Tor. Only useful on {{project_name_gateway_short}}. {{CodeSelect|code= sudo service tor restart }} '''6.''' Done. Tor should work once correct clock values are set, but that can be manually tested with {{kicksecure_wiki |wikipage=systemcheck |text=systemcheck }}. }} = Block Networking until sdwdate Finishes = == Rationale == [[Sdwdate|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. https://forums.whonix.org/t/testers-wanted-blocking-networking-until-sdwdate-finished-status-of-sdwdate-gui/5372 [[sdwdate]] is functional on both {{project_name_gateway_short}} and {{project_name_workstation_short}}, 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 changes the system clock for the first time after boot. https://phabricator.whonix.org/T533 In this case, the user is only left with the protections afforded by [[Boot Clock Randomization]]. [[Dev/TimeSync#Block_Networking_until_sdwdate_Finishes]] == Enable == {{Testers-Only}} Note: The following instructions should be applied on {{project_name_gateway_short}} and inside {{project_name_workstation_short}}. ([[Qubes|{{q_project_name_short}}]]: It is the easiest to apply changes in the {{project_name_gateway_short}} and {{project_name_workstation_short}} Templates since these settings will be inherited by all App Qubes. Alternatively, apply this setting in App Qubes, see footnote. {{mbox | type = notice | image = [[File:Ambox_notice.png|40px|alt=Info]] | text = [[Qubes|{{q_project_name_short}}]] only. }} The procedure can optionally be completed in select App Qubes like {{project_name_gateway_vm}} and {{project_name_workstation_vm}}. {{Box|text= '''1.''' Edit the {{project_name_short}} firewall configuration. In the chosen {{project_name_short}} App Qube, run. {{Open with root rights|filename= /usr/local/etc/whonix_firewall.d/*.conf }} '''2.''' Copy and paste the following text. {{CodeSelect|code= firewall_mode= }} '''3.''' Save the file and reboot. }} ) {{Box|text= '''1.''' Edit the {{project_name_short}} firewall configuration. In ''both'' {{project_name_gateway_short}} ({{project_name_gateway_template}}) and {{project_name_workstation_short}} ({{project_name_workstation_template}}), run. {{Open with root rights|filename= /etc/whonix_firewall.d/50_user.conf }} '''2.''' Copy and paste the following text. {{CodeSelect|code= firewall_mode= }} '''3.''' Save the file and reboot. '''4.''' Have the changes take effect. * {{non_q_project_name_long}}: restart {{project_name_gateway_short}} and {{project_name_workstation_short}}. * {{q_project_name_short}}: shutdown the {{project_name_gateway_short}} ({{project_name_gateway_template}}) and {{project_name_workstation_short}} ({{project_name_workstation_template}}) Templates and restart the App Qube ({{project_name_gateway_vm}} and {{project_name_workstation_vm}}). }} = NTP = == Disabling NTP == If ISP tampering with NTP is ever confirmed, users are advised to [[Time_Attacks#GNU.2FLinux_Host|disable NTP]] and manually update the host clock out-of-band. For example, a watch or [https://en.wikipedia.org/wiki/Atomic_clock atomic clock] 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 [[Warning#Confirmation_Attacks|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. See the [[Fingerprint]] page to discover what fingerprinting means in this case. 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. See Design: [[Dev/TimeSync]]. 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. In this case, Tor cannot verify the Tor consensus. This is easily solved by manually fixing the clock on the host, then powering the {{project_name_gateway_short}} ({{project_name_gateway_vm}}) 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 = {{mbox | type = notice | image = [[File:Ambox_notice.png|40px|alt=Info]] | text = '''Tip:''' Spoofing the initial virtual hardware clock offset is useful to prevent [[Dev/TimeSync#Clock_Correlation_Attack|Clock Correlation Attacks]]. }} == KVM ==
For KVM, click on Expand on the right.
[[KVM#Optional:_XML_Modification|Edit the VM xml before import]] or [[KVM#Editing_an_Imported_Machine's_XML_Configuration|edit the VM xml after import]] and change the following setting. {{CodeSelect|code= }} To. {{CodeSelect|code= }} The 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).
== Qubes == TODO Unfortunately, it is not yet possible to set a random clock offset for {{q_project_name_short}} VMs to prevent clock correlation attacks since it is [https://phabricator.whonix.org/T440 unsupported by Xen]. A related issue is [https://phabricator.whonix.org/T389 denying {{q_project_name_short}} access to "clocksource=xen"], which may not be possible without Linux kernel and/or Xen patches. For a detailed discussion of these issues, see [https://groups.google.com/g/qubes-devel/c/aN3IOv6JmKw here]. == VirtualBox ==
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. {{CodeSelect|code= VBoxManage modifyvm --biossystemtimeoffset - VBoxManage modifyvm --biossystemtimeoffset + }} It is recommended to add a random delay within the following range. {{CodeSelect|code= VBoxManage modifyvm --biossystemtimeoffset -60000 VBoxManage modifyvm --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). {{CodeSelect|code= VBoxManage modifyvm "{{project_name_gateway_short}}" --biossystemtimeoffset -35017 VBoxManage modifyvm "{{project_name_gateway_short}}" --biossystemtimeoffset +27931 VBoxManage modifyvm "{{project_name_workstation_short}}" --biossystemtimeoffset -35017 VBoxManage modifyvm "{{project_name_workstation_short}}" --biossystemtimeoffset +27931 }} Apart from this small biossystemtimeoffset, a clock skew always degrades privacy. biossystemtimeoffset is 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 {{project_name_short}} Timesync adjusts it. Clock skews can lead to linkability, meaning the user would be [[Tips_on_Remaining_Anonymous#Study:_Anonymity_and_Pseudonymity_are_not_the_same|pseudonymous rather than anonymous]].
= Summary = '''Table:''' ''Network Time Synchonization Summary'' {| class="wikitable" |- ! scope="col"| '''Platform''' ! scope="col"| '''Recommendations''' |- ! scope="row"| All Platforms | * [[timezone|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 {{project_name_gateway_short}} ({{project_name_gateway_vm}}) 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|block networking until sdwdate finishes]]. |- ! scope="row"| {{non_q_project_name_short}} | * It is strongly discouraged to use the pause / suspend / save / hibernate features. * Only [[#Spoof_the_Initial_Virtual_Hardware_Clock_Offset|spoof the initial virtual hardware clock offset]] after importing the VM. |- ! scope="row"| {{q_project_name_short}} | * 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 == {{mbox | image = [[File:Ambox_warning_pn.svg.png|40px]] | text = '''Warning:''' This action is recommended against and is usually not required. In all cases, first check with the {{project_name_short}} developers. }} To deactivate sdwdate, run. {{CodeSelect|code= sudo service sdwdate stop }} {{CodeSelect|code= sudo systemctl mask sdwdate }} = Footnotes = {{reflist|close=1}} {{Footer}} [[Category:Documentation]]