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.
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
