LWN: Comments on "A security review of three NTP implementations"

original article url dead; providing link from wayback machine

salewski — Mon, 22 Jul 2024 14:59:20 +0000

Here's a link to the original article in the Internet Archive's "Wayback Machine":

"Securing Network Time"
Date published: 2017-09-27
https://web.archive.org/web/20171028123642/https://www.co...

The original article at:

https://www.coreinfrastructure.org/news/blogs/2017/09/sec...

is no longer available. The site redirects to a 404 at openssf.org ("Open Source Security Foundation"), and rummaging around the "Blogs & Resources" there, looks like their content only goes back to October 2020. I don't know if that site actually has any connection to the original 'coreinfrastructure.org' other than owning the domain name.

openntpd.org

jch — Thu, 12 Oct 2017 21:16:05 +0000

Last time I checked, OpenNTPd violated the protocol in ways that may cause synchronisation loops (which might in principle lead to desynchronisation of the whole network, not just of the machine running OpenNTPd). I recommend you avoid it.

A security review of three NTP implementations

kjp — Fri, 06 Oct 2017 23:52:27 +0000

nevermind, it appears "smear" isn't what I want, it's "leapsecmode slew" on a client, so time doesn't jump backward. Does that actually work for a normal client, e.g. in ec2?

A security review of three NTP implementations

kjp — Fri, 06 Oct 2017 23:45:56 +0000

So still no way for us people "just running clients" to have smeared leap seconds? :(

A security review of three NTP implementations

dskoll — Thu, 05 Oct 2017 11:52:10 +0000

This was a very interesting article. I replaced the standard ntpd with chrony on a large number of machines. Not only was it easy to set up, it also seems to lock onto the time references faster than ntpd. Thanks for this!

A security review of three NTP implementations

nkiesel — Thu, 05 Oct 2017 00:59:26 +0000

Of course we also have systemd-timesyncd these days which promises even simpler "keep my local clock in sync".

openntpd.org

rsidd — Tue, 03 Oct 2017 06:26:23 +0000

Just a nitpick -- OpenNTPD is not a fork, it's a reimplementation like chrony.

A security review of three NTP implementations

gerv — Tue, 03 Oct 2017 04:55:42 +0000

Just to set the record straight: Mozilla's SOS Fund commissioned and paid for the audits of ntp and ntpsec. We also ran the audit for chrony, although it was paid for by CII.

A security review of three NTP implementations

zdzichu — Mon, 02 Oct 2017 15:58:44 +0000

Chrony supports KVM's paravirtualized PTP clock, which gives pretty good accuracy.

A security review of three NTP implementations

smurf — Mon, 02 Oct 2017 15:34:26 +0000

Just checked out the Chrony sources and had a look.

This is one of the most well-commented and -assertion-sprinkled code bases I have seen lately. Exemplary.

A security review of three NTP implementations

SEJeff — Mon, 02 Oct 2017 15:15:58 +0000

The most obvious reasons chrony is more secure is its apparent simplicity compared to the legacy mess that is ntpd riddled with ancient landmines and old coding standards. It is one of the reasons they mention security reasons to using chrony in the RHEL7 documentation:

https://access.redhat.com/documentation/en-us/red_hat_ent...

A security review of three NTP implementations

cyperpunks — Mon, 02 Oct 2017 07:46:01 +0000

Chrony also seems to work way better than ntpd in VMs (for some reason).

A security review of three NTP implementations

zblaxell — Mon, 02 Oct 2017 04:48:46 +0000

Thanks! I somehow missed that in a forest of not-quite-relevant links.

So TL;DR Chrony has no broadcast/multicast, Autokey, or symmetric ephemeral modes (and at least two of those you don't want anyway). There's different NTP clock driver architecture (clock drivers talk to the server through a socket instead of being built into the server). The query interface is different, both on the network (separate port for queries) and admin tools (but not difficult to adapt--I flipped a couple of servers since reading the parent article).

OTOH Chrony boasts better statistical filters (which compensate for the lack of a clustering algorithm?), better power-saving behavior, better DNS pool behavior, and better tolerance for assorted network problems compared to ntpd and openntpd.

A security review of three NTP implementations

fest3er — Mon, 02 Oct 2017 02:24:50 +0000

https://chrony.tuxfamily.org/comparison.html

openntpd.org

josh — Mon, 02 Oct 2017 02:11:35 +0000

Likewise. I don't know about chrony, and this report is encouraging, but I personally used to use OpenNTPD myself, back when I ran a full NTP daemon and not just an SNTP client.

openntpd.org

karkhaz — Sun, 01 Oct 2017 23:36:37 +0000

Yes, when I saw the headline I was really hoping that the third implementation to be tested would be OpenNTPD. They're using the same development model as OpenSSH (whereby main development is targeted at OpenBSD, and a different developer patches it to create the 'portable' version), which comes with all of the pros and cons that this model entails. I've been using OpenNTPD on my (Linux) boxes, very happy with it.

A security review of three NTP implementations

zblaxell — Sun, 01 Oct 2017 23:36:19 +0000

What are these "not every single option in the NTP specification" options that distinguish NTP servers? Autokey? Obscure MAC formats? Missing data fields? Rate tracking and request limiting?

My Google-fu can't find a concise list. Anything worth the extra exposure?

openntpd.org

cornelio — Sun, 01 Oct 2017 23:15:24 +0000

FWIW, OpenBSD has its own fork.