OpenBSD Journal

s2k15: Authenticated TLS 'constraints' in ntpd(8)

Contributed by tbert on from the stuck-with-the-MitM-with-you dept.

Reyk Flöter (reyk@) wrote in to tech@, talking about some work he'd done at s2k15:

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

(Comments are closed)

Comments

  1. By Anonymous Coward (212.136.9.4) on

    The apple.com line should read 'constraints' too, right?

    Comments

    1. By Theo de Raadt (130.102.96.33) on

      > The apple.com line should read 'constraints' too, right?

      No. Like the server & servers keywords, there are constraint & constraint keywords. The singular selects one address. The plurals expand to all the addresses identified (by a DNS lookup or such).

      Comments

      1. By Anonymous Coward (212.136.9.4) on

        > > The apple.com line should read 'constraints' too, right?
        >
        > No. Like the server & servers keywords, there are constraint & constraint keywords. The singular selects one address. The plurals expand to all the addresses identified (by a DNS lookup or such).

        Just noticed that from the mail related to commit message, thanks for the clarification anyway.

    2. By reyk (130.102.96.33) on

      > The apple.com line should read 'constraints' too, right?

      No, as I mentioned on tech@ (http://marc.info/?l=openbsd-tech&m=142356742801119&w=2):

      "Yes, it is valid. As mentioned in the man page, it works like the existing server vs. servers for NTP peers.

      When a hostname or URL is specified, ntpd(8) will resolve the host. The singular version will use only one of the returned IP addresses and the plural version will use it as a pool and use all of the returned IP addresses.

      Following the example, a "dig A" on www.google.com or www.apple.com will typically show you a number of addresses, while the Akamai-hosted www.apple.com only returns one address near you. You're free to use any host, and some people might prefer to use their own trusted servers, I just picked some examples with good availability and seemingly good time."

  2. By Anonymous Coward (2601:6:5182:4595:e5af:b6bd:5833:2d49) on

    A simple yet very useful concept. Excellent!

  3. By Christian Neukirchen (138.246.2.57) chneukirchen@gmail.com on http://chneukirchen.org/

    Any reason this doesn't use the "Start Time" parameter from the SSL handshake?

    Comments

    1. By Gwyllion (83.101.69.36) on

      > Any reason this doesn't use the "Start Time" parameter from the SSL handshake?

      This is mentioned explicitly in the tech@ post:
      "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."

  4. By Anonymous Coward (209.181.89.124) on

    Shouldn't this be put into an RFC so this becomes a "thing", to avoid it being an OpenBSD-specific approach? This sounds like it isn't typically done for ntpd updates.

    Comments

    1. By phessler (phessler) on http://www.openbsdfoundation.org/donations.html

      > Shouldn't this be put into an RFC so this becomes a "thing", to avoid it being an OpenBSD-specific approach? This sounds like it isn't typically done for ntpd updates.

      For now, this is an experiment. If it turns out to be a useful experiment, an RFC will be considered.

    2. By henning (130.102.96.33) on

      > Shouldn't this be put into an RFC

      good luck with that process! let us know how it goes.

  5. By Martin Seener (2a02:8109:8000:14:b7:8824:4aeb:c6dd) on

    That's a very nice idea!

    Also why not adding the possibility on the NTP server side? I could not just serve the date via NTP but also via a super simple HTTPS/TLS only "webserver" on 443 or another port for direct verfification of the ntp responses. Because you know the RTT to a specific ntp server you can also better calculate the boundaries of the TLS response and you don't have to use a 3rd party HTTPS Server for this.

    And in this regard: Is it possible to do this? "constraints www.mydomain.com:8443" for example?

  6. By n1000 (2601:9:7d80:ced:301a:8984:b597:f395) natex84@gmail.com on

    Not trolling here, but what is the major advantage of doing this over just comparing the NTP server reported time vs the current local system time? Is it just protection against a slow migration of the time set by NTPD?

    Comments

    1. By n1000 (2601:9:7d80:ced:301a:8984:b597:f395) natex84@gmail.com on

      > Not trolling here, but what is the major advantage of doing this over just comparing the NTP server reported time vs the current local system time? Is it just protection against a slow migration of the time set by NTPD?

      "...hosts in your ntpd.conf that will be queried upon startup of ntpd."

      Ah, so this is just for the initial time setting, that makes more sense now... sorry for the spam.

Latest Articles

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]