Re: ntpd with default config broken in -current

2017-01-02 Thread Stuart Henderson
On 2017/01/02 16:37, Matthieu Herrb wrote:
> On Mon, Jan 02, 2017 at 03:59:51PM +0100, Matthieu Herrb wrote:
> > Hi,
> > 
> > running -current on amd64 and i386 with the default /etc/ntpd.conf,
> > ntpd doesn't send any NTP request and doesn't sync the clock...
> > 
> > mirrorball% ntpctl -sa
> > 0/4 peers valid, clock unsynced
> > 
> > peer
> >wt tl st  next  poll  offset   delay  jitter
> > 151.80.19.218 from pool pool.ntp.org
> > 1  2  -0s0s  peer not valid 
> > 37.187.104.44 from pool pool.ntp.org
> > 1  2  -0s0s  peer not valid 
> > 37.187.2.84 from pool pool.ntp.org
> > 1  2  -0s0s  peer not valid 
> > 163.172.163.169 from pool pool.ntp.org
> > 1  2  -0s0s  peer not valid 
> > 
> > tcpdump -n -i em0 port 123 doesn't show any trafic on ntp port
> >
> 
> Looking a bit more, this is caused by a cert validation failure during
> constraints checks.

> The www.google.com certificate fails verification because the 'Equifax
> Secure Certificate Authority' root CA certificate that is on top of
> the www.google.com certificate chain is missing from newer
> /etc/ssl/cert.pem.

It fails verification because alt chains aren't working correctly.
It's this problem which I mentioned on another list:

- Forwarded message from Stuart Henderson  -

From: Stuart Henderson 
Date: Mon, 2 Jan 2017 13:26:07 +
Subject: alt chains / verify callback [Re: CVS: cvs.openbsd.org: src]

On 2016/12/26 09:20, Joel Sing wrote:
> CVSROOT:  /cvs
> Module name:  src
> Changes by:   js...@cvs.openbsd.org   2016/12/26 09:20:58
> 
> Modified files:
>   lib/libtls : tls.c tls_client.c 
> 
> Log message:
> Hook up a certificate verify callback so that we can set user friendly
> error messages, instead of libssl error strings. This gives us messages
> like:
> 
> certificate verification failed: certificate has expired
> 
> Instead of:
> 
> 14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
> 
> This also lets us always enable peer verification since the no verification
> case is now handled via the callback.
> 
> Tested by tedu@
> 
> ok beck@
> 

naddy ran into a problem fetching ports distfiles from a google server
with ftp(1) with the new cert.pem, whereas it was working OK for me
when I tested the cert.pem update with ftp(1) on a slightly older
snapshot (23 Dec).

I've bisected and found that this was the commit that stopped it from
working. However testing further I find that curl(1) (which doesn't
use libtls) also fails in a similar way.

google's chain looks like this;

---
Certificate chain
 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com
   i:/C=US/O=Google Inc/CN=Google Internet Authority G2
 1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2
   i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
   i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority
---

With the new cert.pem the old 1024-bit "Equifax Secure Certificate Authority"
cert is no longer included, so alt chains need to work to be able to connect to
it (GeoTrust Global CA is in cert.pem).

On -current:

$ nc -vvc google.com 443
Connection to google.com 443 port [tcp/https] succeeded!
nc: tls handshake failed (certificate verification failed: certificate not 
trusted)

On a machine with new cert.pem but older libtls:

$ ssh jodrell nc -vvc google.com 443
Connection to google.com 443 port [tcp/https] succeeded!
TLS handshake negotiated TLSv1.2/ECDHE-ECDSA-CHACHA20-POLY1305 with host 
google.com
Peer name: google.com
Subject: /C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.google.com
Issuer: /C=US/O=Google Inc/CN=Google Internet Authority G2
Valid From: Thu Dec 15 14:04:15 2016
Valid Until: Thu Mar  9 13:35:00 2017
Cert Hash: 
SHA256:c6ad71b8ad015bff4df56886261d0f975caa3ae427a3e68c2f8bf92f36824d4b
OCSP URL: http://clients1.google.com/ocsp

And on either machine with curl:

$ curl https://www.google.com/
curl: (51) SSL certificate verify result: certificate not trusted (27)

curl is not using SSL_CTX_set_cert_verify_callback; in that case the failure
is coming from SSL_get_verify_result -

lib/vtls/openssl.c

2796 lerr = data->set.ssl.certverifyresult =
2797   SSL_get_verify_result(connssl->handle);
2798 
2799 if(data->set.ssl.certverifyresult != X509_V_OK) {
2800   if(data->set.ssl.verifypeer) {
2801 /* We probably never reach this, because SSL_connect() will fail
2802and we return earlier if verifypeer is set? */
2803 if(strict)
2804   failf(data, "SSL certificate verify result: %s (%ld)",
2805 X509_verify_cert_error_string(lerr), lerr);
2806 result = CURLE_PEER_FAILED_VERIFICATION;
2807   }

Does anyone have ideas to fix it? If not, which of the temporary workarounds
would 

ntpd with default config broken in -current

2017-01-02 Thread Matthieu Herrb
Hi,

running -current on amd64 and i386 with the default /etc/ntpd.conf,
ntpd doesn't send any NTP request and doesn't sync the clock...

mirrorball% ntpctl -sa
0/4 peers valid, clock unsynced

peer
   wt tl st  next  poll  offset   delay  jitter
151.80.19.218 from pool pool.ntp.org
1  2  -0s0s  peer not valid 
37.187.104.44 from pool pool.ntp.org
1  2  -0s0s  peer not valid 
37.187.2.84 from pool pool.ntp.org
1  2  -0s0s  peer not valid 
163.172.163.169 from pool pool.ntp.org
1  2  -0s0s  peer not valid 

tcpdump -n -i em0 port 123 doesn't show any trafic on ntp port


Internet:
DestinationGatewayFlags   Refs  Use   Mtu  Prio Iface
defaultblackipUGS0   55 - 8 em0  
224/4  localhost  URS0   79 32768 8 lo0  
127/8  localhost  UGRS   00 32768 8 lo0  
localhost  localhost  UHhl   2   46 32768 1 lo0  
192.168.31/24  mirrorball UCn5 1600 - 4 em0  
mirrorball b8:ae:ed:72:d0:cd  UHLl   0  253 - 1 em0  
alix   00:0d:b9:15:76:50  UHLc   0  851 - 3 em0  
moonshine  10:78:d2:eb:7d:d7  UHLc   1  221 - 3 em0  
freenas00:9c:02:a0:45:b3  UHLc   2   15 - 3 em0  
blackip00:08:a2:09:99:52  UHLch  1   30 - 3 em0  
black  00:00:24:cd:7e:50  UHLc   0  520 - 3 em0  
192.168.31.255 mirrorball UHb15 - 1 em0  

Internet6:
DestinationGatewayFlags   Refs  Use   Mtu  Prio Iface
defaultfe80::31:200%em0   UGS2   39 - 8 em0  
::/96  localhost  UGRS   00 32768 8 lo0  
::/104 localhost  UGRS   00 32768 8 lo0  
localhost  localhost  UHhl  14   28 32768 1 lo0  
::127.0.0.0/104localhost  UGRS   00 32768 8 lo0  
::224.0.0.0/100localhost  UGRS   00 32768 8 lo0  
::255.0.0.0/104localhost  UGRS   00 32768 8 lo0  
:::0.0.0.0/96  localhost  UGRS   00 32768 8 lo0  
2002::/24  localhost  UGRS   00 32768 8 lo0  
2002:7f00::/24 localhost  UGRS   00 32768 8 lo0  
2002:e000::/20 localhost  UGRS   00 32768 8 lo0  
2002:ff00::/24 localhost  UGRS   00 32768 8 lo0  
2a03:7220:8081:610 mirrorball.herrb.n UCn42 - 4 em0  
mirrorball.herrb.n b8:ae:ed:72:d0:cd  UHLl   0  154 - 1 em0  
blackip.herrb.net  00:08:a2:09:99:52  UHLc   0  161 - 3 em0  
2a03:7220:8081:610 00:0d:b9:15:76:50  UHLc   2  195 - 3 em0  
freedom.herrb.net  00:23:8b:f2:b7:a3  UHLc   1  177 - 3 em0  
nebraska.herrb.net 7c:7a:91:ef:4e:d0  UHLc   2   47 - 3 em0  
fe80::/10  localhost  UGRS   01 32768 8 lo0  
fec0::/10  localhost  UGRS   00 32768 8 lo0  
fe80::%em0/64  fe80::baae:edff:fe UCn10 - 4 em0  
fe80::31:200%em0   00:08:a2:09:99:52  UHLch  1  427 - 3 em0  
fe80::baae:edff:fe b8:ae:ed:72:d0:cd  UHLl   0   51 - 1 em0  
fe80::1%lo0fe80::1%lo0UHl00 32768 1 lo0  
ff01::/16  localhost  UGRS   01 32768 8 lo0  
ff01::%em0/32  fe80::baae:edff:fe Um 01 - 4 em0  
ff01::%lo0/32  localhost  Um 01 32768 4 lo0  
ff02::/16  localhost  UGRS   01 32768 8 lo0  
ff02::%em0/32  fe80::baae:edff:fe Um 04 - 4 em0  
ff02::%lo0/32  localhost  Um 01 32768 4 lo0  

OpenBSD 6.0-current (GENERIC.MP) #15: Mon Jan  2 13:05:09 CET 2017
matth...@mirrorball.herrb.net:/usr/obj/GENERIC.MP
real mem = 8453414912 (8061MB)
avail mem = 8192557056 (7813MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xa2ee6000 (52 entries)
bios0: vendor Intel Corporation version "RYBDWi35.86A.0353.2015.1222.0947" date 
12/22/2015
bios0: Intel Corporation NUC5i3RYB
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT FIDT MCFG HPET SSDT UEFI LPIT SSDT ASF! SSDT 
SSDT SSDT DMAR BGRT
acpi0: wakeup devices PEGP(S4) PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4) 
PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) 
PXSX(S4) RP05(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at