> 2017-10-15 6:01 GMT+02:00 <[email protected]>: > >> >> So to sum up, my best impression presently is that time validation >> >> should be disabled for TLS certificates within NTPD. >> > Not going to change. >> >> Ok! >> >> For a user to add to his installer or maybe even boot scripts, a NTPD >> invocation that is foolproof so that it will succeed with sync even if the >> time is badly off, how would such an NTPD invocation look - would there be >> any reason to add an "ignore TLS certificate time on connect to constraint >> server" argument to NTPD, or should I just do "echo servers pool.ntp.org >> | ntpd -d -f /dev/stdin -s"? >> (Actually this NTPD invocation doesn't work, something about the stdin >> reading fails, would need to debug, any further pointer on a foolproof >> command line would be appreciated.) >> Btw also, can NTPD be run in any way so that it terminates after its first >> successful time sync? >> > > You are looking for "rdate", to run one-off, un-validated timesetting from > a time source on the net. > Adding "sure, use validation method but ignore time problems with cert if > any" to ntpd > sounds really like a silly idea.
Ah, "rdate -v pool.ntp.org" - great, right that is exactly the kind of date sync fixup I looked for. It also prints out the new time, and the adjustment it applied, making any MITM transparent, how practical. So this might be a healthy thing to run at first boot. And accordingly NTPD's present behavior also makes sense to me now. (For some other day I leave the question what MITM attack surface is left by the default NTPD configuration, how far from the constraint server's time could NTPD go, and what could happen if feed it with more constraint servers and they'd turn out to have some time deviation between them.) Thanks for pointing out!
