Contributed by tbert on from the stuck-with-the-MitM-with-you dept.
Theo, Henning, and me developed an idea to utilize TLS in some way for authenticated time in ntpd(8). We are not intending to use it as a direct time source, but as a "constraint" to verify the NTP responses. I came up with an implementation that has been designed to be an optional, non-intrusive feature that is now part of OpenBSD -current.
From the ntpd.conf(5) man page: "ntpd(8) can be configured to query the `Date' from trusted HTTPS servers via TLS. This time information is not used for precision but acts as an authenticated constraint, thereby reducing the impact of unauthenticated NTP `Man-In-The-Middle' attacks. Received NTP packets with time information falling outside of a range near the constraint will be discarded and such NTP servers will be marked as invalid."
The standardized attempts to add authentication to NTP are a) fairly horrible (ASN.1 etc.) and b) rarely deployed. HTTPS is most widely deployed and provides a reference time in the Date: header. The resolution is not good enough as a time source, only seconds and it does not consider network and I/O delays, but it is good enough to provide bounds that can be used to verify the NTP responses. We only use the time from the HTTPS header, and not the TLS timestamp, as the latter is most possibly randomized in modern SSL/TLS implementations.
To test it, you can configure one or more HTTPS URLs or hosts in your ntpd.conf that will be queried upon startup of ntpd. Any HTTPS URL would work and the path is fully optional. The server certificate is currently verified against the CA certificates in /etc/ssl/cert.pem; a self-signed certificate would not work unless you add your own CA to the file.
---snip--- servers pool.ntp.org constraints from "https://www.google.com/search?q=openntpd" constraints from www.twitter.com constraint from www.apple.com ---snap---
The feature is still experimental and we're continuing to improve the semantics. But it is already fully functional and ready to be tested. The HTTPS client requests are executed in independent processes that are fully isolated from each other and from the NTP processes - a strict separation protects the daemon from any potential failures in the TLS execution.
Have fun with catching the "outliars"!
(Comments are closed)