Slashdot Mirror
OpenBSD Releases a Portable Version of OpenNTPD
Noryungi (70322) writes Theo De Raadt roundly criticized NTP due to its recent security advisories, and pointed out that OpenBSD OpenNTPD was not vulnerable. However, it also had not been made portable to other OS in a long time. Brent Cook, also known for his work on the portable version of LibreSSL (OpenBSD cleanup and refactoring of OpenSSL) decided to take the matter in his own hands and released a new portable version of OpenNTPD. Everyone rejoice, compile and report issues!
I'm led to believe that the reason we're using ntpd and not any of the other is that, although they are fine for getting your home machine to approximately the right second, they are damn-near useless for anything that you want real time-keeping for.
So if you want to interact with stratum-1's or be a stratum-2, then you'll be using ntpd. And, en-masse, NTP is not something as simple as just clock-skewing. That throws lots of things out of kilter. Granted, you may think you don't care, but these things can come back to bite you if you make a hasty decision now.
When someone like the NTP pool project (that I run a couple of serverse on) come to me and tell me that ntpd isn't secure enough, and that OpenNTP is good enough , then maybe I'll go over to them. Fact is, I haven't heard anything along those lines.
There's a lot of maths behind getting your clocks in sync quickly without going backwards in time, or slowing to a crawl, or messing up timestamps a lot. It's not as simple as "let's just drag the users clock closer to the reference one constantly". ntpd does a LOT that other NTP servers don't, and a lot of that is important for anything that you want to rely on a timeserver for.
Sorry, but this is just blatant "Look at us, we run an NTP project that's secure" when actually it does less than 10% of what ntpd does. And to make it do what ntpd does, presumably will take years of work to secure.
There are various "rewrite" projects at the moment, but all known holes with ntpd are closed. Until there's a compelling reason to move, don't. And by the time there is, you'll find properly-written, full-featured NTP projects being offered.
Nobody's talking about sub-millisecond accuracy here either. We're just talking not cocking up the one thing you plug in an NTP server to get right - the time.
Like chrony.
I wouldn't recommend openntpd because it isn't an implementation of ntp
Hey, speak for yourself! I wrote a secure "hello world" once....
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
ntp is surprisingly complex to deal with a surprisingly complex thing. If tlsdate was a decent enough utility, then we'd still be using the time protocol of rdate as the go-to time sync strategy. Precision and quality is much lower.
There's also a couple of tricky things. One is that it could be dropped in TLS 1.3. Another is that it doesn't play with the concept of TLS certificate expiry.
Basically, this is a potentially handy utility to take the place of rdate, not something that begins to touch ntp.
XML is like violence. If it doesn't solve the problem, use more.
I wrote a super secure interactive hello world once, so the user could see "hello world" in any language of their choice:
int main (int argc, char **argv) {
char hello[256];
gets(hello);
printf("%s\n", hello);
return 0;
}
Works best when run with root permissions. :)
I want peace on earth and goodwill toward man.
We are the United States Government! We don't do that sort of thing.
imo, when you go for that last nanosecond of accuracy as the highest priority
That's kind of the whole point of a timeserver. If you're just running a typical client that doesn't need precision there are a multitude of SNTP implementations that you can use, including the one built into Windows. If you're running something that demands precision or wish to share your time with others (random plug: NTP Pool) you're going to need a little bit more accuracy than that.
and lower the priority of writing secure software to the point where it is no longer a priority, then you have ntp.
ntpd has been around since the 80s. Contrast it against other system daemons that have been around that long (sendmail) and you'll see that it has a solid security record. The recent "exploits" only impacted a small subset of servers that were using the cryptographic functionality of ntpd, which is primarily used for remote management and peering relationships and was a non-issue for the lion's share of configurations. Configurations to work around the issues were released immediately and a patch to solve them entirely was available within days. What more do you want? This was all discussed on the NTP Pool mailing lists and the consensus was "meh." I'm not aware of any NTP server that has been compromised because of these exploits.
The biggest issue that's hit ntpd in the last year was the ease with which you could use the 'monlist' command for amplification attacks. This too was easily solved with a configuration change and in any event did not compromise the integrity of the servers running ntpd. It's symbolic of a larger problem that has hit other protocols (DNS) and which will never go entirely away until network operators get off their lazy asses and implement the recommendations of BCP38.
I want peace on earth and goodwill toward man.
We are the United States Government! We don't do that sort of thing.