Lion Cipher Lab
Keep your clock honest: NTP, UTC, and why a wrong clock breaks security
- Foundations
- Beginner
- ~45 min
- Free · no account required
Why it matters
Almost every security control you will ever touch quietly assumes your computer knows what time it is. A TLS certificate is only valid between two timestamps. A Kerberos ticket is refused if your clock is more than about five minutes off the server's. A one-time code from an authenticator app is derived from the current 30-second window. A forensic timeline that stitches together logs from four machines is worthless if one of them is forty minutes fast — the incident will look like it started on the wrong box. And yet the clock is the one dependency nobody teaches, because it appears to look…
What you'll learn
- time synchronisation fundamentals (NTP)
- reading timedatectl output line by line
- UTC vs local time vs the hardware clock (RTC)
- chrony and chronyc (tracking, sources)
- diagnosing clock skew failures in TLS and Kerberos
- RFC 3339 / ISO 8601 timestamps for log correlation
- recognising NTS and NTP amplification risk
Steps in this lab
- Three different "times", and why your computer keeps all of them
- Read every line of `timedatectl` — the whole status in one command
- `date` versus `date -u`, and the one timestamp format that never lies
- The hardware clock — and the classic dual-boot trap
- Set your time zone — and why servers are deliberately left on UTC
- What NTP actually does: four timestamps, offset and delay
- Stratum — and why a lower number is not automatically better for you
- systemd-timesyncd versus chrony: which you already have, and which you'd want
- Install chrony and read `chronyc tracking` field by field
- `chronyc sources -v`: see exactly who you are trusting
- The Windows side: `w32tm /query /status`
- Break it on purpose: watch a valid TLS certificate fail
- The security payload: skew, timelines, NTS, and a hostile DHCP server
- The judgment: when NOT to run your own time server, and what a pro actually does