Time Is Running Out for NTP | Hacker News Reader

Time Is Running Out for NTP

infoworld.com

111 pointsmistertrotsky31 comments

Article doesn't bother to mention that there are completely different projects which implement NTP servers with varying levels of functionality (openntpd, chrony, ntpsec, ntimed). And while the pool.ntp.org system is a nice scheme, it's hardly a global necessity. You can fairly easily get a stratum 1 server going on your own infrastructure. IMHO, too much of NTP relies on GPS, but that's a separate matter.

> IMHO, too much of NTP relies on GPS, but that's a separate matter.

I'm curious to know more. Can you please elaborate or point to some articles discussing this?

https://ntpserver.wordpress.com/2008/09/10/ntp-server-stratu...

http://www.ntp.org/ntpfaq/NTP-s-refclk.htm

TL;DR Most NTP networks are relying on GPS versus a high precision on-site time keeping device. Break GPS, and you break timekeeping for a wide swath of the worldwide NTP pool. But thems the breaks when you can get access to atomic clocks in space (each GPS satellite carries an atomic clock on board) just by sticking an antenna out the window.

If you require precision time for critical business operations (financial transactions, global database operations), you should be running a precision time source locally at your datacenter; for under $20 an attacker could deny you GPS timing.

If anyone is wondering: yes, you can own your very own atomic clock for a "reasonable" price! I encourage everyone to read [0] where a father takes his kids and a few atomic clocks up a mountain and back down. By looking at the clock drift due to changes in gravity, he was able to observe relativity!

[0]: http://leapsecond.com/great2005/

> If anyone is wondering: yes, you can own your very own atomic clock for a "reasonable" price!

Just to clarify, the clocks used to demonstrate gravitational time dilation were on the order of $10,000 (or more, e.g., [0]). But one can find rubidium standards online for a few hundred dollars.

[0] http://www.ebay.com/itm/HP-5061B-Cesium-Beam-Frequency-Stand...

To add to this, you can buy GPS time source dongles really cheap and in Linux it's not too hard to run one as a parallel/backup time source.

Especially when using distributed databases where write priority is determined by timestamp, someone wrecking havoc with your time source could bring down the database

Thanks, but the articles you link don't really describe what I was asking about (and the "TL;DR" doesn't appear to be actually derived from those in an obvious way). I know about the strata and the use of GPS as stratum 0 clocks.

I was interested in more details about why GPS is dangerous (i.e., more about "breaking GPS"). I get that a cheap jamming attack can disrupt a single NTP server/location. But it isn't obvious that that leads to widespread use of GPS being a bad thing for NTP pools. Because it would require a widespread (near-simultaneous?) jamming for several hundred physical locations to bring down a large chunk of the pool in that way. Of course, somehow corrupting the global GPS signal would be an issue, but how would that happen?

There was an interesting presentation at Kiwicon (a New Zealand security conference) the other day; someone demonstrated mimicing a GPS radio to trigger NTP drift in servers. The upshot was that it wasn't difficult, and gave you an avenue to replaying TOTP/2fa tokens...

Were they properly setup? Generally you want a local time source (GPS), the local CPU clock, and of course anyone you peer with (ideally 2 other peers on site) and of course your servers (ideally 3 as separate as possible from each other).

So the way it's supposed to work is that NTP models the error in all the above services and noticed when a source deviates. So if someone screws with the local GPS you should ignore it, and do the best you can with the remaining sources.

If you trigger NTP drift with a single source something is wrong with the setup.

A side-effect of a 4+ satellite fix is both extremely accurate and extremely precise computation of current time (in addition to location). (GPS sats broadcast time, receivers triangulate.) Some high-quality receivers (Trimble, probably others) attempt to count the number of pseudowavelengths back to the satellite, including relativistic, gravimetric and atmospheric effects. http://www.trimble.com/gps_tutorial/sub_phases.aspx

Thanks, but I was asking why heavy use of GPS in NTP pools was a bad thing, rather than how GPS can be used to determine a reference time (I'm aware of the use of GPS as a stratum 0 clock).

I thought NTP was a protocol, not a piece of software. Is the article conflating them, or is there only one single implementation of it that everyone relies upon?

There's OpenNTPD which is maintained by the OpenBSD/OpenSSH developers. It has been poorly criticized for its focus on security rather than absolute precision, but it's more than adequate for most peoples timekeeping needs.

http://www.openntpd.org/

It has privilege separation, sandboxing and if your OS/distribution uses LibreSSL it implements HTTPS constraints.

http://man.openbsd.org/ntpd.conf.5

http://man.openbsd.org/ntpd.8

http://man.openbsd.org/ntpctl.8

it's more than adequate for most peoples timekeeping needs

Yes it is. I'm on a cable modem and currently using OpenNTPD to talk to 5 NTP servers. My largest offset is currently 3.6 milliseconds. That's fine for general purpose computing. Anyone who needs better should probably buy some NTP or PTP hardware for his LAN.

There is NTP the protocol[1], and there is NTP the implementation[2].

While the implementation is popular, there are alternatives. There is also OpenNTPd, chrony and ntimed for instance.

There are also alternatives to the NTP protocol too, such as PTP and SNTP.

[1]https://www.ietf.org/rfc/rfc5905.txt [2]http://www.ntp.org/

Don't forget the billion-plus machines out there running Windows Time Service (which strangely has had zero security issues I can remember, even when running in server mode).

W32Time has different kinds of issues, in my experience. With it, one's problems tend to be that, by design until very recently, it doesn't provide to-the-second accuracy.

* https://blogs.technet.microsoft.com/askds/2007/10/23/high-ac...

* https://greyware.com/software/domaintime/v5/overview/w32time...

* https://technet.microsoft.com/en-gb/windows-server-docs/iden...

... and TAICLOCK.

* http://cr.yp.to/proto/taiclock.txt

If you care that much about accuracy you should take a look at https://en.wikipedia.org/wiki/Precision_Time_Protocol ... "IEEE 1588 is designed for local systems requiring accuracies beyond those attainable using NTP".

Surprised that the whole piece didn't mention roughtime, a timesetting protocol developed by Adam Langley with much better security properties (NTP basically has no security): https://www.imperialviolet.org/2016/09/19/roughtime.html

> NTP is buried so deeply in the infrastructure that practically everyone reaps the project’s benefits for free.

The most common embedded NTP implementation is probably busybox, being used on Linux routers/modems/etc.. is actually based on OpenNTPD.

https://git.busybox.net/busybox/tree/networking/ntpd.c

why dont dns servers provide this capability? seems like they are the most centralized of all the online services.

The problem isn't the service being provided, that's well handled. The problem is that the development team is woefully underfunded, incapable of keeping up with maintenance, security fixes, new design, documentation, testing, etc.

DNS is cached aggressively. As in, there is no "do not ever cache this" flag really. And even if there was, it there are multiple solutions actively ignoring the TTL hints. And caching is one thing you do not want when asking for time.

Separation of concerns.

The alternatives are most certainly as much underfounded as the mentioned project.

Classic NTP is hardly the only game in town. For example, see the NTPsec work in progress: https://www.ntpsec.org/ which I'll probably transition to someday, maybe even get an el-cheapo GPS receiver now that I'm not effectively living in a basement.

And I've personally be using chrony for a while, although my needs are significantly less than whatever level of accuracy it provides. There are some other clients out there as well, such as OpenBSD's OpenNTPD, although I have a vague memory of it having issues of precision, congruent with the distribution's focus on security.

My biggest issue with NTP is little control over who runs the servers. Unlike the CA system that has checks in place against bad actors, practically anyone can run an NTP pool.

It was discovered a while ago for example that some part of the Linux default NTP servers are run by shodan. So when your machine gets the time it lets shodan know you've got a server running so they can port scan you.

It would be stupid not to run a bunch of NTP servers if you wanted a to run a bot net. A free list of every running Linux server and countless IoT devices! Without having to actively scan IP space at all

NTP is more analogous to an SMTP server, HTTP server or any of the other myriad servers anyone can run on the internet with absolutely no vetting. The CA system is something different entirely. If you're confident that an NTP server is safe, don't use it. The same you would do with a potentially malicious website.

NTP is hierarchical. If you run a large organization generally you run a few NTP servers that talk to the internet. Then you setup your local nodes to talk to your NTP servers.

So it's hardly "a list of every running linux server".

Hmm does ntpsec only test their website with Chrome? Firefox says "Secure Connection Failed ... The OCSP server suggests trying again later." I guess that's one of the reasons Chrome TLS devs say online (looked-up on-demand) certificate revocation is useless.

Reply on news.ycombinator.com