On 5/13/26 16:27, Daniel wrote:
Hello!
Thank you for you comments.

I toke a while do read the man pages and also to make some searches...
Man page says:
"Time can also be fetched from TLS HTTPS servers to reduce the impact of 
unauthenticated NTP man-in-the-middle attacks."

you need to read the entire man page.  You also need to read
the ntpd.conf man page.


So it seams that we can assume that the clock is still corrected having only "constrains" 
in ntpd.conf. Maybe that is not enough to have “ntpctl -s status” saying "clock synced".

no.


This is an interesting subject and it would be great to have it really clear
I respect you opinion. And I know I am just an openbsd rookie, but I believe 
that there can be some contradiction between what the man page says and your 
response.

Much more an interpretation issue...

NTP is not a secured protocol -- there's no real proof
that you are talking to the server you think you are.  So if I
can slip my server in between your server and what you are hoping
is an authoritative source, I can change your clocks.  If I can
change your clock, perhaps I can convince you to accept an
expired certificate I stole, or any of a number of other forms
of mischief.

OpenNTPD tries to make that more difficult by getting a *rough*
time estimate by making an HTTPS connection to a trusted source.
So...if (for example) an HTTPS connection to www.google.com says
the time is a particular time, and the upsream NTP server says it
is within a few seconds of that time -- we can probably trust the
NTP server's time report.  If it comes back with a radically
different time, then no, we won't trust the NTP time.

from man ntpd.conf:

CONSTRAINTS
     ntpd(8) can be configured to query the `Date' from trusted HTTPS servers
     via TLS.  This time information is not used for precision but acts as an
     authenticated constraint, thereby reducing the impact of unauthenticated
     NTP man-in-the-middle attacks.  Received NTP packets with time
     information falling outside of a range near the constraint will be
     discarded and such NTP servers will be marked as invalid.

ntpd MUST use the NTP protocol via the NTP ports.  "Constraints"
are just a verification through secured channels that the NTP data
you are getting is plausible -- it isn't used as the answer, ever.


Nick.

Reply via email to