«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.

Reliable time

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

First, you need an NTS capable software. It appears that NTPsec and Chrony are currently the only choices. In this example, we use Chrony, but feel free to use NTPsec instead.

• 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 timed from launchd configuration).
• Windows: Apparently, there is no NTS software support available there.

Some example setups:

apt install chrony # Uninstalls other NTP software

pkg install chrony
echo chronyd_enable=YES >> /etc/rc.conf.local

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

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/chrony/chrony.conf or /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 (server, peer, and pool directives).

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:

nocerttimecheck 1

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.

Therefore, I maintain a list of public NTS servers. As of 2023-08-12, it has been moved to its own page: Public NTS Server List.

More servers

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.

History

2021-12-28: Added/improved install instructions for various platforms; added some additional servers and outlined listing policy.

2021-12-31: Added ntp.br servers.

2022-01-08: Listed Linux distributions with NTS-capable software.

2022-01-10: Added 0xt.ca servers by agreement.

2022-01-11: Added time.signorini.ch by agreement.

2022-02-03: Added nts1.adopo.net, www.jabber-germany.de, and www.masters-of-cloud.de by agreement.

2022-06-04: Added virginia.time.system76.com, ohio.time.system76.com, and oregon.time.system76.com by agreement.

2022-08-02: Added ntpmon.dcs1.biz by agreement. Added ntp3.fau.de. Updated NL to production servers. Updated the paragraph below the table.

2022-09-04: Removed most 0xt.ca servers as these will be shutting down at the end of this month. time.0xt.ca will remain.

2022-09-26: Added {paris,brazil}.time.system76.com by agreement.

2023-08-12: Moved list out of this post to the Public NTS Time Server List page.