Time is a hidden dependency of almost every security protocol. TLS certificate validity windows. TOTP one-time passwords, which are only valid within a 30-second window. Kerberos tickets, which have explicit time bounds. OAuth tokens with issued-at and expires-at claims. DNSSEC signature validity periods. The correctness of all of these depends on the participating machines agreeing on what time it is — within a reasonable tolerance.
The Network Time Protocol (NTP) has kept the internet's clocks synchronized since 1985. It works well enough that most users never think about it. What most users also don't know is that standard NTP operates over UDP, with no authentication of the time source by default. A machine-in-the-middle that can intercept NTP packets can tell your device that it's any time it wants.
How NTP Time Spoofing Enables Other Attacks
NTP spoofing is rarely an end in itself — it's a stepping stone. Here are the attack chains it enables:
TLS certificate rollback. A TLS certificate has a notBefore and notAfter field. A certificate that was valid in 2022 but has since expired cannot normally be used to establish a TLS connection — your browser or library will reject it. But if an attacker can convince your device that the current date is 2022, the expired certificate is suddenly valid again. This is useful if the attacker has already obtained a legitimate (but now-expired) certificate for a domain through any means.
TOTP defeat. Time-based one-time passwords (RFC 6238) generate a new code every 30 seconds, derived from the shared secret and the current Unix timestamp divided into 30-second buckets. If an attacker can shift your device's clock by 30 seconds, the TOTP code you generate won't match what the server expects — an effective denial of service against your MFA. If the attacker can instead shift the server's clock, any code from the corresponding 30-second window on the manipulated timeline becomes valid.
Replay window expansion. Many protocols include timestamps specifically to prevent replay attacks — a nonce that includes the time prevents replaying an old message because the timestamp will be outside the acceptable window. Manipulating time expands that window, making old captured messages valid again.
Standard NTP has historically been used for distributed denial-of-service attacks via amplification. An attacker sends a small NTP request (spoofing the source IP to the victim's address) to an NTP server that responds with a much larger payload. The monlist command, now disabled on modern NTP software, could amplify a request by a factor of several hundred. NTP amplification attacks remain possible with unpatched servers and are documented in attack toolkits. The NTS protocol defends against both spoofing and amplification.
NTS: Network Time Security (RFC 8915)
Network Time Security was published as RFC 8915 in September 2020 and provides authenticated NTP using the same cryptographic infrastructure as TLS. The protocol works in two phases:
- Key establishment: The client connects to an NTS Key Exchange (NTS-KE) server over TLS 1.3. The TLS handshake authenticates the server and negotiates session keys. The client receives cookies that encode keying material without the server having to maintain session state.
- Time exchange: The client sends NTP requests over UDP, attaching an NTS Authenticator Extension Field using the session keys from step 1. The server's response is authenticated with a Message Authentication Code. Neither party can be impersonated; the time information cannot be modified in transit without invalidating the MAC.
The separation of key exchange (TLS, over TCP) from time exchange (UDP) is intentional — it preserves NTP's low-latency, UDP-based time synchronization while adding cryptographic authentication. The cookies prevent the server from needing to track client sessions, which scales well.
Configuring NTS in Practice
Several major public time services now support NTS:
| Provider | NTS-KE Address | Notes |
|---|---|---|
| Cloudflare | time.cloudflare.com |
NTS supported since 2019; stratum 1 access |
| Netnod (Sweden) | nts.netnod.se |
Well-established European NTS provider |
| PTB (Germany) | ptbtime1.ptb.de |
Germany's national metrology institute; NTS on port 4460 |
| NIST | time.nist.gov |
NTS supported; US national time standard |
To use NTS, your NTP client must support it. The two main options on Linux are chrony (version 4.0+, released 2020) and ntpsec. The default systemd-timesyncd does not yet support NTS in most distributions' shipped versions, though support has been added upstream. A minimal chrony configuration for NTS looks like:
server time.cloudflare.com iburst nts
server nts.netnod.se iburst nts
makestep 1.0 3
rtcsync — Excerpt from /etc/chrony.conf with NTS enabled
On macOS, Apple's time synchronization service uses its own infrastructure; third-party NTS configuration is possible but not the default. On Windows, the built-in W32tm service does not support NTS; third-party tools (Meinberg NTP for Windows, Chrony for WSL) are alternatives.
Why This Matters More for Some Systems Than Others
Time integrity matters for every system, but the risk profile varies significantly by use case:
Desktop and mobile devices on public internet. Practical risk is low for typical users — NTP spoofing requires network position (being able to intercept or inject packets) that most attackers don't have. The threat is more relevant on public Wi-Fi or hostile network environments.
Servers with public network exposure. A server accepting TLS connections or issuing signed tokens has a higher stake in clock accuracy. An NTP spoof that corrupts a server's clock can potentially invalidate all sessions or expand replay windows for an extended period before anyone notices.
High-security cryptographic infrastructure. Hardware Security Modules (HSMs), Certificate Authorities, code-signing infrastructure, and systems issuing timestamped certificates have strict requirements for clock accuracy. Time manipulation against a CA's clock during certificate issuance could produce certificates with manipulated validity windows. These systems should use NTS or GPS-based time references with independent verification.
IoT and embedded devices. Many connected devices use NTP without authentication, have limited ability to be updated, and are often deployed in exposed network environments. They represent a large, largely unaddressed attack surface. A smart home device with a manipulated clock may accept expired TLS certificates from a rogue local server, enabling man-in-the-middle attacks against encrypted home network traffic.
Hardening Your Time Stack
A practical hardening checklist for systems where time integrity matters:
- Use chrony or ntpsec instead of ntpd on Linux servers; both have better security architectures and NTS support
- Configure at least two independent NTS-capable servers from different providers and geographic locations
- Enable chrony's
makestepdirective to allow large initial corrections, but disable it after initial synchronization to prevent large jumps from being accepted without scrutiny - Log time synchronization events — sudden large offsets are worth alerting on; they indicate either a compromised time source or a hardware clock failure
- For high-security infrastructure, use a GPS-disciplined clock or a hardware time server as your local reference and sync other machines from it internally, rather than relying on internet NTP
- Firewall NTP (UDP 123) so that only known time sources can respond to your NTP client's queries — prevents an attacker on the same network from injecting spoofed responses
Time security sits in an unusual category of infrastructure hardening — the risk is mostly invisible until an exploit occurs, the fix is straightforward (NTS is production-ready and well-supported), and the operational overhead is minimal. For systems where forward secrecy and certificate integrity matter, it's worth closing this attack surface entirely.