
Securing Network Time - jwilk
https://www.coreinfrastructure.org/news/blogs/2017/09/securing-network-time
======
jlgaddis
Chrony doesn't have all the bells and whistles that ntpd does but it does have
all of the features that 99% of users will need. I've been running ntpd for
many, many years and, due to inertia (and, sometimes, device support), have
just stuck with it. I've started using Chrony since it started shipping on
RHEL by default, though, and it's an excellent replacement.

OpenNTPD has one feature, in particular, that I'd love to see supported in
Chrony: "authenticated TLS constraints" [0].

> _" Time can also be fetched from TLS HTTPS servers to reduce the impact of
> unauthenticated NTP man-in-the-middle attacks."_

In my testing, OpenNTPD wasn't nearly as accurate as Chrony or ntpd --
although I believe it wasn't really intended to be. Instead, if memory serves,
it was designed to be a more secure replacement that was "good enough" for
most uses.

[0]: [https://marc.info/?l=openbsd-
tech&m=142356166731390&w=2](https://marc.info/?l=openbsd-
tech&m=142356166731390&w=2)

~~~
xyzzy_plugh
We originally considered using times from TLS but many HTTP servers randomize
the times. It was common enough, and likely to become more common, to be
unreliable to us. In some cases, potentially dangerous (if times provided
allow for using expired certificates).

~~~
jlgaddis
As pointed out by _jwilk_ , this comes from the "Date:" HTTP header, _NOT_ the
TLS timestamp. To clarify, they aren't intended to be exact or high-precision,
like NTP timestamps. They are simply meant to give the NTP client some
confidence that the (unauthenticated) timestamps being received from NTP
servers/peers are accurate (and not being manipulated by an attacker).

OpenNTPD supports both the singular and plural versions [0] of the directive
and they operate in the same fashion as chrony's "server" and "pool"
directives do (i.e. single vs. multiple hosts). With several such sources
configured, outliers here can also be easily detected.

Personally, I use several sources across many different organizations (U.S.
government, U.S. tech companies, foreign entities, and my own servers) and it
gives me much more confidence that an attacker can't manipulate the time on
any of the hosts under my control.

Please do reconsider adding this feature! If you'd like, I'd be more than
happy to open a bug/file a feature request/whatever.

[0]: [https://man.openbsd.org/ntpd.conf](https://man.openbsd.org/ntpd.conf)

~~~
xyzzy_plugh
This is a good point. There is a bit of a chicken-egg issue if the system time
is set improperly such that you can't perform a secure TLS handshake. The
issue we were concerned with is factory resets (say you resold the appliance
or had issues) would accept old certificates. Malicious actors could use a
brief window to exploit the system and perform permanent modifications that
could withstand factory resets.

IoT is especially scary, since often the first authority is a local Wi-Fi
network. Users can easily be deceived to configure the wrong network, and
become exploited. Additionally, users can easily exploit system clocks in many
products to install custom firmware which, when resold or returned may then be
passed on to other users. Does Amazon reflash all consumer electronics that
are returned?

Lastly, we decided to use a combination of HTTPS, certificate pinning, and
client certificates to fetch a remote timestamp. We also use other, signed
timestamps when available, but permanently record the most accurate time we
suspect we have received. Devices cannot rewind prior to this, so if you have
a device that has been offline for four or five years, you may be vulnerable,
but chances are you are very vulnerable at that point anyways. If your device
connects at least once a year, you should be good. Most devices connect
constantly throughout the day.

------
eadmund
Interestingly, chrony is C. I thought for sure it'd be a more modern, safer
language — but no, this level of code quality is clearly _possible_ in C. I'm
honestly surprised. Congratulations to the author, though!

~~~
xorcist
There are other high quality C codebases, vsftpd, postfix, dovecot come to
mind, maybe openssh nowadays.

~~~
zimpenfish
Most of djb's stuff comes to mind as well.

------
speps
No author name and sounds like a PR article for Chrony. That's 2 red flags
there.

~~~
ibotty
Did you read the article at all?

~~~
dang
Would you mind following the site guidelines when commenting here?
[https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)

They ask you not to do the "did you read" trope. What would be particularly
better is if you explained, instead, what the commenter missed in the article.
Then we all learn something.

