Kategorien
How-to Open Source

Transparent, Trustworthy Time with NTP and NTS

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

Debian/Ubuntu

apt install chrony # Uninstalls other NTP software

Fedora

Already installed, nothing to do!

FreeBSD

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

The configuration file will live in /usr/local/etc/chrony.conf.

MacOS GUI

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/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:

Location Servers Notes
Global time.cloudflare.com Anycast
Brasil a…d.st1.ntp.br
Canada time.0xt.ca
Germany ptbtime1…3.ptb.de
Netherlands nts.time.nl Pilot
Sweden nts.netnod.se Anycast
Sweden sth1…2.nts.netnod.se STH area
use only
Switzerland ntp.3eck.net
Switzerland ntp.trifence.ch
Switzerland ntp.zeitgitter.net
Switzerland time.signorini.ch Dynamic,
Chrony-only
USA time-{dfw,ewr,atl,sjc}.0xt.ca

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.

Other servers appear in some lists or setup instructions and may even have monitoring pages. They are not included in this list, unless there is some indication about their public availability.

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.trifence.ch and ntp.zeitgitter.net are near Zurich (Winterthur) and operated by me.

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.

Why time is im­por­tant in today’s proto­cols

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.

Schreibe einen Kommentar

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.