Securing Network Time | Hacker News Reader

Securing Network Time

coreinfrastructure.org

77 pointsjwilk14 comments

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

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).

The mail says:

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.

Do any HTTP servers lie in the Date header? That would be weird.

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

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.

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!

Early releases of Chrony go as far back as 2006 [0] so the original codebase predates Rust, Go, etc.

0: https://git.tuxfamily.org/chrony/chrony.git/tag/?h=1.20

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

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

I'll add sqlite too, and also, cough, seL4. The latter is cough "secure due to being written in C" cough.....

Same here. So what is chrony doing differently? Is it just that the developer(s) are really clever, or are they using static analysis, or a better coding standard, or what?

This is important. We don't often get the chance to compare side-by-side implementations of the same requirement, so when big differences turn up we need to understand why.

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

Did you read the article at all?

Would you mind following the site guidelines when commenting here? 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.

Reply on news.ycombinator.com