«Time is Money», as the old adage says. Who controls the time, controls all kinds of operations and businesses around the world. And therefore, controls the world. Today, we all take accurate time for granted. Even though, today, it is delivered over the Internet mostly unsecured. But this is easy to change.
Switching from NTP to NTS is as easy and important as moving from HTTP to HTTPS.
(Part 1 in the NTS series.)
What could possibly go wrong?
In the old times™, accuracy in the order of decades („during the reign of King Herod“) or years („a boy of seven summers“) might have been good enough. Today, hours and minutes are the minimum for many processes and in some cases, even milliseconds are too coarse.
Anything from industrial control systems over (distributed) file systems to everything even remotely related to security depends on time and will break one way or another if time is wrong: HTTPS/TLS/X.509 certificates, PGP keys, DNSSEC, two-factor authentication, overwriting or expiring backups, and even vaccination certificates, to name just a few.
Different applications have different requirements on time: For some, such as rate measurement devices, a coherent pace may be important. For others, including certificate validity checks, the actual, absolute, time is key; they can live with uneven speeds of time advancing.
There might have been a time where exploring each application’s detailed reliability requirements might have been necessary. However, today, for the vast majority of everyday applications, the answer is easy: Just use authenticated NTP, aka NTS!
Installing NTS capable software
- GNU/Linux: Almost all distributions include NTPsec or Chrony prepackaged in a way that installing them will replace the preinstalled time synchronization service. However, only NTPsec>=1.2.0 and Chrony>=4.0 include NTS support.
Debian 11 (bullseye; also buster-packports), Ubuntu 21.04 (hirsute), Arch Linux, Fedora 34 and newer are among the distributions including sufficiently new versions.
- Other Unix-like systems: Check for packages or build instructions; most BSD systems include a Chrony package.
- MacOS: Install ChronyControl (or, install Chrony with Homebrew and disable
- Windows: Apparently, there is no NTS software support available there.
Some example setups:
apt install chrony # Uninstalls other NTP software
Already installed, nothing to do!
pkg install chrony echo chronyd_enable=YES >> /etc/rc.conf.local
The configuration file will live in
Download and install ChronyControl, then select Action → Install chrony. The configuration can be edited from the Gears menu in the window.
MacOS Command Line
Install Homebrew, then run the following commands:
brew install chrony sudo launchctl disable system/com.apple.timed sudo tee << "EOF" /Library/LaunchDaemons/org.tuxfamily.chrony.plist <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>Label</key> <string>org.tuxfamily.chrony</string> <key>Nice</key> <integer>-10</integer> <key>ProgramArguments</key> <array> <string>/usr/local/sbin/chronyd</string> <string>-n</string> </array> <key>RunAtLoad</key> <true/> </dict> </plist> EOF sudo launchctl load /Library/LaunchDaemons # Only after you create /etc/chrony.conf sudo launchctl start system/org.tuxfamily.chrony
The configuration file will be
/etc/chrony.conf; the service will not start without it.
Configuring Chrony or NTPsec
Then, choose 3-4 NTS servers from the list of public NTS servers, below and add them to the configuration file (e.g.,
/etc/ntpsec/ntp.conf), making sure that they have the
nts flag set. For a configuration in Switzerland, the following lines might be added to the configuration file (syntax compatible with both Chrony and NTPsec):
server ntp.3eck.net iburst nts server ntp.trifence.ch iburst nts server ntp.zeitgitter.net iburst nts
If you use Chrony, you may want to consider adding the
authselectmode prefer directive on a line of its own to disable non-NTS sources in the presence of NTS servers.
After your server chimes reliably, you can also consider removing the unauthenticated (non-NTS) sources (
Raspberry Pi caveats
The popular Raspberry Pi computers lack a real-time clock, as do several other single-board or embedded computers, including most home routers. This means that on power-up, these machines do not have the faintest idea what time it is, not even the year or decade. This makes it impossible to verify the validity of TLS certificates, as is required for establishing a trustworthy HTTPS or NTS connection. (On those machines, you might have seen „Invalid certificate“ warnings, especially if you only connect it to the network after you have already logged in.)
This results in a chicken-and-egg problem: The machine does not know the time, therefore, it cannot get a reliable time, as it relies on NTS verifying the validity period of the certificate.
If you can use Chrony, the easiest and most secure way out is to add the following configuration line:
This instructs Chrony to not check the certificate validity time until it has set the clock the first time. Short of adding an RTC chip or GNSS („GPS“) receiver, this is the most secure option possible. It beats the other option of adding enough non-NTS servers to make (entirely unauthenticated!) initial time setting possible. (If the time is ever maliciously off, it will never revert back to the real time!)
Public NTS-capable servers
Currently, the number of public servers with NTS support still seems very modest:
Except for the Swiss, US, and Canada servers, they have not agreed to appear on this list, but are self-listed as publicly available. So, before you use them, please check the links of whether they are still available and under what policy.
ntp.3eck.net is in Zurich and operated by Adrian Zaugg, who also inspired me to this post and provided feedback.
time.signorini.ch is in Ticino and operated by Attilio Signorini.
ntp.zeitgitter.net are near Zurich (Winterthur) and operated by me.
NTS is an important upgrade to NTP. Hopefully, the number of NTP servers with NTS authentication will grow quickly. This should not be too hard, as all the infrastructure (e.g., Let’s Encrypt), tools, and know-how which has been used to migrate HTTP to HTTPS in the recent years can be reused. Upgrading an existing NTP server to NTS is even simpler as upgrading a web servers, as there are no problems with HTTP redirects and mixed content. (Basically, it is as easy as pointing NTPsec or Chrony to the private key and certificate chains.)
If (or when) you run a public server with NTS, please let me know, so I can add it to this list.
2021-12-28: Added/improved install instructions for various platforms; added some additional servers and outlined listing policy.
2022-01-08: Listed Linux distributions with NTS-capable software.
0xt.ca servers by agreement.
time.signorini.ch by agreement.
Why time is important in today’s protocols
Assuring consistent state at multiple sites is very hard in the presence of timeouts and errors. Most solutions require complex protocols, multiple round-trip times and/or large amounts of communication or storage. Therefore, instead of trying to achieve perfect synchronization such as two-phase commit, often a „soft state“ approach is chosen, where the validity of state (e.g., credentials) expires after some well-defined period. This ensures that inconsistencies will self-heal, putting the burden on reliable time.