Hi!

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.

Related commit:
http://marc.info/?l=openbsd-cvs&m=142355043928397&w=2

Have fun with catching the "outliars"!

Reyk

Reply via email to