⏱️ Securing Linux Time Sync with chrony and NTS (Network Time Security)

Time is a security primitive, and almost nobody treats it like one. Your TLS certificate validation, your Kerberos tickets, your TOTP codes, your log correlation, and half your distributed systems’ consistency guarantees all assume the clock is roughly right and roughly honest. Classic NTP provides neither authentication nor integrity — an attacker who can intercept your time traffic can quietly walk your clock forward or backward, and suddenly valid certificates look expired, Kerberos rejects everyone, and your audit timestamps are fiction.

NTS — Network Time Security — fixes this. It’s authenticated, integrity-protected time sync, and chrony has supported it for years. If you run chrony (and on modern distros you probably do), turning on NTS is one of the highest-security-per-effort changes available. Here’s how I set it up, and where an AI copilot helps validate the config and reason about the failure modes.

Why unauthenticated NTP is a real risk

The threat isn’t theoretical. Moving a host’s clock can:

• Break or bypass TLS. Push the clock past a cert’s expiry and connections fail; push it back before a revoked cert’s window and you may un-revoke it in the client’s eyes.
• Destroy Kerberos. Kerberos rejects tickets when clock skew exceeds (typically) five minutes. An attacker who skews your clock can deny all authentication.
• Corrupt logs and forensics. Inconsistent or manipulated timestamps make incident reconstruction unreliable — exactly when you need it most.
• Replay TOTP. Time-based one-time passwords depend on a shared clock.

Plain NTP packets are unauthenticated UDP. NTS wraps the time exchange in a TLS-authenticated key establishment so your client can verify it’s talking to the real server and that the time data wasn’t tampered with in flight.

Checking what you have

chronyc tracking          # current sync state, offset, stratum
chronyc sources -v        # the servers chrony is using
chronyc authdata          # NTS key/cookie status per source (the tell)

If chronyc authdata shows your sources with no NTS keys, you’re running unauthenticated. That’s the gap we’re closing.

Configuring chrony with NTS

NTS-capable public servers exist. The config change is small — add nts to your server lines and ensure the CA trust is available for the TLS handshake:

# /etc/chrony/chrony.conf  (or /etc/chrony.conf)

# NTS-secured time sources
server time.cloudflare.com iburst nts
server nts.netnod.se iburst nts

# Where chrony stores NTS cookies so it doesn't re-key every boot
ntsdumpdir /var/lib/chrony

# Keep drift handling as usual
driftfile /var/lib/chrony/chrony.drift
makestep 1.0 3
rtcsync

The nts keyword is the whole point. iburst speeds initial sync. The ntsdumpdir lets chrony persist NTS cookies across restarts so it isn’t doing a full key establishment on every boot.

sudo systemctl restart chrony
chronyc authdata          # now should show NTS-KE established, cookies present
chronyc sources -v        # sources should show the 'N' (authenticated) flag

If authdata shows established keys and a healthy cookie count, you’re synchronizing over authenticated time. If it’s empty or erroring, that’s almost always a TLS trust or firewall problem — NTS key establishment runs over TCP/4460, separate from the NTP/UDP/123 traffic, and people forget to open it.

The failure modes worth understanding

NTS introduces a few new ways to fail that plain NTP didn’t have, and they’re worth knowing before they page you:

• TCP/4460 blocked. NTS key establishment (NTS-KE) uses TLS over TCP, typically port 4460. A firewall that only allows UDP/123 will let plain NTP through but silently break NTS.
• CA trust gaps. The NTS-KE handshake is a TLS handshake; if your system CA bundle is broken or stale, key establishment fails. This ties time security to your CA trust store health.
• The bootstrap paradox. TLS needs roughly-correct time to validate certs, and NTS provides time over TLS. In practice chrony tolerates modest skew during NTS-KE, but a wildly wrong clock (dead RTC battery, fresh VM with epoch-zero time) can stall the handshake. Keep at least one fallback and consider makestep to allow an initial large correction.

Letting AI pressure-test the config

A time config that looks right but quietly falls back to unauthenticated sync is the dangerous case, so I have an AI copilot review the config and the authdata output together and tell me whether NTS is genuinely in force.

Prompt: You are a senior Linux engineer. Here is my chrony.conf and the output of chronyc authdata and chronyc sources -v. Confirm whether NTS is actually authenticating my time sources or silently falling back to plain NTP, list any source not protected, and flag firewall/CA prerequisites I might be missing.

Response (excerpt): Two of your three sources show NTS-KE established with cookies > 0 and the ‘N’ authentication flag in sources -v — those are genuinely NTS-protected. The third (pool 2.debian.pool.ntp.org) has no NTS keys and is plain NTP; it can still influence your clock, so either drop it or replace it with an NTS server. Prerequisites: confirm outbound TCP/4460 is open (NTS-KE) in addition to UDP/123, and that your CA bundle validates the NTS server certs — a stale ca-certificates package will break the handshake. Verify with chronyc authdata showing nonzero, non-expiring cookie counts.

That caught the trap precisely: a leftover plain-NTP pool source mixed in with the NTS ones, quietly able to steer the clock without authentication. The AI read the authdata and sources together to distinguish real NTS from fallback — tedious correlation I’m glad to delegate. But I still verified by re-running chronyc authdata myself and removing the unauthenticated source. The model audits; I confirm the clock is actually protected.

Don’t forget the local clock discipline

NTS secures where time comes from; you still want sane local discipline:

# Confirm the clock is well-disciplined, not just authenticated
chronyc tracking          # offset should be tiny, leap status normal

# Step large initial offsets but slew small ongoing ones
# (makestep 1.0 3 in config: step if offset > 1s, only first 3 updates)

A securely-sourced but wildly-drifting clock still breaks Kerberos. Authentication and accuracy are separate properties; you want both.

The takeaway

Time is a security dependency hiding in plain sight, and plain NTP leaves it unauthenticated — which means anyone who can touch your time traffic can break TLS, Kerberos, logs, and TOTP by moving your clock. chrony with NTS closes that gap with a tiny config change: add nts to your sources, open TCP/4460, keep your CA store healthy, and verify with chronyc authdata. The new failure modes (blocked NTS-KE port, CA trust gaps, the bootstrap-skew paradox) are worth understanding up front. AI is a strong reviewer for confirming NTS is genuinely in force rather than silently falling back, but you verify the authenticated state yourself and remove any plain-NTP source that sneaks in. Authenticate the time, then confirm it.

For related ground, see keeping Linux clocks in sync with chrony and NTP and managing the CA trust store that NTS depends on. The chrony / NTP time sync troubleshooting prompt is a good companion when sync misbehaves.