On Mon, Jun 03, 2019 at 10:18:38AM -0400, sven falempin wrote:
> On Mon, Jun 3, 2019 at 1:44 AM Otto Moerbeek <o...@drijf.net> 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 201806030000.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.013333 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.000000s)
>
> ^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.000000s)
> ^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.000000s)
> 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.
I explicitly asked to test on current *without* -s
You are just adding noise.
-Otto
>
> tl;dr
> And by the way, restricting or having custom certificate would be a
> strong feature ntpd -c /etc/ssl/restricted.pem ,
> also sending a certificate to the server to authenticate the client
> would provide a interesting secure bootstrapping.
> saving us from ntpds which is million lines of python at the moment.
> ( HTTPS for base clock, classic ntp to adjust ).
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
> ? And if DNSSEC works, can we put a TIME record in it ?
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
>
> __why not__ (not a usable diff)
>
> Index: config.c
> ===================================================================
> RCS file: /cvs/src/usr.sbin/ntpd/config.c,v
> retrieving revision 1.30
> diff -u -p -r1.30 config.c
> --- config.c 28 May 2019 06:49:46 -0000 1.30
> +++ config.c 3 Jun 2019 13:45:08 -0000
> @@ -135,7 +135,7 @@ host_dns(const char *s, struct ntp_addr
> if (error <= 0) {
> log_debug("no luck, trying to resolve %s without checking",
> s);
> save_opts = _res.options;
> - _res.options |= RES_USE_CD;
> + // _res.options |= RES_USE_CD;
> error = host_dns1(s, hn, 1);
> _res.options = save_opts;
> }
> Index: constraint.c
> ===================================================================
> RCS file: /cvs/src/usr.sbin/ntpd/constraint.c,v
> retrieving revision 1.44
> diff -u -p -r1.44 constraint.c
> --- constraint.c 30 May 2019 13:42:19 -0000 1.44
> +++ constraint.c 3 Jun 2019 13:45:08 -0000
> @@ -343,7 +343,7 @@ priv_constraint_child(const char *pw_dir
> /* Init TLS and load CA certs before chroot() */
> if (tls_init() == -1)
> fatalx("tls_init");
> - if ((conf->ca = tls_load_file(tls_default_ca_cert_file(),
> + if ((conf->ca = tls_load_file("/etc/ssl/cert.pem",
> &conf->ca_len, NULL)) == NULL)
> fatalx("failed to load constraint ca");
> Index: ntpd.c
> ===================================================================
> RCS file: /cvs/src/usr.sbin/ntpd/ntpd.c,v
> retrieving revision 1.120
> diff -u -p -r1.120 ntpd.c
> --- ntpd.c 14 Jan 2019 16:30:21 -0000 1.120
> +++ ntpd.c 3 Jun 2019 13:45:08 -0000
> @@ -251,7 +251,7 @@ main(int argc, char *argv[])
> * Constraint processes are forked with certificates in memory,
> * then privdrop into chroot before speaking to the outside world.
> */
> - if (unveil(tls_default_ca_cert_file(), "r") == -1)
> + if (unveil("/etc/ssl/cert.pem", "r") == -1)
> err(1, "unveil");
> if (unveil("/usr/sbin/ntpd", "x") == -1)
> err(1, "unveil");
>
> --
> --
> ---------------------------------------------------------------------------------------------------------------------
> Knowing is not enough; we must apply. Willing is not enough; we must do
>
