Re: request for testing: bootstrapping time
On Mon, Jun 03, 2019 at 10:18:38AM -0400, sven falempin wrote: > On Mon, Jun 3, 2019 at 1:44 AM Otto Moerbeek wrote: > > > > Hi, > > > > If you ever wanted to be more involved in OpenBSD here's a chanche: > > > > https://marc.info/?l=openbsd-tech&m=155950103825035&w=2 > > > > It requires setting up a test machine running a recent snapshot, so > > that's a nice first step. Then get the sources and apply the patch, > > build and test > > > > You'll find help getting src and bulding the system in the FAQ. > > > > Much appreciated! > > > > -Otto > > > > Dear readers, > > I'd like to share some result regarding ntpd , I did not yet configure > DNSSEC and will try that later. > I use a local unbound, and have some issue regarding time on some devices. > > on 6.0 I was unable to use constraint: it was not working. > my current production version is 6.4, and I have 'problems' similar to > the one nicely explain above, > I still feel like a STDERR warning would be nice for -s flag failure, > because reading log in rcctl like management script > when time is not set is 'incomplete'. > > This is an important feature to TEST. ( thank you Otto for working on ntpd ) > > I m running a slightly modified HEAD version in the test, see __why not__ > this is a * pre test * > > First I stopped ntpd and changed the date , then run with -ds > > badblock# rcctl stop ntpd && date 20180603.00 && ntpd -s > ntpd(ok) > Sun Jun 3 00:00:00 EDT 2018 > ntp engine ready > trying to resolve www.google.com > resolve www.google.com done: 2 > trying to resolve pool.ntp.org > resolve pool.ntp.org done: 4 > constraint request to 2607:f8b0:4020:804::2004 > constraint request to 172.217.13.196 > tls connect failed: 2607:f8b0:4020:804::2004 (www.google.com): > connect: No route to host > no constraint reply from 2607:f8b0:4020:804::2004 received in time, > next query 900s > constraint reply from 172.217.13.196: offset 31567971.561072 > reply from 206.108.0.131: offset 31567971.791870 delay 0.016370, next query > 8s > set local clock to Mon Jun 3 08:53:04 EDT 2019 (offset 31567971.791870s) > reply from 154.11.146.39: offset 15783985.894667 delay > 31567971.873626, next query 5s > reply from 209.115.181.107: offset 15783985.890166 delay > 31567971.885181, next query 7s > reply from 205.206.70.2: offset 15783985.888720 delay > 31567971.886449, next query 6s > reply from 154.11.146.39: offset -0.000489 delay 0.082025, next query 6s > reply from 205.206.70.2: offset -0.011286 delay 0.087997, next query 6s > reply from 206.108.0.131: offset 0.003587 delay 0.022641, next query 8s > reply from 209.115.181.107: offset -0.006413 delay 0.091241, next query 9s > reply from 154.11.146.39: offset 0.013697 delay 0.110286, next query 7s > reply from 205.206.70.2: offset -0.010733 delay 0.091208, next query 9s > reply from 206.108.0.131: offset 0.010468 delay 0.036784, next query 9s > reply from 209.115.181.107: offset -0.01 delay 0.096816, next query 8s > peer 154.11.146.39 now valid > > as we can read here in basic scenario the constraint will force the > setup, when everything s fine, ….everything s fine ! > Assuming you have a nicely place anchor > Let 's do : echo 'block on egress proto {tcp,udp} from any to any port > ntp' | pfctl -f - -a 'top' > or echo 'block on egress proto {tcp,udp} from any to any port ntp' >> > /etc/pf.conf && pfctl -f /etc/pf.conf in a default setup. > Things can get more interesting. I m not sure why but I had to modify > my /etc/hosts to force ipv4 , no matter. > Nevertheless: > > badblock# ntpd -sd > ntp engine ready > trying to resolve www.google.com > resolve www.google.com done: 1 > trying to resolve pool.ntp.org > resolve pool.ntp.org done: 4 > constraint request to 172.217.13.132 > constraint reply from 172.217.13.132: offset 31568246.201761 > set local clock to Sun Jun 3 00:42:25 EDT 2018 (offset 0.00s) > > ^Cntp engine exiting > Terminating > badblock# date > Sun Jun 3 00:42:35 EDT 2018 > badblock# ntpd -sd > ntp engine ready > trying to resolve www.google.com > resolve www.google.com done: 1 > trying to resolve pool.ntp.org > resolve pool.ntp.org done: 4 > constraint request to 172.217.13.132 > constraint reply from 172.217.13.132: offset 31568246.593501 > set local clock to Sun Jun 3 00:42:39 EDT 2018 (offset 0.00s) > ^Cntp engine exiting > Terminating > > The clock suddenly refuse to be set up correctly with the HTTP header. > And it is logged that clock is set : set local clock to Sun Jun 3 > 00:42:39 EDT 2018 (offset 0.00s) > wrongly. > > Given the above proposition, the ULTRA_VIOLENCE mode may not be working > as the clock wont be offset by the http header. > > I hope this *pretest* log may help other user to test this important > bootstrapping. > The above result is for me a problem, and I will have to thwart this > first ( and find time for DNSSEC setup). > > NB: it is possible to have a network where HTTPS
Re: request for testing: bootstrapping time
On Mon, Jun 3, 2019 at 1:44 AM Otto Moerbeek wrote: > > Hi, > > If you ever wanted to be more involved in OpenBSD here's a chanche: > > https://marc.info/?l=openbsd-tech&m=155950103825035&w=2 > > It requires setting up a test machine running a recent snapshot, so > that's a nice first step. Then get the sources and apply the patch, > build and test > > You'll find help getting src and bulding the system in the FAQ. > > Much appreciated! > > -Otto > Dear readers, I'd like to share some result regarding ntpd , I did not yet configure DNSSEC and will try that later. I use a local unbound, and have some issue regarding time on some devices. on 6.0 I was unable to use constraint: it was not working. my current production version is 6.4, and I have 'problems' similar to the one nicely explain above, I still feel like a STDERR warning would be nice for -s flag failure, because reading log in rcctl like management script when time is not set is 'incomplete'. This is an important feature to TEST. ( thank you Otto for working on ntpd ) I m running a slightly modified HEAD version in the test, see __why not__ this is a * pre test * First I stopped ntpd and changed the date , then run with -ds badblock# rcctl stop ntpd && date 20180603.00 && ntpd -s ntpd(ok) Sun Jun 3 00:00:00 EDT 2018 ntp engine ready trying to resolve www.google.com resolve www.google.com done: 2 trying to resolve pool.ntp.org resolve pool.ntp.org done: 4 constraint request to 2607:f8b0:4020:804::2004 constraint request to 172.217.13.196 tls connect failed: 2607:f8b0:4020:804::2004 (www.google.com): connect: No route to host no constraint reply from 2607:f8b0:4020:804::2004 received in time, next query 900s constraint reply from 172.217.13.196: offset 31567971.561072 reply from 206.108.0.131: offset 31567971.791870 delay 0.016370, next query 8s set local clock to Mon Jun 3 08:53:04 EDT 2019 (offset 31567971.791870s) reply from 154.11.146.39: offset 15783985.894667 delay 31567971.873626, next query 5s reply from 209.115.181.107: offset 15783985.890166 delay 31567971.885181, next query 7s reply from 205.206.70.2: offset 15783985.888720 delay 31567971.886449, next query 6s reply from 154.11.146.39: offset -0.000489 delay 0.082025, next query 6s reply from 205.206.70.2: offset -0.011286 delay 0.087997, next query 6s reply from 206.108.0.131: offset 0.003587 delay 0.022641, next query 8s reply from 209.115.181.107: offset -0.006413 delay 0.091241, next query 9s reply from 154.11.146.39: offset 0.013697 delay 0.110286, next query 7s reply from 205.206.70.2: offset -0.010733 delay 0.091208, next query 9s reply from 206.108.0.131: offset 0.010468 delay 0.036784, next query 9s reply from 209.115.181.107: offset -0.01 delay 0.096816, next query 8s peer 154.11.146.39 now valid as we can read here in basic scenario the constraint will force the setup, when everything s fine, ….everything s fine ! Assuming you have a nicely place anchor Let 's do : echo 'block on egress proto {tcp,udp} from any to any port ntp' | pfctl -f - -a 'top' or echo 'block on egress proto {tcp,udp} from any to any port ntp' >> /etc/pf.conf && pfctl -f /etc/pf.conf in a default setup. Things can get more interesting. I m not sure why but I had to modify my /etc/hosts to force ipv4 , no matter. Nevertheless: badblock# ntpd -sd ntp engine ready trying to resolve www.google.com resolve www.google.com done: 1 trying to resolve pool.ntp.org resolve pool.ntp.org done: 4 constraint request to 172.217.13.132 constraint reply from 172.217.13.132: offset 31568246.201761 set local clock to Sun Jun 3 00:42:25 EDT 2018 (offset 0.00s) ^Cntp engine exiting Terminating badblock# date Sun Jun 3 00:42:35 EDT 2018 badblock# ntpd -sd ntp engine ready trying to resolve www.google.com resolve www.google.com done: 1 trying to resolve pool.ntp.org resolve pool.ntp.org done: 4 constraint request to 172.217.13.132 constraint reply from 172.217.13.132: offset 31568246.593501 set local clock to Sun Jun 3 00:42:39 EDT 2018 (offset 0.00s) ^Cntp engine exiting Terminating The clock suddenly refuse to be set up correctly with the HTTP header. And it is logged that clock is set : set local clock to Sun Jun 3 00:42:39 EDT 2018 (offset 0.00s) wrongly. Given the above proposition, the ULTRA_VIOLENCE mode may not be working as the clock wont be offset by the http header. I hope this *pretest* log may help other user to test this important bootstrapping. The above result is for me a problem, and I will have to thwart this first ( and find time for DNSSEC setup). NB: it is possible to have a network where HTTPS is possible but NTP blocked or invalid (or hacked), and /etc/ssl/cert.pem + a valid ip/domain ( why not constraint https://a valid ip/ ) trust level is above the BIOS for me. Best. tl;dr And by the way, restricting or having custom certificate would be a strong feature ntpd -c /etc/ssl/restricted.pem , also se