Jump to: navigation, search


< Dev

TimeSync (Whonix) done


Basic Knowledge[edit]


The Post Install Advice is part of this design, therefore read Network Time Syncing first. Also read the Advanced Security Guide chapter Network Time Synchronization as well.

Virtualizers Time Synchronization Features[edit]

VirtualBox Time Synchronization Features[edit]

For understanding Whonix's Time Synchronization Mechanism, it is required to know VirtualBox's time synchronization features:

  • VirtualBox uses the host's time if it needs to correct the time for guests.
  • (Some of VirtualBox's time synchronization features depend on guest additions.)
  • By default VirtualBox corrects Virtual Machine guests' virtual hardware system clock,
    • when they get powered on,
    • when they resume from suspension and
    • when their clock is more than X minutes off.

KVM's Time Synchronization Features[edit]

TODO: document

Qubes Time Synchronization Features[edit]

TODO: document


People have been using:

  • Tor Browser and Mozilla Firefox in parallel
  • Tails inside VMs and Firefox on the host
  • Tor Browser inside Whonix-Workstation and Mozilla Firefox on the host

Other Facts[edit]

  • Almost no one and no operating system is using Secure Network Time Synchronization or External Clocks by default. Most systems synchronize the system clock using unauthenticated NTP. An adversary tampering with NTP replies or malicious NTP server makes things even worse. Even if there was authenticated NTP, there is a requirement for a distributed trust model.
  • A system not using NTP or using authenticated NTP stands out from most other users.
  • clock jumps are bad: wired: The Inside Story of the Extra Second That Crashed the Web


  • Time Sanity Check in context of Whonix: Is an init.d script, which checks if the system clock is between build timestamp and expiration date (17 MAY 2033 10:00:00).


A correct system clock is crucial for many reasons (see footnotes for more):

  • Attack 1: Replay attacks [1]
  • Attack 2: Feeding old/outdated/known vulnerable updates and (https) certificates [2]
  • Attack 3: Deanonymizing [3]
  • Attack 4: Linking all sessions to the same pseudonym [4]
  • Attack 5: Locating hidden services. [5]


Completely Isolated Virtual Time[edit]

Quote https://www.kernel.org/doc/Documentation/virtual/kvm/timekeeping.txt

4.8) Covert channels and leaks

In addition to the above problems, time information will inevitably leak to the guest about the host in anything but a perfect implementation of virtualized time. This may allow the guest to infer the presence of a hypervisor (as in a red-pill type detection), and it may allow information to leak between guest by using CPU utilization itself as a signalling channel. Preventing such problems would require completely isolated virtual time which may not track real time any longer. This may be useful in certain security or QA contexts, but in general isn't recommended for real-world deployment scenarios.

So we want a completely isolated virtual time.

Whonix's Time Synchronization Mechanism[edit]


  • Whonix leaves the host's system clock or time synchronization mechanism untouched.
  • Whonix-Gateway and Whonix-Workstation are based on VirtualBox and therefore have their own virtual hardware system clocks.
  • Most VirtualBox time synchronization features get disabled by Whonix.
    • Guest additions time synchronization gets disabled in by vbox-disable-timesync at run time. See VirtualBox bug report VBoxService --disable-timesync broken. They say it's actually not a bug. It's a missing feature, that running instances of VBoxService can not be modified in their settings. Whonix would need to edit /etc/init.d/vboxadd-service by adding --disable-timesync [6]. Whonix developer Patrick Schleizer does not see a reliable way to do so. If the guest additions get automatically updated in future the option would get overwritten. That's why Whonix added a line in /etc/init.d/sdwdate to turn it off completely. Guest additions time synchronization gets disabled, but the rest of the guest additions continue to work fine. Unless you have a better idea, it's an acceptable workaround. Maybe when Whonix is based on Debian jessie / systemd, it will be easier to add the --disable-timesync to daemon options using a systemd override.
    • built in time synchronization features get disabled by VBoxManage setextradata "$VMNAME" "VBoxInternal/Devices/VMMDev/0/Config/GetHostTimeDisabled" "1" at build time.
  • VM Settings, Hardware Clock: set to UTC.
  • When get powered on, they still get their time from the host. The user is advised to modify the biossystemtimeoffset in Advanced Security Guide, chapter Network Time Synchronization. [7]
  • Time Sanity Check before sdwdate will be executed, this ensures, that the host clock is sane and not slow in 1980. User gets advised to fix its host clock in such cases.
  • After they are connected to the Tor network, they use sdwdate (inspired by tails_htp) to set the system clock. [8]
  • Time Sanity Check after sdwdate was executed. This should catch eventual bigger bugs and attacks. User gets informed if it fails.
  • Using Boot Clock Randomization, i.e. after boot, the clock is set randomly between 5 and 180 seconds into the past or future. This is useful to enforce the design goal, that the host clock and Whonix-Workstation clock should always slightly differ. It's also useful to obfuscate the clock when sdwdate itself is running, because naturally at this time, sdwdate hasn't finished.
  • sdwdate runs after booting.
  • Whonix-Gateway: Using sdwdate is better against Attack (1) when using a bridge.
  • Every hour, at a random time, sdwdate will set the clock again. This is useful for machines running for long time periods without reboot.
  • sdwdate runs at non-predictable times to prevent the ISP or Tor guard/bridge node to guess, that the user is running Whonix.
  • sdwdate adds or subtracts a random amount of seconds in range of 0.000000001 and 0.999999999. [9] This is supposed to prevent time servers tracking individual users.
  • Implementation details are in Design-Shared, chapter TimeSync
  • That will reach the design goal, that all clocks, the host's, Whonix-Gateway's and Whonix-Workstation's slightly differ.

boot clock randomization[edit]



Open /var/log/bootclockrandomization.log in an editor.

If you are using a graphical environment, run:

kwrite /var/log/bootclockrandomization.log

If you are using a terminal (Konsole), run:

nano /var/log/bootclockrandomization.log


How Secure is it?[edit]

No longer using TLS. Now using Tor hidden services. TODO: expand

Time Fetching Methods[edit]


Only "Remote Web Servers Method" is implemented at the moment. "Tor Consensus Method" is only an idea.

Remote Web Servers Method[edit]

Authentication of Servers[edit]

sdwdate only connects to Tor hidden services, which are encrypted by default and do not rely on SSL CA's. (See also Hidden_Services#Notes_about_End-to-end_security_of_Hidden_Services.) It also uses several different pools of time sources, and if there are too many that fail for any given pool, e.g. because of failed certificate checking or being unreachable, the pool is considered to be potentially compromised and sdwdate aborts.

sdwdate source pools[edit]

What sources should be trusted? This is of course also a problem with NTP.

The sdwdate pools used by Whonix are based on stable and reliable Tor hidden service web servers. They are categorized into three different pools according to their members' relationship to the members in the other pools; any member in a one pool should be unlikely to share logs (or other identifying data), or to agree to send fake time information, with a member from the other pools.

The pools are listed in /etc/sdwdate.d/30_sdwdate_default.

Basically, sdwdate picks three random servers - one from each pool, and then builds the mediate of the three advertised dates.

sdwdate is only using 'pal' pools. Not using 'neutral' and 'foe' pools as tails_htp, because no good reasoning for that has been provided. [10]

Tor Consensus Method[edit]


Just an idea. Not yet implemented.

Tails' tordate (Guessing time based on Tor consensus), renamed to anondate for trademark reasons and refactored to work outside of Tails provides useful bash functions to check system clock using Tor's consensus file and Tor's log.


Tor connects to the network. The Tor consensus file contains rough time information. Since when and until when it is valid.

tordate (now anondate) can provide us with a few machine readable infos we can then use for whatever we may need them.

This is magic.

valid-after=2014-07-31 21:00:00
valid-until=2014-08-01 00:00:00

This is simply /bin/date.

Current time is 2014-07-31 22:44:02

Less magic.

Current time is in valid Tor range

Less magic, but maybe useful.

Current time is not in valid Tor range, setting to middle of this range: [2014-07-31 22:30:00]

anondate can do this by parsing Tor's verified consensus file /var/lib/cached-microdesc-consensus or by parsing /var/lib/tor/unverified-microdesc-consensus.

Open Questions[edit]
Under which conditions Tor is not able to verify the Tor consensus file?[edit]

1) If it has been tampered with by a man-in-the-middle.

2) For clocks that are more than 30 days in the past or 2 days in the future, Tor will not even be able to download a consensus. In this case anondate can parse Tor's log and report the authority's cert's valid-after date. [11]

anondate --tor-cert-valid-after
Jun 16 00:00:00 2014 GMT

Is the authority's cert's valid-after date signed/verified/built-into-Tor or can it be tampered with by a man-in-the-middle attack?

3) Anything else?

Other Questions[edit]
  • When can anondate set time from verified and when only from unverified consensus file?
  • How reliable is it to do something as non-standard, unintended, inventive such as parsing Tor's consensus and Tor's log?
  • When clock is more than 1 hour in past or more than 3 hour in future, Tor will be unable to establish circuits? [12]
  • How accurate has the clock to be so hidden services can be accessed? See: https://trac.torproject.org/projects/tor/ticket/3460
Reasons for relying solely on anondate for time setting[edit]
Reasons against relying solely on anondate for time setting[edit]
  • Provides only rough time.
    • web fingerprint would differ from most other Tor users.
    • Would cause lots of support requests complaining about skewed clocks.
    • Might trouble hidden services (such as hidden web servers) that need to show time to clients?
    • Might trouble people attempting to tunnel I2P through Tor?
    • Might cause other (gpg) verification issues?
  • Fingerprinting issues at ISP level:
  • Hidden services can only be accessed if the clock is no more than 30 minutes slow or fast. [13]
  • Tails ticket: Robust time syncing Quote:
    Currently we use tordate to set the initial clock. It's very messy and error prone, so we desperately need a robust replacement.
  • Vulnerable to ISP level man-in-the-middle attacks:
    • Tails Design: Time Syncing Quote:
      First, replaying a consensus older than one week or so results in preventing access to the Tor network, and that's all, because onion keys will be wrong.
      • In a situation where an adversary is replaying a more than ~7 days old consensus:
        • anondate could report a clock that is more than ~7 days slow. With a system clock that is that slow, Tor would no longer be able to establish circuits. But there are multiple reasons why Tor may not be able to establish circuits. So anondate could only guess, that the clock reported in Tor consensus is more than ~7 days slow, but not know with certainty.
      • In a situation where an adversary is replaying an up to ~7 days old consensus:
        • anondate could report a clock that is up to ~7 days slow and Tor would still be able to create circuits.
        • With Tor as is at the moment, anondate cannot even in principle provide a more accurate time guess than a clock that is up to ~7 days slow.
        • Using an up to ~7 days old consensus, is most likely something we really should avoid?
    • In comparison to Remote Web Servers Method, an adversary does not even need to break SSL CA's, but can do an even simpler attack by replaying an old Tor consensus.
    • Therefore vulnerable to Attack 3 as per #Attacks.
  • Relying solely on anondate for time setting is probably a bad idea.
  • Using anondate as a sanity test and for debugging (useful user output) may be useful: sdwdate-plugin-anondate
  • Rough time fix.
    • Only for users that do not care about being temporarily fingerprinted! This needs proper documentation.
    • If clock is too much off so sdwdate cannot fix it, use anondate to get a rough time fix, then let sdwdate do the rest.
Why not use tordate by Tails instead of reinventing the wheel with anondate?[edit]
  • Because Tails code is highly Tails specific.
    • Depending on non-persistent Tor data dir.
    • Entangled with Tails specific gui notifications.
    • Entangled into the Tails specific boot process with other scripts.
    • Not a clean abstraction of "tell me what Tor's log / Tor's consensus thinks about date/time".
    • Quote: "Currently we use tordate to set the initial clock. It's very messy and error prone, so we desperately need a robust replacement." [14]
  • Patrick wouldn't want opening up to the fingerprinting risks without the user being aware of it.
  • Patrick wouldn't know how to just re-use it on Whonix without cleaning it up.
  • After all, Patrick is very happy about all their grep / date / sed magic, and re-using that code without modification. anondate is just cleaning up API / abstraction layer / boot process.
Random Stuff[edit]
  • tails-dev mailing list: tordate: why is it safe to set time from unverified-consensus?
    • Patrick would argue, that string parsing a unverified consensus using anondate is more risky [hitting hypothetical vulnerabilities in grep] than string parsing a verified Tor consensus.
  • Tor consensus is in some cases downloaded from Tor directory authorities and in some cases from Tor directory mirrors. The latter should not be trusted as much as the former.
  • We ought to not download the Tor consensus exclusively from Tor directory authorities. Source: [15]
    <armadev> oh. i think that would be horrible. hundreds of thousands of users doing that could overwhelm the directory authorities.
Status of this idea[edit]
  • Needs more research.
  • Let's implement sdwdate Tor Consensus Time Sanity Check first.
  • A simple command line tool that can parse Tor's consensus and Tor's log as been implemented: #anondate
  • Perhaps relying solely on anondate for time setting could be implemented as an alternative Time Fetching Method into sdwdate and be available as an option (disabled by default in Whonix).

Trusted Time Sources[edit]

Hidden Services is the preferred method to thwart SSL MITM: Proposal [16]. These are reliable and trustworthy sites. The sources are listed here to keep track of pool candidates:


gui actions[edit]

  • (1) Whonix startup -> sdwdate starts -> sdwdate in startup mode -> X starts -> when sdwdate in progress -> sdwdate-plugin-timesync shows progress bar
  • (2) Whonix startup -> sdwdate starts -> sdwdate in startup mode -> X starts -> when sdwdate failed -> sdwdate-plugin-timesync shows active error popup
  • (3) Whonix startup -> sdwdate starts -> sdwdate in startup mode -> X starts -> when sdwdate crashed -> sdwdate-plugin-timesync shows active error popup
  • (4) Whonix startup -> sdwdate starts -> sdwdate in startup mode -> X starts -> when sdwdate succeeded -> sdwdate-plugin-timesync shows passive success popup

  • (5) Whonix after startup -> sdwdate in daemon mode -> when sdwdate in progress -> sdwdate-plugin-timesync do nothing
  • (6) Whonix after startup -> sdwdate in daemon mode -> when sdwdate failed -> sdwdate-plugin-timesync shows active error popup
  • (7) Whonix after startup -> sdwdate in daemon mode -> when sdwdate crashed -> sdwdate-plugin-timesync shows active error popup
  • (8) Whonix after startup -> sdwdate in daemon mode -> when sdwdate succeeded -> sdwdate-plugin-timesync do nothing

  • (9) Whonix after startup -> sdwdate in daemon mode -> when user runs "sudo service sdwdate restart" or apt-get upgrades sdwdate ->

  • (10) Whonix after startup -> user runs timesync -> timesync works like a monitor -> timesync restarts sdwdate -> sdwdate in startup mode -> timesync shows progress bar and monitors sdwdate -> show active popup (with result, either: crash / failed / succeeded)


When the user powers on Whonix-Gateway and the host time is too much off, it will not be able to connect to the Tor network. It is advised, when powering on Whonix-Gateway, to check that the host time is no more than 1 hour in past or more than 3 hour in future, otherwise Tor will be unable to establish circuits.[17]

An adversary tampering with the user's clock, while the user doesn't recognize that, can't do any more damage to Whonix than he could do to the Tor Browser Bundle. Worst case is a denial of service for Tor. On the other hand, an adversary capable of actively tampering with the traffic between the user and its entry guard or bridge poses much bigger risks to Tor in general. [18]

The reason for running TimeSync on Whonix-Gateway, is that hidden services can only be accessed if the clock is no more than 30 minutes slow or fast.[19] Running TimeSync ensures, that Whonix-Gateway's clock is reasonably accurate.

Adjusting time slowly using adjtimex/ntp_adjtime[edit]

Under consideration is changing the time with sclockadj2. The initial drive for this was that calling clock_settime() in the original sclockadj can result in several thousand entries in systemd's journal per invocation (can be seen with journalctrl -f) on Debian jessie.

sclockadj2 uses adjtimex call in libc (als called ntp_adjtime) which translates to Linux' kernel system call 124. This is a modal interface that is used by `ntpd` to change the system clock. adjtimex supports a mode with "hard" changes to the time, but those generate entries in systemd journal, just like with clock_settime.

The offset mode for adjtimex allows a change of 0.5 seconds per call (used to be ~130 milisec until the 2.6 kernel). The documentation of this call is incomplete, partly resulting from the limited number of clients (ntpd, chronyd) using this interface, but by tracing the kernel internals (linux/kernel/time/ntp.c and /linux/kernel/time/timekeeping.c) one can get a more complete picture, including that modern kernels support a NANO mode easier implementation of smaller adjustments than the older μsecond based interface, without the need to do clock tick adjustment calculations.

Based on this interface and mode bit definitions taken from /usr/include/linux/timex.h (more complete than the counterparts you typically find online) to form a Python based interface via ctypes. Primarily first setting the kernel internals to handle nanoseconds specifications and run in PLL mode. Then using OFFSET to adjust the time. With this call the kernel is instructed to change the time gradually. You can observe this change by making further calls to adjtimex, this time without setting any values (specified by 0 in the modes bitfield of the structure handed to adjtimex). To handle changes of more than the maximum allowed (±0.5 seconds), you need to invoke a 0.5 second change and observe if the offset has been reduced to 0, then invoke again. Writing a new offset using adjtimex will overwrite any running adjustment process, therefore you have to wait.

By default the kernel uses a decreasing stepsize as the (remaining) offset to handle approaches 0. This can be influenced by the TIMECONST to start with bigger steps, or even reset the stepsize on a regular basis while the kernel is changing the clock according to the remaining offset.

The ntpd can use this offset changing possibility as is but also has a more sofisticated approach, by instructing the kernel about the drift compared to the internal clock.

The sclockadj2 directly uses a nanosecond offset (positive or negative) that instructs the kernel to adjust (looping muliple invocations if the absolute value of the offset > 0.5 seconds. The program has to be run as root in order to tell the kernel to make these changes (querying the status doesn't require this). At the start of this process a PID file is written, which is checked during loops (if running longer than 0.5 s) and will kill any previous invocation of the program. The syntax for the offset invocation is:

     sclockadj2 offset [-h] [--constant CONSTANT] [--verbose] [--quiet][--wait]  nanoseconds

for changes > 0.5s --wait has to be specified. Increased verbosity can be used to watch the progress of what the kernel is doing with the offset.

This progress can also be seen by invoking the program with the status option. To do so has some instructional value for observing normal `ntpd` behaviour as well. The full options for status:

   usage: sclockadj2 status [-h] [--follow] [--set] [--verbose] [--quiet]
                            [--debug] [--wait]
   adjtimex status (--quiet -> only offset, --verbose -> detail)
   optional arguments:
     -h, --help     show this help message and exit
     --follow, -f   follow status indefinately
     --set          set status explicitly to PLL and NANO
     --verbose, -v  increase verbosity level
     --quiet, -q    decrease verbosity level
     --debug, -D    Debug messages. Don't change date
     --wait         wait for offset to return to 0

Stopping a previous invocation of sclockadj2 (which might be looping on values > 0.5s), including stopping the internal offset can easily be achieved by calling sclockadj2 offset 0

External Clock[edit]

This topic is still under research. Help is welcome.

It might make sense to add an external clock, such as a GPS, or even better an atomic clock. (Can we get an atomic USB clock?) This clock should be added to the host and/or Whonix-Gateway and/or Whonix-Workstation?

Open question: would the GPS/atomic clock be too accurate and would that make Whonix more fingerprintable?

Discarded Options[edit]





  • uses seccomp
  • written by Jacob Appelbaum (security researcher; The Tor Project staff member) Due to the recent news now probably abandoned.


  • Only native SSL CA pinning support. No direct SSL certificate pinning support.
  • Does not distribute trust. [26] [27] [28] The single time source can send by error or by malicious intent send wrong time replies.
  • Does not support hooks for user notifications about state of network time synchronization. -> Users shouldn't use the internet in Whonix-Workstation before network time synchronization finished, and timesync is informing users about this. -> Implementing notifications would be difficult or require patching tlsdate.
  • Produces clock jumps, which confuses various applications. Does not gradually adjust as sdwdate does with Slow Clock Adjuster. [29]
  • Cannot connect to (most) Tor hidden services, because most of those do not support SSL. [30] [31]
  • Minor: command line parser doesn't fail closed on extraneous / unknown command line parameters [32] - not that important in the absence of bugs, butsafer behavior for tlsdate would be to fail closed on on extraneous / unknown command line parameters.
  • Likely denial of service issue: https://github.com/ioerror/tlsdate/issues/149



Tails htpdate fork


Consideration no TimeSync on Host[edit]

Would it be advisable to run no network time synching daemon on the host at all? There are open questions. See:

Time Source of Time Servers[edit]

Even if we could very securely obtain the time from a server with distributed trust and everything, the question is, how do these servers themselves set their own clock? If they just use unauthenticated NTP themselves, they might not be a big help.

Local Clock Leaks[edit]

  • TCP Sequence Numbers -> open issue [34]
  • ICMP timestamps -> blocked by Whonix's firewall for Whonix VMs. Host: Recommendation to disable on the host.
  • TCP timestamps -> blocked in Whonix VMs by tcp-timestamps-disable.; Recommendation to disable on the host.
  • NTP [22] [23] -> Not installed by default in Whonix. Host: TODO
  • Automatic updaters and other network using cron jobs that run at non-random, canned [35] times.
  • Javascript. [36] [37]
  • E-mail clients such as Mozilla Thunderbird / Icedove and others. [38] [39] [40]
  • https / ssl, older [41] versions of openssl, TLS HELLO gmt_unix_time [42] What about other implementations of SSL / TLS, other than openssl?
  • older [41] versions of Tor (NETINFO) [43]
  • web servers (time stamps from http headers (RFC 2616)) [44]


high priority[edit]

normal priority[edit]



Successful boot and network time synchronization.

  • Two independent processes: sdwdate-daemon and sdwdate-tray.
  • A one way messaging mechanism sdwdate-daemon -> sdwdate-tray. [sdwdate-tray implements a file watcher watching the changes in a file "/run/sdwdate/status" or so, updated by sdwdate-daemon.]

Boot cycle:

  • system starts
  • all network blocked, besides for Tor and sdwdate-python - implemented by whonix-gw-firewall / whonix-ws-firewall, which will keep care to create a file /var/run/sdwdate-firewall/limited (with content 'whonix-gw-firewall')
  • sdwdate-daemon starts
  • sdwdate-daemon writes its successive statuses to a /tmp file, clearing the previous status. The history is kept in the log.
  • sdwdate-tray starts after X is running. Checks boot clock randomization, checks sdwdate (1), reads the last sdwdate-daemon status file, removes the file.
  • sdwdate-tray sets its icon, updates its on-hover text and a pops a notification according to the last sdwdate-daemon status.
    • sdwdate-daemon status success (2): releases the network, pops a success notification.
    • sdwdate-daemon status warning/error: pops a warning, waits until sdwdate-daemon success (polling).

(2) In most of the cases, time synchronization should be completed before sdwdate-tray is ready (kdm started, X running).

Normal cycle:

  • sdwdate-tray polls sdwdate-daemon status file. Any warning/error is reported by [icon change - on-hover text - pop up notification no popup]

[progress-done-success] mechanism:

  • The asynchronous times fetching in sdwdate-daemon should render the progress feature obsolete. Yet a safety could be implemented in sdwdate-daemon for the case url_to_unixtime fails.
  • [done-success] could be handled in the messaging mechanism (not that many possible combinations).


  • /var/run/sdwdate-firewall is supposed to be a generic name. Optional feature. Only used by Whonix. In Whonix, implemented by whonix-(gw|ws)-firewall.
  • always rely on files, i.e. only show "Network limited [by whonix-gw-firewall]." when /var/run/sdwdate-firewall/limited exists (or when the status file says "Network limited [by whonix-gw-firewall].")
  • everything is asynchronous, events could happen in a different order

sdwdate-tray right click menu:

  • open sdwdate's log
  • restart sdwdate
  • restart fresh ?

sdwdate-tray left click action:

  • show a popup with the latest hovering over text?
  • passive or active popup?
  • a popup is useful for those, who don't know the hovering over mechanism
  • or full sized gui?

Development discussion:


Consensus Related Options[edit]
  • --verified-only
  • --prefer-verified
  • --unverified-only
Special Exit Codes[edit]
  • exit 3: $TOR_LOG not readable.
  • exit 4: $consensus not readable.
Simple Status Checking[edit]
/usr/lib/anon-shared-helper-scripts/anondate --has-consensus[edit]

Useful for checking if asking for any #Date Ranges Output is worthwhile.

  • yes:
    • exit 0
  • no:
    • exit 1

Can be replaced by Tor ControlPort / python-stem?

  • verified-only: Yes. (consensus/valid-after)
  • unverified: No.
/usr/lib/anon-shared-helper-scripts/anondate --current-time-in-valid-range[edit]

Useful for a sanity test before setting the time for the first time and before setting the time to a newly fetched timestamp.

  • yes:
    • exit 0
  • no:
    • exit 1

Can be replaced by Tor ControlPort / python-stem?

Date Ranges Output[edit]
/usr/lib/anon-shared-helper-scripts/anondate --show-valid-after[edit]
  • yes:
    • output: 2015-08-15 22:00:00
    • exit 0
  • no:
    • exit 1

Can be replaced by Tor ControlPort / python-stem?

/usr/lib/anon-shared-helper-scripts/anondate --show-valid-until[edit]
  • yes:
    • output: 2015-08-16 01:00:00
    • exit 0
  • no:
    • exit 1

Can be replaced by Tor ControlPort / python-stem?

/usr/lib/anon-shared-helper-scripts/anondate --show-middle-range[edit]
  • yes:
    • output: 2015-08-15 23:30:00
    • exit 0
  • no:
    • exit 1

(A scripted calculation of the above.)

Certificate Validity[edit]
/usr/lib/anon-shared-helper-scripts/anondate --tor-cert-lifetime-invalid[edit]

When this exits 0, this is actually a bad sign. Example Tor log:

Sep 03 10:32:59.000 [warn] Certificate already expired. Either their clock is set wrong, or your clock is wrong.
Sep 03 10:32:59.000 [warn] (certificate lifetime runs from Aug 16 00:00:00 2014 GMT through Jul 29 23:59:59 2015 GMT. Your time is Sep 03 10:32:59 2015 UTC.)

When clock is several months or years fast or slow, Tor cannot even download Tor consensus. (In this case, Tails is probably setting time from unverified(?) consensus and restarts Tor. We probably won't do this. Not sure that date is any useful. But the info, that clock is way off, is useful.)

  • yes:
    • output: Sep 03 10:34:00.000 [warn] Certificate already expired. Either their clock is set wrong, or your clock is wrong.
    • exit 0
  • no:
    • exit 1

Can be replaced by Tor ControlPort / python-stem? No. Tor Project Upstream Feature Request: make certificate lifetime accessible through Tor's ControlPort

/usr/lib/anon-shared-helper-scripts/anondate --tor-cert-valid-after[edit]

Similar to above, but less output.

  • output: Jun 16 00:00:00 2014 GMT
  • Exit codes unreliable.
  • Don't use without using the above first.
  • (Could be fixed in the code if worthwhile.)


Useful to run in Qubes dom0.

qvm-run --pass-io sys-whonix "date -u" ; date -u

See Also[edit]


Previous Discussion[edit]

Other Projects[edit]

Comparison with Others[edit]

Network Time related


Clock Correlation Attack[edit]


prerequisite knowledge:

  • Whonix-Gateway [Proxy]VMs and Whonix-Workstation [App]VM's system time cannot not be obtained by watching traffic at ISP level.
  • This chapter is not about tracking a single VM across its different Tor exit relays.
  • The context is anonymity. The significance is deanonymization.
  • In anonymity we don't just care about about correlations. Also about estimations. Anonymity set reduction. Partitioning users is already a success. Because it may be combined with other guesses. No direct proof is required. From some countries, there are just a few 100 users or less. If there is already a lead by country, then combined with these time related issues, things begin to really matter.
  • clocksource 'xen' / 'kvmclock' doesn't prevent Whonix from using sdwdate.
  • clocksource 'xen' / 'kvmclock' doesn't prevent each VM having slightly different system time (used by all the applications), so no direct leaks here.
  • [host | dom0] host time and VM times a very, very similar. At most one second difference. Or less. In [host | dom0], see:
date ; qvm-run --pass-io sys-net date


  • 1) requires a) compromise a Whonix-Workstation VM and b) observing the ISP network the user is using
  • 2) read [host | dom0] time using clocksource 'xen' / 'kvmclock' or possibly the wall clock interface
  • 3) [host | dom0] time will be very similar to NetVM's time (the system where external network connections are made)
  • 4) correlate Whonix-Workstation VM with NetVM's time
  • 5) anonymity set reduction done


No need to compromise multiple VMs. Only one VM, a Whonix-Workstation VM needs to be compromised. NetVM does not have to be compromised, it leaks in most cases - hard to avoid all cases - any passive ISP level adversary watching traffic can read the clients local clock. It's leaked on many levels, see #Local Clock Leaks.

Threat Model:

  • Whonix-Workstation AppVM gets compromised up to local root code execution. Then the attacker uses the local exploit, reads clocksource 'xen' / 'kvmclock'.


We need to make sure that all of Whonix-Gateway, Whonix-Workstation, and NetVM uses slightly different time. Even if Whonix-Workstation would be compromised, and the attacker gets knowledge of the time of [host | dom0] and sniffs NetVM's time, it would hinder correlation.

[host | dom0] and non-anonymous VM's clocks should be as synced, correct and secure as those can be.

But those should differ from the clocks within Whonix VMs.

We need completely isolated virtual time within Whonix VMs. [45] [46]


> The other interface ("wallclock interface") would provide such time, though. And it isn't configurable. But not sure if it is used anywhere in Linux by default (probably besides initial system time set).

Yes. Must be so. Otherwise with "ticks" alone the VM had no chance to figure out the current time. And this is a roblem, because we don't want the VM to know [host | dom0]'s time.

We might be able to solve the wallclock [not pvclock] issue by Spoofing the Initial Virtual Hardware Clock Offset.


Rather than modifying [host | dom0]'s clock, we could perhaps spoof the initial virtual hardware clock offset. It's possible for KVM, as per: https://libvirt.org/formatdomain.html#elementsTime

Something like this:

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

Reading clocksource xen as a [root] user is not easily possible. source: http://lists.xen.org/archives/html/xen-users/2015-08/msg00020.html

Would probably require writing a kernel module.



Needs more research.

Why we should avoid leaking TSC from the host go the VM.

I think leaking anything related to time from the host into the VM [or from VM to VM] risks cryptographic side channel attacks and should therefore be avoided.

Search term:
time stamp counter tsc side channel

Leads to:

TSC leaks may be similar to to TCP sequence numbers. [47]

clocksource xen[edit]




Hardware clock: Set to UTC. OpenSSL (used by Tor) leaks it [48]; [43], but that is of no concern. Tor is running on Linux and Linux is expected to be run in UTC. Therefore there is no point to set it to the local time zone of the user.

    • An adversary could guess if someone is running a hidden service with constant clock adjustments, that it's hosted inside a Whonix-Workstation. It's unknown if the clock adjustments by sdwdate are big enough to enable an adversary to guess that.
      • TODO: Open question... "ntpd adjusts the clock in small steps so that the timescale is effectively continuous and without discontinuities" - is that possible with a sdwdate like approach as well? -> Working on sclockadj.
    • Running sdwdate also every [ 1440 minutes + random(0-1440) ]. Not running this every hour at a random time, because Tor does not like clock jumps. [deprecated because sclockadj] When testing this, there were cases where the clock jumped about 800 seconds, which caused Tor to expire circuits, which caused connection interrupts.
    • TODO: Open question... How often should sdwdate run on Whonix-Gateway? Every hour is a bad idea, as we see above. Not running it again when some people may run Whonix-Gateway for days or weeks is not good either, since the clock can drift. Maybe it should run wait 24 hours and then wait a random amount of minutes within 24 hours? -> Will be solved when sclockadj gets finished.
      • The entry guard or bridge can see the time through TCP timestamp. [48]; [43]
      • Continuous clock jumps could help the entry guard or bridge guessing, that a Whonix-Gateway is connected.
      • TODO: Open question... "ntpd adjusts the clock in small steps so that the timescale is effectively continuous and without discontinuities" - is that possible with a sdwdate like approach as well? -> Will be solved when sclockadj gets finished.
  • sdwdate is designed to be as secure as TLS (RFC 2246) but of course the security of TLS is often reduced to whichever CA racket you believe is trustworthy. By default, sdwdate uses curl that by default trusts your local CA root store - so when any of these companies assist in a MITM attack, malicious time information could be feed into your system.


  1. Replay old Tor consensus, see Tails: Time syncing for detailed explanation.
  2. Cryptographic verification depends on system clock, i.e. a clock two years in past will accept certificates/updates, which have been expired/revoked for two years.
  3. #Local Clock Leaks are an issue. Imagine the user connects to an adversary controlled web-server with Mozilla Firefox / Iceweasel and connects to another web-server controlled by the same adversary with Thunderbird / Icedove. The adversary can link the anonymous and non-anonymous session, thus deanonymizing.
  4. If the clock is too much off, it's also easy for an adversary's web-server to detect "Oh, that's the Tor Browser user who's clock is X in past/future.", thus allowing the adversary to link all sessions to the same pseudonym. See Tor Browser upstream bug #3059: Find some way to deal with time-based fingerprints.
  5. For hidden services a correct clock is crucial, see:
  6. source
  7. Developer information: If we needed or wanted to render the hardware clock unusable, we could set VirtualBox --biossystemtimeoffset several decades in past or future.
  8. Stream isolation has been added, for Whonix's sdwdate implementation i.e. people using Tor Browser prevent notifying their exit relay, that they are sdwdate or Whonix users.
  9. Check.
    grep -i "Made up" /var/log/sdwdate.log
  10. https://github.com/Whonix/Whonix/issues/310
  11. Source, source code comment in tordate: https://git-tails.immerda.ch/tails/plain/config/chroot_local-includes/etc/NetworkManager/dispatcher.d/20-time.sh
    	# Since Tor 0.2.3.x Tor doesn't download a consensus for
    	# clocks that are more than 30 days in the past or 2 days in
    	# the future.  For such clock skews we set the time to the
    	# authority's cert's valid-after date.
  12. https://lists.torproject.org/pipermail/tor-talk/2012-February/023264.html
  13. https://trac.torproject.org/projects/tor/ticket/3582#comment:3
  14. https://labs.riseup.net/code/issues/5774
  15. https://www.whonix.org/old-forum/index.php/topic,514.msg4001.html#msg4001
  16. https://phabricator.whonix.org/T131
  17. https://lists.torproject.org/pipermail/tor-talk/2012-February/023264.html
  18. General Tor problems, Tor is known to be broken against many active attacks. This can not be solved by Whonix. When an adversary is capable of running active attacks, tampering with the time leading into a denial of service is the least of the worries. The adversary could also disrupt the service easier. And as for active attacking in general, there are other attacks which are easier to deploy and which pose a greater danger. Not a Whonix specific problem.
  19. https://trac.torproject.org/projects/tor/ticket/3582#comment:3
  20. http://lists.ntp.org/pipermail/questions/2010-November/028033.html
  21. https://labs.riseup.net/code/issues/6113
  22. 22.0 22.1 Source: RFC5905

    Origin Timestamp (org): Time at the client when the request departed for the server, in NTP timestamp format.

  23. 23.0 23.1 Credits: Thanks to dfc for the answer on security.se.
  24. http://www.webcitation.org/6ST27IXN6
  25. 60 s * 60 m * 24 h
  26. As sdwdate does.
  27. https://github.com/ioerror/tlsdate/issues/112
  28. https://github.com/ioerror/tlsdate/issues/143#issuecomment-57053323
  29. sclockadj
  30. Because in most cases, there is little need to combine Tor hidden services with SSL. connections to Tor hidden services are Tor-to-Tor encrypted by default ("not exactly end-to-end").
  31. https://github.com/ioerror/tlsdate/issues/157
  32. https://github.com/ioerror/tlsdate/issues/158
  33. https://tails.boum.org/contribute/design/Time_syncing/#index4h1
  34. By distribution defaults.
  35. Was fixed in Tor Browser, but remains open for other applications such as browsers like Mozilla Firefox / Iceweasel.
  36. See http://ip-check.info for demonstration.
  37. prevent leak via Date header field (local timestamp disclosure)
  38. prevent leak via Message-ID header field (local timestamp disclosure)
  39. Quote, on October 24th, 2014 sukhbir said:
    "The timestamp disclosures are via the date and the message-ID headers (relevant tickets: #6314, #6315). We have submitted patches to Mozilla (902573, 902580) that have not yet been merged. The patches probably need more work and we are looking for volunteers to work on them and help us to get them merged. We will be doing a blog post about this soon and put out a call for help."
  40. 41.0 41.1 For example the one shipped by Debian wheezy.
  41. https://trac.torproject.org/projects/tor/ticket/8751
  42. 43.0 43.1 43.2 See torproject.org #4852: Clients send NETINFO with time. The ticket says fixed. However, Debian wheezy (currently: oldstable) (which Whonix 10 was based on) is using Tor 0.2.3 but Nick's patch appeared first in 0.2.4. It was solved in Whonix 11, because it is based on Debian jessie, that contains a more recent version of Tor.
  43. For demonstration, you could use.
    curl -silent --head torproject.org | grep -i date:
  44. http://security.stackexchange.com/questions/106406/how-to-get-a-completely-isolated-virtual-time-using-xen
  45. http://lists.xen.org/archives/html/xen-users/2015-11/msg00114.html
  46. https://trac.torproject.org/projects/tor/ticket/16659#comment:10
  47. 48.0 48.1 Cite error: Invalid <ref> tag; no text was provided for refs named tlsleakone


Whonix TimeSync wiki page Copyright (C) Amnesia <amnesia at boum dot org>
Whonix TimeSync wiki page Copyright (C) 2012 - 2015 Patrick Schleizer <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:

We are looking for video makers.

Impressum | Datenschutz | Haftungsausschluss

https | (forcing) onion
Share: Twitter | Facebook | Google+
This is a wiki. Want to improve this page? Help welcome, 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 (g+) is a licensee of the Open Invention Network. Unless otherwise noted above, content of this page is copyrighted and licensed under the same Free (as in speech) license as Whonix itself.