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.
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?
Accurate time is pretty important to computers. An attacker that can skew time can bypass HSTS, expire cookies, etc.
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.
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.
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.
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?
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.
PHK has been working on a rewrite of ntp sponsored by the Linux Foundation. He has posted a couple of entries about his progress so far: http://phk.freebsd.dk/time/20140926.html In the meantime Miroslav's chrony is a good alternative: http://chrony.tuxfamily.org/ If you are looking for the fixed version you can grab 4.2.8 from archive.ntp.org which is still responding to requests: http://archive.ntp.org/ntp4/ntp-4.2/…
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.
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 P…
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...)
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.
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?
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.
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.
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?
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?
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.
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.