
Attacking the Network Time Protocol [pdf] - bootload
http://www.cs.bu.edu/~goldbe/papers/NTPattack.pdf
======
GauntletWizard
This is probably a good time to plug (or a release timed to coincide with) the
NTPSec project [1], which is approaching actual launch goals [2].

Time is incredibly important for security. As a wise man once said, you can't
hide secrets from the future [3]. You can only protect them with the best
crypto you currently have, and expire old secrets as they are no longer valid.
Kerberos, most OTP protocols, and SSL are all predicated on the two sides
having a consistent view of time. SSL Certs have an expiry, for reasons that
include that we expect their crypto to fail. Kerberos uses it among other
things to prevent and limit scope of replay attacks, as does the TOTP
protocol.

[1] [http://www.ntpsec.org/](http://www.ntpsec.org/) [2]
[https://plus.google.com/+EricRaymond/posts/WHQ4YMTy14U](https://plus.google.com/+EricRaymond/posts/WHQ4YMTy14U)
[3] [https://youtu.be/NK5WfcmeaUg](https://youtu.be/NK5WfcmeaUg)

~~~
nullc
The whole NTP protocol (and deployment practices of the public NTP
infrastructure and most private NTP deployments I've seen) is not terribly
compatible with strong security -- a better implementation can only go so far.

Fundamentally the NTP implementations work with very strong assumptions that
the servers they speak to are honest-- and even ignoring that the network
authentication parts are so unusable, well-- that they make PGP/GPG look like
a iProduct by comparison, this assumption just isn't a good one because it
makes the security very brittle.

Look no further than the widespread false leapsecond events in the last couple
years. If NTP gets bad data _by mistake_ can we really expect it to stand up
to an actual attack?

