Set a laptop’s clock forward two years and open any website. It won’t load. Not “loads with a warning” — the browser refuses, NET::ERR_CERT_DATE_INVALID, because every certificate on the machine is now expired according to a clock that’s lying. Set it back to 2010 and you get the mirror image: certificates that won’t be valid for years yet. The entire trust apparatus of HTTPS quietly assumes the machine knows what time it is, and the moment that assumption breaks, none of the cryptography helps you.
That’s the part I don’t think gets said often enough. We talk about certificate validation as if it were a math problem — signatures, chains, trusted roots. But baked into the middle of it is a comparison against notBefore and notAfter, two timestamps in the certificate, checked against the local clock. It’s not cryptography. It’s if (now > notAfter) reject. And now comes from somewhere.
What leans on the clock
Once you start looking, the clock is load-bearing in an uncomfortable number of places.
TLS certificates have a validity window, and that window is enforced against local time. HSTS is a promise with an expiry — max-age counts down against the clock, and a machine convinced it’s far in the future will decide the promise lapsed. DNSSEC signatures are worse: every RRSIG record carries an explicit inception and expiration time, and a validator whose clock is outside that window will reject perfectly good signatures as either not-yet-valid or expired. Kerberos tickets are time-bound and famously fall over when clocks drift more than five minutes. TOTP — the six-digit codes in your authenticator app — is literally a hash of the current 30-second time step; the whole scheme is “we both know what time it is.” JWTs expire on a timestamp. Log correlation across systems, the thing you rely on during an incident, assumes the timestamps mean the same thing on every box.
Strip the abstractions away and a lot of what we call “security” turns out to be an assertion about the current time, dressed up in signatures. Which raises the obvious question: where does a computer get the time, and how much do we trust that channel?
The trust-anyone protocol
The answer, for essentially every machine on the internet, is NTP — the Network Time Protocol, most recently specified as NTPv4 in RFC 5905. It’s one of the oldest protocols still in daily use, and it works beautifully: a hierarchy of servers, stratum 0 at the top (the actual atomic clocks and GPS receivers), each layer syncing from the one above, clever algorithms to filter out network jitter and settle on the true time to within milliseconds.
Here’s the thing nobody mentions. In its default, overwhelmingly common configuration, NTP is completely unauthenticated. Your machine sends a request for the time, and it believes the answer. It does not verify who sent it. There is no signature to check, no identity to confirm. Whoever’s packet arrives, saying “it’s 3:47:12,” gets believed. For a protocol that sits underneath certificate validation, HSTS, and DNSSEC, that is a remarkable amount of trust to place in an unsigned UDP packet.
For most of NTP’s life this was simply how it was, and mostly it didn’t matter, because mostly nobody was on the wire lying to you about the time. “Mostly” is doing a lot of work in that sentence.
Moving someone’s clock on purpose
In 2015, researchers at Boston University — Malhotra and colleagues — published a paper with the wonderfully blunt title Attacking the Network Time Protocol, and it laid out exactly what you can do to a target if you can control what time they think it is. The list is a tour of everything above. Shift a victim’s clock forward and you can expire certificates that are perfectly valid, or push them past an HSTS max-age so downgrade protections lapse. Shift it backward and you can un-expire things that were supposed to be dead — a certificate that was revoked or retired becomes “valid” again to a machine that thinks it’s still last year. Roll it far enough and DNSSEC signatures fall outside their validity window and validation collapses, which for a strict resolver means the names stop resolving at all.
And you didn’t have to break any cryptography to do it. You changed the one input every one of those checks silently depends on. A man-in-the-middle on the path can just answer the NTP request with a lie. The paper also showed off-path tricks — abusing IPv4 fragmentation, exploiting how NTP clients handle certain server responses — so you didn’t even strictly need to be sitting in the middle. The clock was the soft underbelly, and it had been sitting there, unauthenticated, the whole time.
Why did it stay that way for forty years? Not for lack of trying. NTP had an authentication scheme called Autokey (RFC 5906) that was, to put it kindly, not good — its design had cryptographic weaknesses serious enough that essentially nobody deployed it in anger. The other option, symmetric-key authentication, works but requires you and the time server to share a secret key beforehand, which is fine for a handful of machines in one organization and completely unworkable for public time servers serving millions of strangers. So the mechanism that would have secured NTP either didn’t work or didn’t scale, and the internet defaulted to trusting the packet.
The same protocol, pointed outward, as a weapon
There’s a second half to NTP’s security story, and it’s almost funny in a bleak way. The protocol that authenticated nothing also turned out to be one of the great DDoS amplifiers of the last decade.
Old NTP servers supported a diagnostic command called monlist that returned the last 600 addresses that had talked to the server. A tiny request, a huge response — and because NTP runs over UDP, you can spoof the source address so the huge response lands on your victim. That’s CVE-2013-5211, and in February 2014 it powered a reflection attack that hit around 400 Gbps, one of the largest seen at that point, built out of thousands of innocent misconfigured time servers. Amplification factors of a hundred-fold or more. The protocol keeping the internet’s clocks was briefly better known as a firehose.
monlist got disabled and the amplification problem faded, but it’s a useful reminder: time infrastructure is infrastructure, with all the attack surface that implies, and for a long time almost nobody treated it that way.
The fix exists. Guess how much it’s used.
There is now a real answer. Network Time Security — NTS, RFC 8915, published September 2020 — finally does the obvious thing: it bootstraps keys over TLS (so you get an authenticated channel to establish trust), then uses those keys to authenticate the actual NTP exchange with AEAD, all carried in NTP extension fields so it stays compatible with the existing protocol. Your machine can now check that the time came from the server it meant to ask and wasn’t tampered with in flight. Cloudflare runs a public NTS server at time.cloudflare.com; Netnod and others run them too. The clients exist — chrony and ntpsec support it.
You will be shocked to learn that adoption is a rounding error. Most operating systems still ship plain, unauthenticated NTP as the default. Most people have never heard of NTS. The secure option has been standardized and freely available for years, and the clock on the machine you’re reading this on is almost certainly still being set by a protocol that believes whoever answers. If this sounds like the DNSSEC story, or the MTA-STS story, or the OCSP story — a genuine fix sitting unused while the insecure default rolls on — that’s because it’s the same story. Security improvements that require someone to go change a working default mostly don’t happen.
The dependency nobody lists
Here’s what actually bothers me about it. We spent the last decade making everything lean harder on the clock. Certificate lifetimes keep shrinking — 398 days, then 200, headed toward 47 — precisely so that validity windows are tight and a leaked key stops mattering sooner. HSTS got stricter. DNSSEC signatures have inception and expiration baked in. Every one of those improvements assumes the machine knows what time it is. We tightened all the windows and left the thing that sets the window trusting an unsigned packet.
And it’s not only attackers. Time is fragile even when nobody’s trying. When a leap second was inserted at the end of June 2012, a bug in the Linux kernel’s timekeeping code — it forgot to tell the high-resolution timer subsystem the second had happened — sent CPUs into a spin, and servers at Reddit, Mozilla, LinkedIn, Foursquare, Yelp, and a pile of airline systems fell over simultaneously. Not attacked. Just told, correctly, that time had done something slightly unusual, and unable to cope. It’s why Google and others invented “leap smear,” spreading the extra second across a whole day so nothing ever sees a :60. It’s why the world’s metrologists voted in 2022 to abolish the leap second by 2035 — the safest fix for a decades-old source of outages was to stop doing the thing.
Put it on your threat model. Not because a clock attack is the likeliest thing that happens to you — it isn’t — but because the clock is the dependency underneath the dependencies, the one that doesn’t show up in the architecture diagram because it feels like a law of physics rather than a service someone provides over the network. It’s a service. It has been trusting strangers for forty years. And an alarming share of your security is really just a well-signed statement about what time it is.