3 ms·
OpenNTPD has implemented a clever mitigation to this problem. It relies on trusting various key sites such as Google. You put one or more lines like this into y
by PhantomGremlin 11y ago
OpenNTPD has implemented a clever mitigation to this problem. It relies on trusting various key sites such as Google. You put one or more lines like this into your configuration file:
constraints from "https://www.google.com/search?q=openntpd"
As the man page puts it:
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.
Of course, the devil is in the details. IIRC at the moment this check is only made when NTPD starts up, and not periodically during operation. But the general idea is probably quite solid.
- mlichvar 11y agoThe problem with this solution is that it's very expensive. Imagine couple hundreds of millions of computers making a TLS connection every few minutes. For NTP there is Autokey (RFC 5906), which allows authentication of the servers with public-key crypto. It has various problems, one of them is that it's insecure. The NTP working group is currently preparing a Network Time Security specification and its implementation in NTP, which is supposed to replace Autokey. https://datatracker.ietf.org/wg/ntp/documents/ https://datatracker.ietf.org/wg/ntp/documents/