Lion Cipher Lab
Keep your clock honest, Part 2: authenticate your time source with NTS in chrony
- Cyber / Security Engineer
- Intermediate
- ~75 min
- Free · no account required
Why it matters
In Part 1 you saw that a wrong clock breaks TLS, Kerberos, one-time codes and forensic timelines. The uncomfortable follow-up is that classic NTP lets anyone on the network path decide what your clock says: the replies carry no proof of who sent them or whether they were altered. An attacker on hotel Wi-Fi, a compromised router or a rogue DHCP server can push a machine an hour forward or two days back, and every control that trusts the clock trusts the attacker. Network Time Security (NTS) is the fix, and chrony already speaks it. This lab gets you from never having heard of NTS to running an…
What you'll learn
- explaining why plain NTP is unauthenticated and what an on-path attacker can do with that: in the lab's simulation, rewriting every reply moved a four-source client by +3599.999 s
- describing Network Time Security (RFC 8915) end to end: NTS-KE over TLS on TCP port 4460 hands out keys and cookies, then every NTP packet on UDP 123 carries authenticated extension fields
- configuring chrony as an NTS client of public servers (time.cloudflare.com, nts.netnod.se) with authselectmode require and minsources, inside a throwaway Debian container
- reading `chronyc -N authdata` (Mode, KeyID, Atmp, NAK, Cook) alongside `chronyc -N sources` and `chronyc tracking` to prove a source is really authenticated
- running your own NTS server in Docker with a private CA (ntsserverkey, ntsservercert, ntsport) and a client that trusts it through ntstrustedcerts, then proving the trust is real by removing the CA
- naming what NTS does NOT protect against: an authenticated server that is simply wrong, delay attacks, the certificate-time bootstrap problem (nocerttimecheck), and silent fallback when unauthenticated sources are allowed
- turning a clock error into concrete breakage: which certificates fail, when Kerberos refuses (300 s), when a TOTP code stops working, when a log timeline flips
Steps in this lab
- Recap Part 1 in one minute, and what this lab adds
- Why plain NTP can be forged, and why that is a security problem
- How NTS works: a TLS handshake once, then authenticated NTP packets
- Set up a throwaway Debian container with chrony
- Be an NTS client of two public servers, and read `chronyc -N authdata`
- Simulate a blocked port 4460 and see how NTS fails
- Run your own NTS server with a private certificate authority
- Point a client at your server, then prove the trust is real
- Measure what an attacker gains, with and without NTS (a simulation)
- Read the results: the before-and-after
- Honest negatives: what NTS does not stop
- The judgment: when to use NTS, when not to, and how a pro deploys it