Door Erik van Straten:
Ik betwijfel (niet opgezocht) of het een "eis" is van het ntp-protocol om slechts kleine aanpassingen per keer te maken: dat is vooral iets wat je vaak client-side wilt (omdat processen die iets met timing doen, zoals timeouts genereren, onverwachte fouten kunnen geven als je de systeemklok een slinger geeft - vooral als je een klok achteruit zet en een datum+tijd nogmaals "voorbij komt").
Toch staat dat wel in de NTP RFC. Dit komt ook omdat de RFC ooit gemaakt is door de schrijver van de reference
implementatie, waarin dit allemaal goed geregeld is.
Dat sluit niet uit dat er implementaties zijn die dit niet goed doen. Behalve een NTP client kan er ook sprake zijn
van een SNTP client die gewoon eens per zoveel tijd de tijd opvraagt (met een subset van het NTP protocol) en het
geretourneerde antwoord gewoon in de systeemklok ramt.
Met name simpele devices zoals routers die werken vaak op die manier.
Probleem: als de datum en tijd flink fout zijn is het vaak onwenselijk dat de klok met kleine stapjes wordt bijgeregeld. Als OS-bouwer zit je dus met het dilemma wat te doen als NTP, bij herhaling, blijft zeggen dat de klok bijv. 1 dag, 1 maand of zelfs jaren fout staat.
In elk geval is het zo dat als ik onder Android:
1) "Use network-provided time" uitzet
2) De systeemklok een paar uur vooruit zet
3) "Use network-provided time" aanzet
de systeemklok met één klap teruggaat naar de juiste tijd.
Natuurlijk bewijst dit niet zoveel, maar ik heb (nog) niet onderzocht wat er gebeurt als de klok flink zou driften in een periode dat je geen bereik hebt en de verbinding wordt hersteld.
Dit is precies het gedrag wat je van een goede NTP implementatie mag verwachten. Bij normaal bedrijf alleen
langzaam bijregelen en bij stoppen/starten tijdelijk in een mode werken waarin een grotere sprong mogelijk is.
Dat betekent dat als jij zelf de netwerk sync aanzet en constateert dat het goed gaat, een "aanvaller" niet zomaar
even met het geven van rare NTP antwoorden de tijd behoorlijk kan beinvloeden. Een tijd die "helemaal fout" is
zal normaalgesproken genegeerd worden, en een tijd die "een beetje afwijkt" zal het regelsysteem in werking
stellen waarmee de systeemklok langzaam naar die nieuwe waarde loopt. Wil je daarmee een klok een paar uur
verzetten dan moet je gedurende meerdere dagen precies uitgedokterde foute NTP antwoorden kunnen geven
waarmee je die client langzaam van slag brengt, en al die tijd moet het de gebruiker niet opvallen dat de klok
verkeerd staat. Niet erg waarschijnlijk dat dit lukt.
Op smartphones [*] is de kans dat de gebruiker het foutstaan van de klok ontdekt en handmatig ingrijpt (en we zijn het er kennelijk over eens dat de toegang daartoe beveiligd zou moeten worden), maar een klok die 1 minuut foutloopt levert al vette problemen op met TOTP-apps en kan dus leiden tot helpdesk calls.
Nee hoor, een minuut is geen probleem, de grens ligt meestal verder weg bijvoorbeeld bij 5-15 minuten.
Sterker, vanuit Google Authenticator kun je de systeemklok synchroniseren (zou moeten kunnen, hij meldt bij mij nu, via 4G, "There was a problem contacting Google's server. Please check your network settings and try again"). Ik weet niet welk protocol hiervoor gebruikt wordt, maar als dat "ntpdate" is (zoals Anoniem Gisteren, 09:39 benoemt), en jij de server kunt faken, gaat dit alsnog fout.
Dat zou geen zin hebben. Ik denk eerder dat dit een eigen protocol van die authenticator is dat bijvoorbeeld via een https verbinding met een Google server de tijd ophaalt.
Zelfs een willekeurige webserver waarvan je weet dat de klok goed staat daar kun je de tijd vanaf halen, weliswaar slechts met een resolutie van 1 seconde maar dat is goed genoeg om hem binnen NTP "vangbereik" te brengen en om TOTP te laten werken.
Dus Google zou dit gewoon met google.com kunnen doen. Hoe ze er in slagen om een probleem daarmee te krijgen weet ik ook niet.