Network Time Security with Chrony (RFC 8915)

Plain NTP is unauthenticated, and that has always been an uncomfortable fact: an attacker who can spoof or intercept NTP packets can shift a host's clock, which corrupts log correlation, breaks certificate validation, and in some protocols creates genuine security exposure. NTS solves this by adding a TLS-based key exchange and authenticated extension fields, and chrony has supported it for years. This article covers the configuration, the verification that proves authentication is actually in place, and the fallback behaviour you should think about before deployment.

How NTS works in practice

NTS has two parts. A key establishment (NTS-KE) phase runs over TLS on TCP port 4460 and produces a set of cookies and keys. The time transfer phase then uses ordinary NTP packets carrying NTS extension fields, with each request authenticated by a key derived during the handshake and each response verified against one of the cookies the server issued. The TLS session only has to happen occasionally — the cookies let subsequent NTP exchanges be authenticated without a new handshake.

The practical consequence is that NTS requires a time source that actually supports it, which rules out most public pool servers. Choose a provider that publishes NTS support before designing around it.

Configuration

# /etc/chrony/chrony.conf

# NTS-enabled sources: hostname is required (the TLS certificate is validated
# against it), and chrony performs NTS-KE automatically on first start.
server time.cloudflare.com iburst nts
server nts.netnod.se iburst nts

# Where to cache the obtained cookies across restarts
ntsdumpdir /var/lib/chrony

# Keep unauthenticated sources as a documented fallback, if policy allows
# pool pool.ntp.org iburst

driftfile /var/lib/chrony/drift
makestep 1.0 3
rtcsync
logdir /var/log/chrony

Three points matter. The server must be configured by hostname, because certificate validation depends on it — an IP address cannot be verified and chrony will refuse the connection. The ntsdumpdir allows cookie reuse across restarts, which reduces the window in which chrony has no authenticated data to work with. And whether you keep unauthenticated fallback servers is a policy decision: keeping them maintains time accuracy during a provider outage, at the cost of allowing a downgrade path.

Making it persistent

mkdir -p /var/lib/chrony
chown _chrony:_chrony /var/lib/chrony
systemctl restart chrony
systemctl status chronyd | head -20

Verifying authentication is real

chronyc -N authdata

Name/IP address             Mode KeyID Type KLen Last Atmp  NAK Cook CLen
time.cloudflare.com          NTS     1   15  256  112    0    0    8  100
nts.netnod.se                NTS     1   15  256   95    0    0    8  100

The Mode column reading NTS is the proof. A value of NTS with a non-zero Cook count means the key exchange succeeded and cookies are available for authenticated requests. If the mode shows something else, or if chronyc -N authdata returns nothing, chrony silently fell back to unauthenticated operation — a failure that looks like working time because the clock is still accurate.

chronyc sources -v
chronyc tracking
chronyc -N serverstats
journalctl -u chronyd | grep -i nts | tail -20

chronyc sources -v is where you confirm the sources are selected and reachable; a source can be authenticated and still not selected, which is normal during initial synchronisation. The journal is useful for diagnosing the TLS handshake specifically, since certificate problems surface there with a clear error rather than as a mysterious source failure.

Verification checklist and pitfalls

• TLS port must be permitted — NTS-KE uses TCP 4460. A firewall allowing only UDP 123 will produce sources that never authenticate.
• Certificate trust — the CA bundle used by chrony must include whatever signs the provider's certificate. Minimal container images often ship an empty bundle.
• No fallback to IP addresses — replacing the hostname with an address in the config silently disables NTS.
• Bootstrap sequence — on a cold boot with a badly wrong clock, TLS may fail before time is even approximately correct. Keep one local or IP-based source for initial step, then rely on NTS.
• Monitoring — alert on the loss of NTS mode, not only on offset. A system that quietly reverts to unauthenticated NTP is a security regression that no accuracy alert will catch.

Where this fits

NTS protects the time source hop. It does not protect the applications consuming time, and it does not replace disciplined design: a host with a single authenticated source still has a single point of failure, and a host whose clock steps during a transaction will misbehave regardless of how that time was obtained. Where sub-microsecond accuracy is required, PTP remains the right tool and the trade-offs are different — our NTP vs PTP time synchronisation selection covers the selection criteria. For the foundational configuration, Chrony NTP server configuration on Linux covers a conventional chrony deployment to compare against.

Log correlation is the most immediate beneficiary: authenticated timestamps plus a centralised log path means the timeline you reconstruct during an incident is one you can defend.

原文链接：https://www.rfc-editor.org/rfc/rfc8915.html