1. Related Links
2. Table of Contents
NTS is a method for using TLS/SSL to authenticate NTP traffic on the net. That means that bad guys can’t forge packets that will give your system bogus time.
The RFC hasn’t been published yet (December 2019). Nothing has changed recently, but there may be minor adjustments when it is finalized.
Note: The NTP Pool does not currently support NTS.
It is strongly suggested that you get a "normal", unauthenticated, NTP server working before enabling NTS. This may reduce the time spent debugging. See the Client Quick Start Guide.
4. NTS Client Configuration
Append the keyword nts to the end of your server lines. Do this only for servers that speak NTS. If the server uses a port other than 123 for NTS key exchange, you also need to specify the port number. As of December 2019, the following should work:
Public NTP servers supporting NTS:
server time.cloudflare.com:1234 nts # Global, anycast server nts.ntp.se:4443 nts # Sweden
CloudFlare supports only TLS 1.3. To use TLS 1.3, you must have OpenSSL 1.1.1 or higher.
Development machines, so there may be gaps in availability:
server ntpmon.dcs1.biz nts # Singapore server ntp1.glypnod.com nts # San Francisco server ntp2.glypnod.com nts # London
Note that you must use the same host name that was used to create the server’s certificate. IP addresses will not work.
This assumes that the server is using a certificate covered by your OS/distro’s root certificate collection.
NetBSD needs the mozilla-rootcerts-openssl package and ca /etc/openssl/certs/ added to the server line.
Restart ntpd, and skip to Verification, below.
5. NTS Server Configuration
Being an NTS server requires a well-formed SSL certificate. The easiest way to do this is to use Let’s Encrypt. It needs a FQDN. Please see the certbot client site for instructions.
The following worked on Fedora:
$ sudo dnf install certbot # Install $ sudo certbot certonly --standalone # Renew $ sudo certbot renew $ sudo killall -HUP ntpd
If you already have an SSL certificate for your server, and you are serving time using the same FQDN, you can reuse that certificate.
Next, add the line: nts enable to your ntp.conf file.
Locate the following two files:
Your certificate private key
Your certificate chain (i.e. your certificate followed by any intermediate CA certificates)
Then add the lines below to your ntp.conf, replacing with your pathnames.
Example, using Let’s Encrypt:
nts key /etc/letsencrypt/live/ntp.example.com/privkey.pem nts cert /etc/letsencrypt/live/ntp.example.com/fullchain.pem
Note that ntpd must be able to read both files and you want to make sure that the bad guys can’t read your private key. It may be simpler to copy those files over to /etc/ntp/ and adjust their owner and mode so ntpd running as user ntp can read them.
You may need to tell your system where to store the keys used to encrypt cookies. The default is /var/lib/ntp/nts-keys. Some distros use /var/db/ rather than /var/lib/.
nts cookie /var/lib/ntp/nts-keys
Again, make sure the bad guys can’t read that file.
Restart your server, and skip to Verification, below.
Check your log file. The current client side NTS implementation is quite chatty. The log lines may change, but what you see should be similar to below.
As a client, you should see lines like this:
2019-03-22T08:06:33 ntpd: DNS: dns_probe: pi3.rellim.com, cast_flags:1, flags:21801 2019-03-22T08:06:33 ntpd: NTSc: DNS lookup of pi3.rellim.com took 0.003 sec 2019-03-22T08:06:33 ntpd: NTSc: nts_probe connecting to pi3.rellim.com:ntp => 22.214.171.124:123 2019-03-22T08:06:34 ntpd: NTSc: Using TLSv1.2, AES256-GCM-SHA384 (256) 2019-03-22T08:06:34 ntpd: NTSc: certificate subject name: /CN=pi3.rellim.com 2019-03-22T08:06:34 ntpd: NTSc: certificate issuer name: /C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3 2019-03-22T08:06:34 ntpd: NTSc: certificate is valid. 2019-03-22T08:06:34 ntpd: NTSc: read 880 bytes 2019-03-22T08:06:34 ntpd: NTSc: Got 8 cookies, length 104, aead=15. 2019-03-22T08:06:34 ntpd: NTSc: NTS-KE req to pi3.rellim.com took 0.882 sec, OK
For initializing a server, you should see lines like this:
27 Dec 12:03:47 ntpd: INIT: OpenSSL 1.1.1d FIPS 10 Sep 2019, 1010104f 27 Dec 12:03:47 ntpd: NTSs: starting NTS-KE server listening on port 123 27 Dec 12:03:47 ntpd: NTSs: loaded certificate (chain) from /etc/ntp/fullchain.pem 27 Dec 12:03:47 ntpd: NTSs: loaded private key from /etc/ntp/privkey.pem 27 Dec 12:03:47 ntpd: NTSs: Private Key OK 27 Dec 12:03:47 ntpd: NTSs: OpenSSL security level is 1 27 Dec 12:03:47 ntpd: NTSs: listen4 worked 27 Dec 12:03:47 ntpd: NTSs: listen6 worked 27 Dec 12:03:47 ntpd: NTSc: Using system default root certificates.
On a server, each time a client uses TLS to setup cookies, you should see lines like these. If all goes well, there is a single line for each connection.
1 Dec 22:42:21 ntpd: NTSs: NTS-KE from 192.168.1.71:43560, Using TLSv1.3, TLS_CHACHA20_POLY1305_SHA256 (256), took 0.018 sec 1 Dec 22:42:56 ntpd: NTSs: NTS-KE from 192.168.1.61:33930, Using TLSv1.2, ECDHE-RSA-AES256-GCM-SHA384 (256), took 0.075 sec
Servers on the big bad internet will get a lot of garbage connections. The common cases produce a single line. Less common cases will have additional lines with OpenSSL error data.
26 Dec 18:13:55 ntpd: NTSs: SSL accept from 126.96.36.199:52188 failed: wrong version number, took 0.000 sec 26 Dec 18:24:20 ntpd: NTSs: SSL accept from 188.8.131.52:56525 failed, took 0.101 sec 26 Dec 18:24:20 ntpd: NTS: error:14094418:SSL routines:ssl3_read_bytes:tlsv1 alert unknown ca
alert means the client on the other end encountered troubles and is reporting them back to the server.
The logging prefix NTSs is for the NTS server component. The NTSc component is for the NTS client part, where you are talking to NTS servers.
6.1. Check with ntpq
The output of ntpq will be slightly different when NTS is in use, note the t column. Example:
root@ntpmon:/var/www/html/ntp# ntpq -p remote refid st t when poll reach delay offset jitter *SHM(1) .PPS. 0 l 20 64 377 0.0000 0.0007 0.0281 xSHM(0) .GPS. 0 l 19 64 377 0.0000 233.3966 19.2212 +pi3.rellim.com .PPS. 1 8 56 64 371 197.4484 0.0932 0.9660 +kong.rellim.com 184.108.40.206 2 8 17 64 273 210.7230 -1.3924 0.6086 -ntp1.glypnod.com 220.127.116.11 2 8 50 64 277 178.5749 3.8921 0.9611 -ntp2.glypnod.com 18.104.22.168 2 8 - 64 177 185.7582 -2.6534 0.0275 2407:8000:8001:80::8 .DNS. 16 u - 1024 0 0.0000 0.0000 0.0005 -navobs1.wustl.edu .GPS. 1 u 105 64 356 221.5282 -2.4354 0.0293
The t column shows how many cookies your NTS client is holding for the appropriate servers. The number should be 8. Lower numbers indicate dropped packets. (7 could be a packet in flight.)
The RFC calls for the server to rotate the private key used to encrypt cookies every 24 hours. The server also saves the previous key so old cookies will work for at least 24 hours. 24 hours and 8 cookies will work for a polling interval of up to 3 hours. That’s much longer than the default maxpoll of 10 (1024 seconds).
6.2. Check ntp variables
Try ntpq -c nts. This will show various counters related to NTS. This feature is under active development, so the format might change. An example:
root@ntpmon:/var/www/html/ntp# ntpq -c nts NTS client sends: 7491 NTS client recvs: 6562 NTS client recvs w error: 0 NTS server recvs: 5591 NTS server recvs w error: 38 NTS server sends: 5553 NTS make cookies: 6392 NTS decode cookies: 4734 NTS decode cookies old: 819 NTS decode cookies too old: 0 NTS decode cookies error: 0 NTS KE probes: 8 NTS KE probes_bad: 0 NTS KE serves: 75 NTS KE serves_bad: 56