5 ms·
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 attac
by hannob 12y ago
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.
- NoMoreNicksLeft 12y agoI 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?
- Ricapar 12y agoThere 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.
- dvanduzer 12y agoThe 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.
- cbsmith 12y ago> 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).
- dvanduzer 12y agoThe 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.
- cbsmith 12y agoIf 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).
- tedunangst 12y agoI 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?
- cbsmith 12y agoBecause 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.
- dvanduzer 12y agoYou'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.
- cbsmith 12y agoMaybe I wasn't clear, but I was thinking one would manipulate the delta specifically to cause the machine to adjust its clock.
- cbsmith 12y agoIt'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).
- BreaXerox 12y agoAccurate time is pretty important to computers. An attacker that can skew time can bypass HSTS, expire cookies, etc.
- agwa 12y agoYou 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.
- tedunangst 12y agoPretty persistent attacker. It should take something like 100 days to push the clock off by one day.
- dvanduzer 12y agoThis 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.
- xorcist 12y agoFor 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.
- dfc 12y agontp 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 http://www.nist.gov/pml/div688/grp40/auth-ntp.cfm or https://www.nrc-cnrc.gc.ca/eng/solutions/advisory/calibration/time_frequency.html#authenticated 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.
- FireBeyond 12y agoYou 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...)
- dfc 12y agoYou 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 http://www.nist.gov/pml/div688/grp40/auth-ntp.cfm [2]: https://www.nrc-cnrc.gc.ca/eng/solutions/advisory/calibration/time_frequency.html#authenticated https://www.nrc-cnrc.gc.ca/eng/solutions/advisory/calibratio...
- FireBeyond 12y agoWell, 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).
- cbsmith 12y agoActually, NTP has (limited) support for authentication and encryption. I would agree it's pretty lame though.
- uaygsfdbzf 12y agoYour article about that: https://blog.hboeck.de/archives/863-Dont-update-NTP-stop-using-it.html https://blog.hboeck.de/archives/863-Dont-update-NTP-stop-usi...