sdwdate: Secure Distributed Web Date

sdwdate-gui Control Panel

Introduction

Time keeping is crucial for security, privacy, and anonymity. sdwdate is a Tor-friendly replacement for rdate ^[archive] and ntpdate ^[archive] that sets the system's clock by communicating via end-to-end encrypted TCP with Tor onion webservers. Chosen time providers are exclusively reputable sources (whistle-blowing and privacy-friendly onion sites) that are highly likely to be hosted on different hardware.

At random intervals, sdwdate connects to a variety of webservers and extracts the time stamps from http headers (see: RFC 2616 ^[archive]).

sdwdate vs ntp

Table: sdwdate vs ntp Comparison

	sdwdate [archive]	ntp
Written in memory-safe language	Yes	No
Distributed trust	Yes	No
Secure connection by default (authentication and encryption)	Yes	No
Gradual clock adjustments	Yes	Yes
Daemon	Yes	Yes
Functional over Tor [archive]	Yes	No
Tor not required	No	Yes
Client, time fetcher	Yes	Yes
Server, time provider	No, not yet	Yes
Apparmor profile	Yes	Yes
Drop-in config folder	Yes	No
Proxy support	Yes	No
Possible to secure by default on GNU/Linux distribution level	Yes	No
Secure	Yes	No
Optional GUI	Yes, sdwdate-gui (a systray icon)	No

See also:

• Installation on headless systems; see footnote.
• Time Attacks
• Dev/TimeSync
• sdwdate-gui

TODO:

• Server, time provider
• sdwdate issue tracker: https://phabricator.whonix.org/project/view/6/ ^[archive]

sdwdate Design

Server Authentication

sdwdate ^[archive] only connects to Tor onion services, which are encrypted by default and do not rely on SSL certificate authorities (CAs). Three different pools are used for time sources so that if too many connections fail for any given pool, the pool is considered as potentially compromised and sdwdate aborts.

sdwdate Source Pools

Determining what sources should be trusted is an important issue; this is also a problem with NTP.

The sdwdate pools used by Whonix ™ are based on stable and reliable Tor onion service web servers. The pools are listed in /etc/sdwdate.d/30_default.conf ^[archive].

The various onion services are categorized into three different pools. Any member in one pool should be unlikely to share logs (or other identifying data), or agree to send fake time information, with a member from the other pools. In basic terms, sdwdate picks three random servers - one from each pool - and then builds the mediate (middle position) of the three advertised dates.

sdwdate is only using 'pal' pools and not relying on 'neutral' and 'foe' pools as per tails_htp, because a good rationale for that approach has not yet been provided.

sdwdate Time Sources Criteria

Current Implementation 1.0

Prerequisite knowledge: sdwdate time source pool design

These criteria are meant to be fitting the dynamic trust of the internet and to be as close as possible to the highest trustable level.

Time Source Inclusion Criteria

• trustworthy. This criteria probably means many different things for many different people. To clarify, it needs to be compatible with the Whonix ™ Platform Goals. Trustworthy as far as infrastructure goes, for example as in unlikely to be using cloud and/or insecure hosting for receiving confidential documents.
• hosted by non-anonymous organizations or persons.
• reachable over an .onion domain.
  • If there is a forced redirection from (non-TLS) http onion to TLS https onion, the TLS certificate must be valid.
• highly likely to be hosted on different hardware than other sdwdate time source pool members.

Details:

It is required that each sdwdate time source pool member has both, a clearnet domain name and an onion domain name. An example of a clearnet domain name is whonix.org. An example of a onion domain name is dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion. The clearnet domain must be reachable TLS with a valid TLS certificate. This is because when a website is reachable over .onion which has a corresponding clearnet domain name with the same contents, hosted by the same author, its easier to verify the identity of the website author, when the website was created, where the website or its maintainers are located.

There needs to be evidence that that onion domain is hosted by the same author as the clearnet domain. This can be a mention of the onion domain on the clearnet domain or the Onion-Location HTTP header ^[archive]. The latter can be conveniently noticed by visiting the website using Tor Browser and then showing onion available and seen by using services such as securityheaders.com or using the curl command line tool, i.e. curl --head https://clearnet.domain [archive].

Onion services likely hosted on the same hardware or by the same author will be grouped together and act as one. I.e. these will be considered mirrors of the same onion. sdwdate picks one mirror from the group randomly. Any onion from that author will not be used more than other pool members. The load among these grouped pool members will therefore be load balanced.

Reasons:

This provides higher certainty of having trustworthy time source members because these websites and services services have a reputation to maintain. This includes for example e-mail services such as protonmail, ctemplar and so forth or big news network like The Guardian and so on. Note: Just because these are known organizations and very hard to make them operate maliciously that doesn't mean there are guarantees whether by mistake, hacks or by outside pressure.

Unrealistic Time Source Criteria

• The onion service being popular or receiving great amount of traffic. This is very hard to verify, compare as outsider and reason about. Also (very) high traffic onion services might be less reliable.

Rules for sdwdate time source related git pull requests

New sdwdate pool member additions must be proposed in public in Whonix ™ development forum thread Suggest Trustworthy Tor Hidden Services as Time Sources for sdwdate ^[archive] to allow anyone to comment on it.

• the following type of changes need to be proposed separately using separate pull requests
  • removal of sdwdate pool members because these are offline, unreliable, their clock is too much off or otherwise no longer comply with the requirements
  • updates to already existing sdwdate pool members
    • such as updated onion domain names in case the onion domain name change
    • or if the onion domain was upgraded from onion v2 to onion v3
  • additions of new sdwdate time sources (if there where no objections in previous forum discussion)

Time Sources Exclusion Criteria

The rationale for the following exclusion criteria is to avoid likely insecure websites and also to avoid any mention whatsoever of controversial content within sdwdate source code.

The following categories must be avoided and deleted if turning out later so:

• Unstable Website: Its not useful to add a service which goes off and on periodically.
• Sold Out Website: Its better to remove website if its happen to be sold out and its content will be changed.
• Website Went Offline: If the website went offline then it should removed.
• Contain Any Form of Pornographic Content.
• Contain or Encourage on Damaging Human Health: like drugs, alcohol, smoke, etc.
• Contain Any Form of gore, gangs, terrorist, assassination Content.
• Contain Deanonymization or Cracking Services or Spying Agencies: like HackingTeam ^[archive] or Cellebrite ^[archive] or the NSA, GCHQ, etc.
• Contain or Related to Any Form of Governmental Website: like ministries or military websites or anything similar. (Specially those which end with .gov.)
• Draw highly controversial attention to Whonix ™ or sdwdate due to their on-site or off-site activities.
• Websites which Whonix ™ as default software sources (such as Debian, Whonix, Qubes, The Tor Project) or other purposes (The Tor Project's check.torproject.org webiste for whonixcheck --leak-tests). This is should there be any issues with these services (such as being down for maintenance or other issues such as being under a denial of service attack) this should not break multiple things in Whonix ™ such as sdwdate and APT upgrading at the same time.

Contributor Proposed Version 2.0

It is being proposed to drop the requirement hosted by non-anonymous organizations or persons. I.e. onion's hosted by anonymous organizations or persons should also be permitted under the following conditions.

• Here things are little bit more trickier as we cannot know much except what the website claiming to be so we cannot know who, where, how long etc. this website was running. So we need verification mechanism to check:
  • Consensus or Aggregation of Testimonies: We try to collect users opinions on this website and thus clearnet will be heavily involved into this specially in social media and blogs. So we can verify this website is really doing what it claims to be doing. For example, an e-mail service claiming to not spam their users should not spam their users.
  • Seniority: The older a website becomes, the more trustworthy it will be considered if there have not been any (deliberate or by mistake?) public verifiable breaches of its promises. Recently established websites cannot be with reasonable certainty considered well tested, established, being scam, fraud, deception or not.

Tor Consensus Time Sanity Check

sdwdate checks if dates/times from remote servers (onions) are within Tor consensus/valid-after and consensus/valid-until date/time, otherwise rejects those. An example from sdwdate log.

2021-01-09 14:47:17 - sdwdate - INFO - * consensus/valid-after: 2021-01-09 13:00:00
2021-01-09 14:47:17 - sdwdate - INFO - * remote_time          : 2021-01-09 14:49:38
2021-01-09 14:47:17 - sdwdate - INFO - * consensus/valid-until: 2021-01-09 16:00:00
2021-01-09 14:47:17 - sdwdate - INFO - * time_consensus_sanity_check: sane

sdwdate Clock Randomization

Log example.

End fetching remote times.
pool differences, sorted: [-35, 5, 5]
median time difference: +5.000000000
randomize             : -0.976225329
new time difference   : +4.023774671

The rationale for that is that an onion time source could try to tag specific users. sdwdate uses the median time (not average) fetch result. (Average time of the 3 pools would not be be safe. To explain, suppose one pool returning a result of -1000 seconds time difference would overpower the time pools with a more realistic time difference of for example -1 and -2 seconds.)

Let's say the normal distribution for most users would be pool differences, sorted: [7, 5, 3]. Then and onion time source could experiment with saying 4, 5, 6 to split users into different groups. This is assuming that not too many users ask the same server at the very same time. A realistic assumption given that the total number of Tor users is not that high. By adding up to ± 1 second it gets harder to tag specific users.

After boot, sdwdate sets the time using the date after fetching times from remote.

• Without clock randomization: The command executed from sdwdate could be sudo date --set "Tue 12 Jan 2021 06:48:55 AM UTC". This allows for more opportunities to tag user because nanoseconds are to 0 without any randomization. The full command to be run could be guessed by the sdwdate time source. Or might change from
  • old unixttime: 1610866967.519335985 to
  • new unixtime : 1610866966.519335985.
• With clock randomization: The command executed from sdwdate could be sudo date --set "Tue 12 Jan 2021 06:48:55:976225329 AM UTC". Only the first part of the date/time Tue 12 Jan 2021 06:48:55 AM UTC can be guessed but an an extra random clock skew is introduced. The random nanoseconds part 976225329 being unpredictable by remote time sources.

(These are just examples. sdwdate internally actually uses unixtime since that is easier in the program. Just to illustrate the mode of operation.)

If nanoseconds are randomized and later leaked to for example remote web servers, it won't be possible for the remote web server know if clock is just skewed normally or if it was set using sdwdate with randomization. Rationale of randomization is making it look more like a naturally skewed clock.

Accuracy of sdwdate is far outside of ± 1 second anyhow. Due after asking a remote onion web servers for the time and the result being relayed back through the slow Tor network to the user with hard to predict latency, nanoseconds might not matter anyhow. By the time sdwdate running date, nanoseconds might already be randomized without extra randomization required.

When supposing for the sake of threat modeling that a web server can observe clock jumps from remote because of lets say browser, javascript or something leaks it is better to jump to a randomized number of nanoseconds 976225329 than 000000000.

In sdwdate clock randomization was enabled by default for many versions. From sdwdate version 11.8 and above it needs to be opt-in, which is only done inside Whonix ™ through package anon-apps-config ^[archive] /etc/sdwdate.d/40_anon-apps-config.conf ^[archive] RANDOMIZE_TIME=true. sdwdate version 11.8 does not enable clock randomization by default for non-Whonix ™ users.

This feature, sdwdate clock randomization, is unrelated to Boot Clock Randomization. sdwdate Clock Randomization happens only after sdwdate has fetched the time from onion time sources before setting the time. Boot Clock Randomization happens at boot time only. See also Boot Clock Randomization.

No clock randomization is planed when temporarily setting time based on Tor certificate lifetime or Tor consensus time middle range. This is because these times are so far off from the the real world time and so few users are using it that randomization could not help or even make users more trackable.

Onion Time Sources Candidates List

The links below are listed to keep track of pool candidates:

• https://en.wikipedia.org/wiki/SecureDrop ^[archive]
• https://freedom.press/securedrop/directory ^[archive]
• https://en.wikipedia.org/wiki/GlobaLeaks#GlobaLeaks_uses ^[archive]

Screenshots

Figure: sdwdate GUI Control Panel

Figure: sdwdate GUI Successful Check

Related

• Timezone
• Time Attacks
• Dev/sdwdate
• Dev/TimeSync
• sdwdate-gui

Footnotes

---

Whonix ™ is Supported by Evolution Host DDoS Protected VPS. Stay private and get your VPS with Bitcoin or Monero.

---

Jobs in USA

---

Search engines: YaCy | Qwant | ecosia | MetaGer | peekier | Whonix ™ Wiki

---

Follow:

Support:

Donate:

Share: Twitter | Facebook

Please contribute by helping to answer Whonix ™ questions.

This is a wiki. Want to improve this page? Help is welcome and volunteer contributions are happily considered! Read, understand and agree to Conditions for Contributions to Whonix ™, then Edit! Edits are held for moderation. Policy of Whonix Website and Whonix Chat and Policy On Nonfreedom Software applies.

Copyright (C) 2012 - 2020 ENCRYPTED SUPPORT LP. Whonix ™ is a trademark. Whonix ™ is a licensee ^[archive] of the Open Invention Network ^[archive]. Unless otherwise noted, the content of this page is copyrighted and licensed under the same Freedom Software license as Whonix ™ itself. (Why?)

Whonix ™ is a derivative of and not affiliated with Debian ^[archive]. Debian is a registered trademark ^[archive] owned by Software in the Public Interest, Inc ^[archive].

Whonix ™ is produced independently from the Tor® ^[archive] anonymity software and carries no guarantee from The Tor Project ^[archive] about quality, suitability or anything else.

By using our website, you acknowledge that you have read, understood and agreed to our Privacy Policy, Cookie Policy, Terms of Service, and E-Sign Consent. Whonix ™ is provided by ENCRYPTED SUPPORT LP. See Imprint, Contact.