Actions

Network Time Synchronization

Introduction[edit]

Block Networking until sdwdate Finishes[edit]

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. [1]


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. [4] In this case, the user is only left with the protections afforded by Boot Clock Randomization. [5]

TemplateVMs[edit]


It is easiest to apply changes in the Whonix-Gateway and Whonix-Workstation TemplateVMs. In Qubes-Whonix, these settings will be inherited by all TemplateBasedVMs.

In both Whonix-Gateway (whonix-gw-14) and Whonix-Workstation (whonix-ws-14), run.

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

If you are using a graphical Whonix or Qubes-Whonix, run.

kdesudo kwrite /etc/whonix_firewall.d/50_user.conf

If you are using a terminal-only Whonix, run.

sudo nano /etc/whonix_firewall.d/50_user.conf

Copy and paste the following text.

firewall_mode=

Save the file and reboot.

To have changes take effect:

  • Non-Qubes-Whonix: restart Whonix-Gateway and Whonix-Workstation.
  • Qubes-Whonix: shutdown the Whonix-Gateway (whonix-gw-14) and Whonix-Workstation (whonix-ws-14) TemplateVMs and restart the TemplateBasedVMs (sys-whonix and anon-whonix).

Qubes-Whonix TemplateBasedVMs[edit]


The procedure can optionally be completed in select TemplateBasedVMs (AppVMs) like sys-whonix and anon-whonix.

In the chosen Whonix TemplateBasedVM(s), run.

Open /rw/config/whonix_firewall.d/*.conf in an editor with root rights.

If you are using a graphical Whonix or Qubes-Whonix, run.

kdesudo kwrite /rw/config/whonix_firewall.d/*.conf

If you are using a terminal-only Whonix, run.

sudo nano /rw/config/whonix_firewall.d/*.conf

Copy and paste the following text.

firewall_mode=

Save the file and reboot.

Enable sdwdate-gui[edit]

Non-Qubes-Whonix[edit]

By default, sdwdate-gui automatically starts when Whonix-Gateway is booted. This keeps users informed about the status of the Tor network connection and sdwdate's progress, and also helps to test this feature.

Qubes-Whonix[edit]

If users are willing to persist with one sdwdate-gui systray instance per VM, then it is recommended to enable sdwdate-gui autostart. This setting keeps users informed about the status of the Tor network connection and sdwdate's progress, and will help to test this feature.

To configure sdwdate-gui autostart, run.

Open /usr/lib/sdwdate-gui/start-maybe in an editor with root rights.

If you are using a graphical Whonix or Qubes-Whonix, run.

kdesudo kwrite /usr/lib/sdwdate-gui/start-maybe

If you are using a terminal-only Whonix, run.

sudo nano /usr/lib/sdwdate-gui/start-maybe

Replace its contents with the following code.

#!/bin/bash

## This file is part of Whonix.
## Copyright (C) 2012 - 2014 Patrick Schleizer <adrelanos@riseup.net>
## See the file COPYING for copying conditions.

set -e

if [ -d /usr/lib/qubes ]; then
    VM_TYPE="$(/usr/bin/qubesdb-read /qubes-vm-type)"

    if [ "$VM_TYPE" == "AppVM" ]; then
        /usr/lib/sdwdate-gui/sdwdate-watcher
    elif [ "$VM_TYPE"  == "ProxyVM" ]; then
        sdwdate-gui-qubes
    fi

else
    sdwdate-gui
fi

Save and exit.

Developers are designing the next sdwdate-gui version so it can be conveniently enabled. Check back later for further information concerning sdwdate-gui modifications to prevent auto-start.

Network Time Synchronization[edit]

Disabling NTP[edit]

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, using a watch or atomic clock. 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 users follow the advice at the link above to disable NTP on the host and manually adjust the clock out of band, this might make clearnet traffic more fingerprintable. [6] 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 or similar. However, search engine research suggests that very few people fall into both these categories.

NTP Issues[edit]

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. [7] 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. [8] 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.

Saving or Suspending the VM State[edit]

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 (sys-whonix) state should not be suspended or saved. It is far better to power it off when it is no longer needed. [9]

Similarly, if users suspend or save the Whonix-Workstation (anon-whonix) 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.

For further detailed information on network time syncing on all Whonix platforms, see here.

Spoof the Initial Virtual Hardware Clock Offset[edit]

KVM[edit]

For KVM, click on Expand on the right.

Edit the VM xml before import or edit the VM xml after import and change the following setting.

<clock offset='utc'>
To.

<clock offset='variable' adjustment='123456' basis='utc'>

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[edit]

TODO

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. A related issue is denying Qubes-Whonix access to "clocksource=xen", which may not be possible without Linux kernel and/or Xen patches. For a detailed discussion of these issues, see here.

VirtualBox[edit]

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 prudent 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

Apart from this small biossystemtimeoffset, a clock skew always degrades privacy. [10] [11] [12]

Summary[edit]

All Platforms

  • Always run secure network time synchronization after suspending or saving the VM state and resuming it. Preferably do not use the suspend, save and resume functions at all.
  • For greater security, block networking until sdwdate finishes.
  • Tor cannot connect if the host clock is grossly inaccurate. In this case, users should manually fix the host clock, before powering the Whonix-Gateway (sys-whonix) off and on again.
  • Users should periodically check the host clock to ensure that it is accurate, or approximately so.


Non-Qubes-Whonix


Qubes-Whonix

  • Consider enabling sdwdate-gui autostart to remain informed about the status of the Tor network connection and sdwdate's progress.


It is also recommended to read the TimeSync Technical Design chapter, even though it is a difficult topic. Interested users, developers and auditors should review the footnotes immediately below for additional information, or to explore design elements and the reasoning for this entry.

Deactivate Automatic TimeSync[edit]

To deactivate sdwdate, run.

sudo service sdwdate stop

sudo systemctl mask sdwdate

Footnotes[edit]

  1. https://forums.whonix.org/t/testers-wanted-blocking-networking-until-sdwdate-finished-status-of-sdwdate-gui/5372
  2. https://phabricator.whonix.org/T534
  3. It is installed by default, and is functional when manually started. Users should check back at a later date for further news on sdwdate-GUI development.
  4. https://phabricator.whonix.org/T533
  5. Dev/TimeSync#Block_Networking_until_sdwdate_Finishes
  6. See the Fingerprint page to discover what fingerprinting means in this case.
  7. See Design: Dev/TimeSync.
  8. In this case, Tor cannot verify the Tor consensus.
  9. 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.
  10. biossystemtimeoffset is used to unlink the virtualizer's initial clock synchronization of the VM from the host clock.
  11. After powering on a VM, it initially synchronizes the VM clock with the host clock until Whonix Timesync adjusts it.
  12. Clock skews can lead to linkability, meaning the user would be pseudonymous rather than anonymous.

License[edit]

Whonix Network Time Synchronization wiki page Copyright (C) Amnesia <amnesia at boum dot org>
Whonix Network Time Synchronization wiki page Copyright (C) 2012 - 2018 ENCRYPTED SUPPORT LP <adrelanos@riseup.net>

This program comes with ABSOLUTELY NO WARRANTY; for details see the wiki source code.
This is free software, and you are welcome to redistribute it under certain conditions; see the wiki source code for details.


Random News:

Want to get involved with Whonix? Check out our Contribute page.


https | (forcing) onion

Share: Twitter | Facebook

This is a wiki. Want to improve this page? Help is welcome and volunteer contributions are happily considered! See Conditions for Contributions to Whonix, then Edit! IP addresses are scrubbed, but editing over Tor is recommended. Edits are held for moderation.

Whonix is a licensee of the Open Invention Network. Unless otherwise noted, the content of this page is copyrighted and licensed under the same Libre Software license as Whonix itself. (Why?)