On 1/25/22 10:45, Christoph Anton Mitterer wrote:
On Tue, 2022-01-25 at 00:54 -0600, Richard Laager wrote:There are two potential issues: A) the server serves bogus/malicious time B) a MITM messes with the time.
(A) is kinda what I'd want to prevent by having -g removed... at least it shouldn't be "so easy" anymore for a rogue server (NTS or not) to quickly change the time by amounts that really matter.The primary protection for A is consensus (see specifically minsane). A single bogus/malicious clock can't do anything.At least not quickly... AFAIU it should still be able to slowly change my time, over time.
I don't see how that's possible. Eventually that single server will tick too far outside of the consensus window and be excluded as a falseticker.
To give you a real example of this... At $DAYJOB a week ago, one of my NTP servers has a PPS input from a telecom GPS clock. This clock failed; specifically it started outputting bad time (ticking at the wrong rate, as opposed to stopping outputting time entirely). ntpd followed this for a bit, making it look like the other sources all went insane simultaneously. After a few minutes (of elapsed time, not of time drift!), the error was bad enough that ntpd realized the PPS was insane, stopped following it, and followed the consensus of the other sources back to sanity. And this was with the PPS source marked "prefer". I'm not sure if anyone kept the graphs, but the error was us or ms, not even seconds, much less your example of 3 minutes.
With -g, and even despite NTS, they could send me malicious time, every time I boot (or (re)start the service manually).
Yes, they could. And someone (USNO, I think) had a bug a couple years ago where they did serve bad time. But if you have multiple sources, as you should, then you have protection against this. For example, I get my time from 8 sources, two with old style authentication and 1 with NTS.
So even on boot, even with -g, a single source can't cause one to accept bad time.
The default configuration uses the pool, so there too, a single source cannot cause one to accept bad time at boot even with -g.
Back to scenario B, the network MITM:Now, given NTS's current limited deployment, I have limited protections against a network MITM. Only 3 of my 8 sources have any protection at all, so a MITM could change the other 5 and I'd follow that. My choices are: reduce the number of non-authenticated sources, raise minsane, and/or run without -g (which only matters at boot).
In the default configuration, a MITM could slowly change your clock over time by changing all of the times you see. But -g or no -g is irrelevant to that. The _only_ real answer to the MITM is NTS.
-- Richard
OpenPGP_signature
Description: OpenPGP digital signature
