{{Header}} {{title|title= Network Time Synchronization }} {{#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 = It is recommended to have a host clock with accuracy of up to ± 30 minutes. Clocks that are hours, days, weeks, months or even years slow or fast can lead to many issues such as: * '''A)''' Connectivity problems with Tor: If the host clock is more than 1 hour in the past or more than 3 hours in the future, Tor cannot connect. * '''B)''' Inability to download operating system upgrades: APT (apt-get) and other tools can break and show errors until the clock is set correctly. Due to invalid (not yet or no longer valid) TLS certificates. Follow the recommendations below to avoid Tor connectivity problems and upgrade issues and to limit possible adverse security impacts. = All Platforms = In case of clock issues: * Kicksecure: ** [[Network_Time_Synchronization#Manually_Set_Clock_Time_and_Date|Manually Set Clock Time and Date]] In case of re-occurring clock issues: * Check for an empty computer battery. If the battery is empty, clock might be reset to its production date and time. If using {{project_name_long}} as a host {{os}}: Reboot. (Easiest.) If using a {{project_name_long}} {{VM}}: Easiest: Power off all VMs. Really power off. Not only reboot. Power on {{project_name_gateway_long}} and Tor should be able to reconnect. In case the user is using [[Network_Time_Synchronization#Block_Networking_until_sdwdate_Finishes|Block Networking until sdwdate Finishes]]; If Tor failed or took too long to connect, then you need to fix Tor connection first and then restart your sdwdate sudo systemctl restart sdwdate in your VM/Qube. = Easy instructions = {{non_q_project_name_short}} in VMs or as a host operating system: It is strongly discouraged to use the pause / suspend / save / hibernate features. {{q_project_name_long}} VMs: 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.
'''{{project_name_workstation_long}} as a host operating system or VM''': * It is strongly discouraged to pause / suspend / save / hibernate {{project_name_short}}. 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. '''{{q_project_name_short}}''': * VM: It is strongly discouraged to pause {{project_name_workstation_short}} VMs 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. Start Menu → Applications → System → Time Synchronization Monitor (sdwdate-gui) → restart sdwdate Or in a terminal. {{CodeSelect|code= sudo sdwdate-clock-jump }} = Manually Set Clock Time and Date = Usually not required. The first step should be completed on the host to ensure the host clock is set to the correct time. {{Box|text= '''1.''' On the host ([[Qubes|{{q_project_name_short}}]]: dom0), 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 }} {{PreBox| {{CURRENTMONTHABBREV}} {{CURRENTDAY2}} {{CURRENTTIME}}:44 UTC {{CURRENTYEAR}} }} '''x.''' {{sysmaint_notice}} '''2.''' Set the correct time in {{project_name_gateway_short}}. 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 }} '''3.''' Restart sdwdate. {{CodeSelect|code= sudo service sdwdate restart }} '''4.''' If Tor is still not functional, try restarting Tor. {{CodeSelect|code= sudo service tor restart }} Tor should work once correct clock values are set, but that can be manually tested with [[systemcheck]]. '''5.''' [[Network_Time_Synchronization#Set_Hardware_Clock_Time|Set Hardware Clock Time]] }} = Set Hardware Clock Time = Most systems have a Real-Time Clock (RTC) on the motherboard that keeps track of time while the system is powered down. On boot, the RTC is read and used to set the system clock to a sensible value. If a system is powered down for any length of time, it is important that it have a functional, up-to-date hardware clock. {{project_name_short}} does not currently synchronize the hardware clock to the system clock on shutdown. As a result, if the hardware clock is drifting out of date, it will continue to drift further and further out of date until problems result. To correct this: '''1.''' {{sysmaint_notice}} '''2.''' [[#Manually_Set_Clock_Time_and_Date|Set the system clock]]. '''3.''' Run: {{CodeSelect|code= sudo hwclock --systohc }} '''4.''' Done. The hardware clock has now been updated. == Broken / Missing Hardware Clocks == Many single-board computers do not have a hardware clock. Many systems also have a broken, drained, or missing BIOS battery, which will result in the hardware clock pausing or becoming corrupted if power is removed from the system even briefly. Usually these systems will need to have their clock [[#Manually_Set_Clock_Time_and_Date|manually set]] on every boot. There are a number of things that can be done to fix or mitigate this problem: * Replace the system's [https://en.wikipedia.org/wiki/Nonvolatile_BIOS_memory BIOS battery], if it has one. This is usually a CR2032 coin-cell battery located in a socket on the motherboard, but some laptops may enclose the battery in plastic and connect it to the motherboard with a short electrical cable. * Install the [https://packages.debian.org/bookworm/fake-hwclock fake-hwclock] package. This will save the system clock to disk periodically (including before shutdown) and restore it on boot, so that your system's time is frozen while powered off. This may make it easier to update the system clock to a sufficiently accurate time for Tor and sdwdate to function. * Install the [https://packages.debian.org/bookworm/ntpsec-ntpdate ntpsec-ntpdate] package. This provides the ntpdate command, which can be used to update the system clock from an NTP server. '''Note that NTP time synchronization may be vulnerable to man-in-the-middle attacks if the date and time are not double-checked against a known-good clock.''' ** Do NOT install the ntpsec package. It conflicts with sdwdate and will uninstall it (along with many {{project_name_short}}-related metapackages). To update the system clock using ntpdate: '''1.''' Run ntpdate -q pool.ntp.org to display the time and date from pool.ntp.org. '''2.''' Double-check the displayed date and time against a clock you know is accurate. '''3.''' Use sudo ntpdate pool.ntp.org to update the clock and display the time that the clock has updated to. '''4.''' Ensure that the date displayed after setting the clock is close to the date displayed when querying the server. '''5.''' Done. The process of setting the system time using NTP is complete. = sdwdate = * Can set the time if the clock is very slow. This is true even if Tor fails to bootstrap due to a very slow clock. sdwdate can set the clock using [[anondate]] from Tor consensus. * sdwdate never sets the time backwards. Only forwards. This is a security feature. Slow clocks can be a security issue because old, expired keys appear to be valid. Fast clocks however are only a functionality (and privacy) issue. = sdwdate = * Can set the time if the clock is very slow. This is true even if Tor fails to bootstrap due to a very slow clock. sdwdate can set the clock using [[anondate]] from Tor consensus. * sdwdate never sets the time backwards. Only forwards. This is a security feature. Slow clocks can be a security issue because old, expired keys appear to be valid. Fast clocks however are only a functionality (and privacy) issue. = Block Networking until sdwdate Finishes = [[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, blocking network access until sdwdate succeeds is sensible. https://forums.whonix.org/t/blocking-networking-until-sdwdate-finished/5372 Note: When using this feature, there will be no internet connectivity until sdwdate succeeded which could take approximately 2 minutes. How to enable this feature? [[Unsupported]]. This feature is has not been implemented yet for {{project_name_short}}. Developers are welcome to contribute to {{project_name_short}}. = Summary = '''Table:''' ''Network Time Synchonization Summary'' {| class="wikitable" |- ! scope="col"| '''Platform''' ! scope="col"| '''Recommendations''' |- ! scope="row"| All Platforms | * 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}} 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. |- ! 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 }} = Related = * [[Timezone]] * [[sdwdate]] * [[sdwdate-gui]] * [[Boot Clock Randomization]] * [[Time Attacks]] * [[Dev/sdwdate]] * [[Dev/TimeSync]] = Footnotes = {{reflist|close=1}} {{Footer}} [[Category:Documentation]]