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=155950103825035=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
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=155950103825035=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
