On Wed, Jan 05, 2022 at 02:19:28PM -0700, Theo de Raadt wrote:
> Otto Moerbeek <[email protected]> wrote:
>
> > On Wed, Jan 05, 2022 at 11:45:36AM +0100, Matthias Schmidt wrote:
> >
> > > >Synopsis: ntpd constraint validation shows timestamp from 1899
> > > >Environment:
> > > System : OpenBSD 7.0
> > > Details : OpenBSD 7.0-current (GENERIC.MP) #216: Mon Jan 3
> > > 16:04:47 MST 2022
> > >
> > > [email protected]:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> > >
> > > Architecture: OpenBSD.amd64
> > > Machine : amd64
> > > >Description:
> > >
> > > Yesterday, the following log message from OpenNTPD appeared for the first
> > > and
> > > only time in my logs:
> > >
> > > Jan 4 19:35:04 sigma ntpd[72304]: maximum length exceeded
> > > Jan 4 19:35:04 sigma ntpd[72304]: tls certificate not yet valid: 9.9.9.9
> > > (9.9.9.9): not before 2021-07-27 00:00:00 UTC, now 1899-12-31 00:00:00 UTC
> > >
> > > It seems like some hiccup during constraint TLS certificate validation.
> > >
> > > Here are the log messages of the last two minutes BEFORE the lines above
> > > appeared:
> > >
> > > Jan 4 19:33:08 sigma ntpd[65131]: peer 134.76.249.201 now invalid
> > > Jan 4 19:33:16 sigma ntpd[65131]: peer 141.2.22.74 now invalid
> > > Jan 4 19:33:20 sigma ntpd[2066]: adjusting local clock by 0.468916s
> > > Jan 4 19:33:20 sigma ntpd[65131]: clock is now unsynced
> > > Jan 4 19:34:04 sigma ntpd[65131]: peer 134.76.249.201 now valid
> > > Jan 4 19:34:22 sigma ntpd[2066]: adjusting local clock by 0.153686s
> > > Jan 4 19:34:26 sigma ntpd[65131]: peer 134.76.249.201 now invalid
> > > Jan 4 19:34:54 sigma ntpd[65131]: clock is now synced
> > > Jan 4 19:34:54 sigma ntpd[65131]: constraint reply from 82.165.229.152:
> > > offset -0.891146
> > > Jan 4 19:35:00 sigma ntpd[65131]: constraint reply from 82.165.229.87:
> > > offset -0.776174
> > >
> > > The next time 9.9.9.9 appeared in the logs was around 15 minutes later:
> > >
> > > Jan 4 19:50:43 sigma ntpd[65131]: constraint reply from 2620:fe::fe:
> > > offset -0.848819
> > > Jan 4 19:50:43 sigma ntpd[65131]: constraint reply from 9.9.9.9: offset
> > > -0.872381
> >
> > The 1899 time is the time taken from the http reply headers received.
> > I suppose quad9 had a hickup and sent garbage. Likely the strptime()
> > call in ntpd/constraint.c went wrong but did not return an error in
> > some way. The answer to this contraint request was rejected. Other
> > constraints worked apparantly and after a while quad9 was reporting a
> > correct time in its http reply headers.
>
> So in other words, the code worked precisely as intended. The constraint
> timestamp was not consumed, and the alert is simply amusing.
>
Yep.
Looking at the loop again and seeing the "maximum length exceeded" I
think what has happened is that the loop exited without reading the
Date: line and so no call to strptime() happened at all.
The code could be improved a bit by returning -1 in that case.
-Otto
