Hacker News Reader

Comment by hannob | Hacker News Reader

The best solution is not to use ntp anyway. It's an unencrypted, unauthenticated protocol vulnerable to Man in the Middle attacks. There was a pretty neat attack presented at BH Europe circumventing HSTS with a MitM-attack on NTP.

Better just replace it with tlsdate.

View on HN

ntp network traffic can be authenticated with symetric keys or autokey currently, and with NTS in the future. Many national labs support authenticated time for free and even more provide authenticated ntp for a fee.[1] Moreover if you care about time you can use a cheap GPS+PPS[2] as a reference or splurge and get a CDMA card. Your "replace it with tlsdate" solution makes little sense; at some point you need NTP or PTP to acquire and synch to UTC.

Why would anyone need encrypted time synch? I do not understand the privacy implications, UTC is not a secret.

[1]: For example: http://www.nist.gov/pml/div688/grp40/auth-ntp.cfm or https://www.nrc-cnrc.gc.ca/eng/solutions/advisory/calibratio...

[2]: My sure gps puck cost $40. It works with the antenna sitting on the window ledge inside my house.

You need encrypted time sync when you don't have a local trusted source, and to reduce your susceptibility to to pseudo MITM attacks (though, having just said that, you're right - UTC isn't a secret, so an attacker could just use that. However, and I'm not sure the answer, the key may be in how much information is leaked to the NTP server on current clock drift state. That being said, I'm fairly sure Kerberos etc don't require millisecond level time sync...)

You are confusing authentication and encryption. Authenticated time protects against MITM attacks. You can obtain authenticated time synch from many national labs, such as NIST[1] or CRC[2].

I do not understand the need for confidentiality.

[1]: http://www.nist.gov/pml/div688/grp40/auth-ntp.cfm

[2]: https://www.nrc-cnrc.gc.ca/eng/solutions/advisory/calibratio...

Well, my thought was that you might be able to determine local clock drift by snooping. But as then mentioned, that's of near zero use, I suspect (as anything that uses time sync for authentication or otherwise is not likely to be that tightly bound to accuracy).

ntp authentication is broken: http://zero-entropy.de/autokey_analysis.pdf and it was the same guy who found the new vulnerabilities :-)

In order for the attack to succeed Eve needs to be able to MITM every configured ntp server association and do so before the daemon starts up.

FYI Stephen Röttger is also the same guy who is a co-author of the two IETF proposals for the successor to autokey; Network Time Security[1] and Crypto Message Syntax for NTS[2].

[1]: https://tools.ietf.org/html/draft-ietf-ntp-network-time-secu...

[2]: https://tools.ietf.org/html/draft-ietf-ntp-cms-for-nts-messa...

Encrypted might not be necessary but you want to be sure your computer is getting the right time. An out of sync Bitcoin miner for example will only produce invalid blocks. Tor I believe also relies on an accurate clock.

Bitcoin relies on more than NTP so it's not a huge vulnerability, but NTP's vulnerability is a headache to many security developers.

Your article about that:

https://blog.hboeck.de/archives/863-Dont-update-NTP-stop-usi...

I don't understand what attacks are possible... making an enemy late for work when his alarm goes off several hours late?

Or can you circumvent certificate revocations this way?

There is still a lot of crypto out there that works off of using the current timestamp as a seed.

Being able to control he time could theoretically let you control any PRNGs that rely on it.

The much bigger issue is with hardware that doesn't have a local clock/battery. Critical initialization code should probably compare uptime with current epoch time if it needs a random seed for a long-use token.

> The much bigger issue is with hardware that doesn't have a local clock/battery.

Ummm, no. NTP normally runs on machines that have a local clock/battery, but which need an established network clock anyway.

> Critical initialization code should probably compare uptime with current epoch time if it needs a random seed for a long-use token.

Using time as a random seed is probably a mistake in the first place. You could perhaps try to add entropy from a clock, but you'd want another source of entropy. Generally crypto code needs network clocks for other things (think of Kerberos ticket expiration).

The average longevity of a Kerberos ticket makes it the perfect example for this attack vector, actually.

Are you familiar with something other than NTP as a time source for devices without CMOS? I have a project that desperately needs crypto without a clock.

If you are really worried, use layer 3 or layer 2 security (say with IPSec) to secure NTP communications.

Yes, there is a bit of a bootstrapping problem, but you can address that with a bootstrapped handshake that sets a clock baseline.

Alternatively, you could just hardwire a radio receiver (like say... a GPS receiver).

I don't think I need to control your clock when I can just look at my watch and know what your clock says. Why do things the hard way?

Because any cryptographic implementation worth its salt wouldn't be using even second resolution time, so what your watch says is irrelevant. Also, if I cracked an NTP feed, I'd not use it to know what the server's clock is set to so much as to manipulate the server's clock to all kinds of wonderful effect.

You're misunderstanding the attack vector. The exploit is about precisely controlling the delta between a client and server.

There is no problem with using low-resolution time signatures as a cryptographic seed. Using time as an entropy source is only a problem if you sample at a lower resolution than your clock's error rate.

Maybe I wasn't clear, but I was thinking one would manipulate the delta specifically to cause the machine to adjust its clock.

It's more than that. There is tons of logic in crypto protocols around timeouts, and of course services themselves often have bugs around the handling of time (there's a great list of assumptions developers make about time that are fatal and create all kinds of security problems).

Accurate time is pretty important to computers. An attacker that can skew time can bypass HSTS, expire cookies, etc.

You could circumvent certificate revocations by replaying expired OCSP Staple responses that say a certificate is not revoked.

You could also cause expired certificates to be accepted, which limits the utility of short-lived certs as a means of protecting against key compromise.

And as hannob said, you can circumvent HSTS by setting the time in the future, causing all HSTS entries to be expired.

Pretty persistent attacker. It should take something like 100 days to push the clock off by one day.

Ubuntu accepts arbitrary time jumps, the attack was presented live at BH with an Ubuntu System.

so you can see Ubuntu so it is 03:14 UTC on 19 January 2038? That might be bad, how big is their time_t?

This kind of attack should be difficult, because NTP clients should be configured to ignore large offsets. See the (dangerous) -g option in the ntpd manpage, for example.

For that to work you need to compromise _all_ the NTP servers those servers sync to for an extended period of time (years). It's simply not a realistic attack.

NTP does not sync time. NTP measures time drift across groups of servers, and sprinkles in known time. I'm not saying authentication is useless, you should turn it on for your known time sources, but it's not so simple as you make it out to be.

Unless you use SNTP on your servers. Don't do that. Ever.

In practice, there are systems that use SNTP or regular NTP with periodic calls to ntpdate. Ubuntu does the latter, by default, and is thus susceptible to the attacks I described,

That's a bug with Ubuntu. That mode of operation is for devices without persistent real time clocks or personal laptops where time isn't that important. If you sync your time at reboots you will screw up ntpd's clock drift calculations.

Actually, NTP has (limited) support for authentication and encryption. I would agree it's pretty lame though.

Reply on news.ycombinator.com