Actions

sdwdate: Secure Distributed Web Date

From Whonix



sdwdate-gui Control Panel

Introduction[edit]

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

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 [1]
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 [2] [3]
Possible to secure by default on GNU/Linux distribution level Yes No [4]
Secure Yes No [5]
Optional GUI Yes, sdwdate-gui (a systray icon) No

See also:

TODO:

sdwdate Design[edit]

Server Authentication[edit]

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, [8] the pool is considered as potentially compromised and sdwdate aborts.

sdwdate Source Pools[edit]

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. [9] [10]

sdwdate Time Sources Criteria[edit]

Current Implementation 1.0[edit]

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

  • 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. [11]
    • If there is a forced redirection from (non-TLS) http onion to TLS https onion, the TLS certificate must be valid. [12]
  • 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[edit]

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

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

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

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

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

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

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

Screenshots[edit]

Figure: sdwdate GUI Control Panel

Sdwdate2.png

Figure: sdwdate GUI Successful Check

Sdwdate3.png

Related[edit]

Footnotes[edit]

  1. Requires UDP which is unsupported by Tor, see Tor#UDP.
  2. http://lists.ntp.org/pipermail/questions/2007-October/015754.html [archive]
  3. http://linux.derkeiler.com/Mailing-Lists/Debian/2003-07/0361.html [archive]
  4. NTP security vulnerability because not using authentication by default [archive]
  5. See Dev/TimeSync#NTP.
  6. If replacing ntp with sdwdate, run the following command to avoid the installation of 160+ recommended packages:
    sudo apt --no-install-recommends install sdwdate

  7. https://forums.whonix.org/t/sdwdate-and-headless-system/8491 [archive]
  8. For example, due to being unreachable or replying with invalid data.
  9. https://github.com/Whonix/Whonix/issues/310 [archive]
  10. https://gitlab.tails.boum.org/tails/tails/-/issues/8283 [archive]
  11. https://phabricator.whonix.org/T131 [archive]
  12. For now, this is for technical reasons only. url_to_unixtime refuses websites that redirect from (onion) http to (onion) https which at the same time have an invalid TLS certificate. Adding extra code to ignore invalid TLS certificates hasn't been done yet. It might also be argued in future, that if an onion provides a valid TLS certificate, that onion should be fetched over TLS and certificate errors should not be ignored. See Notes about End-to-end Security of Onion Services. Onion services reachable over non-TLS http which do not redirect to TLS https are acceptable.


text=Jobs in USA
Jobs in USA


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


Follow: 1024px-Telegram 2019 Logo.svg.png Iconfinder Apple Mail 2697658.png Twitter.png Facebook.png Rss.png Reddit.jpg 200px-Mastodon Logotype (Simple).svg.png

Support: 1024px-Telegram 2019 Logo.svg.png Discourse logo.png Matrix logo.svg.png

Donate: Donate Bank Wire Paypal Bitcoin accepted here Monero accepted here Contriute

Whonix donate bitcoin.png Monero donate Whonix.png United Federation of Planets 1000px.png

Share: Twitter | Facebook

Please contribute by helping to answer Whonix ™ questions.

https link onion link

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.