On Tue, 3 Jul 2012 17:32:40 +0100 Kevin Chadwick <ma1l1ists@xxxxxxxxxxx> wrote: > > Watches are perfectly acceptable time keepers especially considering I > have a cheap watch stuffed in a drawer that I was surprised hasn't lost > seconds in years. RTC: I'm fairly sure many older ones don't even have > crystals but are probably still good enough, though I have no > accurate quantification yet. Noone cares about seconds -- we talk about a 10ns resolution. This is cool, especially if you consider the time scale on which the current propagates inside your motherboard. > > > > Like everything else ntpd has to be properly secured and configured, if > > properly done I suppose it isn't a bigger security problem than anything > > else with network access. This problem about the leap second and > > programs going awry is due to a bug in the kernel and not a problem with > > ntp itself, the only fault that can be attributed to ntp is to expose > > that bug. > > Attacker controlled or influenced time is actually more serious than > you would think for crypto, logging etc., which is why OpenBSD put so > much effort into it and don't allow the clock to go backwards. So do the > benefits of ntp outweigh the risk. I'm simply saying in most scenarios > no. While I respect OpenBSD, sometimes I think they create too much buzz around their "security". I have never seen a clear case when OpenNTPD was a winner security-wise (i.e. not after a default installation). Are you telling me that if my clock is in the future, openntpd is not going to adjust it backwards? This certainly happened to me across DST when my clock was on localtime. NTPD also does this, see man ntpd. As with any networking protocol, any NTPD implementation opens you to yet another attack vector -- yes. However, there are also countermeasures, see http://www.eecis.udel.edu/~mills/security.html. Have you seen the movie Entrapment (http://en.wikipedia.org/wiki/Entrapment_(film))? This is roughly how attacks over NTP can be carried out... > > I'm not saying ntp is at fault, however manually setting the date fixes > this problem. So the easiest and in my opinion best solution for > most users that wasn't put forward for most users is to disable ntp and > set the clock to mr atomic. > Again, RTCs are usually crap -- by design. My understanding that it's not the drift which troubles, it's the unpredictibility which renders them useless for event coordination. So if you want good timing you'll have to use ntpd because OpenNTPD is less accurate, has fewer features and is long unsupported on Linux. > -- Leonid Isaev GnuPG key: 0x164B5A6D Fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
Attachment:
signature.asc
Description: PGP signature
