I meant that as a privacy concern that some users might not be aware of. As a way of solving that problem one could suggest and point a finger explicitly on the default ntpd.conf.
Reasons ? A privacy concern that most users won't be aware of. I might have understood you wrong, otto. Please correct me. g Stephan On Sun, Dec 08, 2019 at 10:36:18AM +0100, Otto Moerbeek wrote: > On Sun, Dec 08, 2019 at 11:15:55AM +0100, List wrote: > > > Please excuse that I wasted your time. You're absolutely right. > > > > The only thing that comes to my mind is that one could add something > > like a small notice that tells the new user to maybe alter his ntpd > > constraints to a "TLS-Provider" that resides in his time zone. > > A good place for that could be the welcoming mail, which already > > describes some first steps. > > Why? You can travel the internet many times around and still be withing > the bounds the constraint checking allows. As for response time, google > anycast is pretty good at that. > > -Otto > > > > > > > On Sat, Dec 07, 2019 at 11:25:48AM -0700, Theo de Raadt wrote: > > > >That might be the case. > > > >The man page creates the impression that my ntpd will carry out a TLS > > > >Handshake with "https://www.google.com";. Out of that handshake (because > > > >it is anycast) you get your approximate local time. Which serves as > > > >vague measuring point for answers by the ntp servers that you are > > > >querying. But the suggestion I made is absolutely 100 % wrong. > > > > > > > >Would it be an option to choose another Anycast resolving address ? > > > >For example akami.net ? > > > > > > akami.net has no https. > > > maybe you mean akamai.net? again, no https. > > > > > > many akamai services come out of less capable caches, not making the > > > same effective certificate promises as the google front-end. would > > > you notice if an akamai service did a certificate downgrade? not > > > really. i don't think the proposal is serious. > > > > > > as a result we use quad9 and google https because their global > > > adjacency is excellent, and then we are avoiding cloudflare https > > > because we added their ticker in the mix (though their anycast ticker > > > is a very weird thing) > > > > > > >g Stephan > > > > > > > >On Thu, Dec 05, 2019 at 03:03:43PM -0700, Theo de Raadt wrote: > > > >> I guess you don't understand what is going on there. > > > >> > > > >> List <l...@md5collisions.eu> wrote: > > > >> > > > >> > Hello, > > > >> > > > > >> > here a diff replacing www.google.com as a default time constraint by > > > >> > www.openbsd.org. > > > >> > It is claimed that OpenBSD would have sane and secure defaults. While > > > >> > www.google.com might be secure it ain't sane from a privacy concerned > > > >> > perspective. Therefore the diff. > > > >> > > > > >> > Regards, > > > >> > Stephan > > > >> > > > > >> > Index: etc/ntpd.conf > > > >> > =================================================================== > > > >> > RCS file: /cvs/src/etc/ntpd.conf,v > > > >> > retrieving revision 1.16 > > > >> > diff -u -p -r1.16 ntpd.conf > > > >> > --- etc/ntpd.conf 6 Nov 2019 19:04:12 -0000 1.16 > > > >> > +++ etc/ntpd.conf 5 Dec 2019 21:36:57 -0000 > > > >> > @@ -8,4 +8,4 @@ sensor * > > > >> > > > > >> > constraint from "9.9.9.9" # quad9 v4 without DNS > > > >> > constraint from "2620:fe::fe" # quad9 v6 without DNS > > > >> > -constraints from "www.google.com" # intentionally not > > > >> > 8.8.8.8 > > > >> > +constraints from "www.openbsd.org" # intentionally not > > > >> > Google > > > >> > > > > >> > > > > > > >
