Feature #8602
closed
DNS over TLS host verification
Added by Andrew M over 6 years ago. Updated over 5 years ago.
100%
Description
Currently at 1.6.8 in release, and 1.7.0 on devel. Unbound 1.7.1 includes this feature (see release notes):
- Can set tls authentication with forward-addr: IP#tls.auth.name And put the public cert bundle in tls-cert-bundle: "ca-bundle.pem". such as forward-addr: 9.9.9.9@853#dns.quad9.net or 1.1.1.1@853#cloudflare-dns.com
Without this there’s no verification of the authenticity of the connection, and it is thus susceptible to a MITM attack.
Requisite GUI changes related to #8388 may also be needed.
Updated by Jim Pingle over 6 years ago
devel should pick it up naturally here in a week or two when the 2018Q3 branch comes in. FreeBSD ports tree HEAD/master is at unbound 1.7.3.
Updated by Jim Pingle over 6 years ago
- Subject changed from Update Unbound to 1.7.1 or later to support DNS over TLS verification to DNS over TLS host verification
- Assignee set to Jim Pingle
- Target version set to 2.4.4
Updated by Jim Pingle over 6 years ago
Unbound 1.7.3 is in current 2.4.4 snapshots, so this can be added now.
Updated by Jim Pingle over 6 years ago
- Status changed from New to Feedback
- % Done changed from 0 to 100
Applied in changeset ad08a8242ca45907e0486712d218a5f8f34c7332.
Updated by Jim Pingle over 6 years ago
- Status changed from Feedback to Assigned
So it looks like we are setting up the unbound configuration correctly but it does not appear to be enforcing hostname/cert check.
# TLS Configuration
tls-cert-bundle: "/etc/ssl/cert.pem"
[...]
# Forwarding
forward-zone:
name: "."
forward-tls-upstream: yes
forward-addr: 9.9.9.9@853#blah.example.com
forward-addr: 1.0.0.1@853#doesnotexist.com
forward-addr: 149.112.112.112@853#somethingwrong.com
: clog /var/log/resolver.log | egrep -i '(cert|auth|doesnot)' | tail -4 Jul 16 10:31:12 jack unbound: [29373:0] debug: [doesnotexist.com] ip4 1.0.0.1 port 853 (len 16) Jul 16 10:31:12 jack unbound: [29373:0] debug: peer certificate: Issuer: C=US, O=DigiCert Inc, CN=DigiCert ECC Secure Server CA Validity Not Before: Mar 30 00:00:00 2018 GMT Not After : Mar 25 12:00:00 2020 GMT Subject: C=US, ST=CA, L=San Francisco, O=Cloudflare, Inc., CN=*.cloudflare-dns.com X509v3 extensions: X509v3 Authority Key Identifier: keyid:A3:9D:E6:1F:F9:DA:39:4F:C0:6E:E8:91:CB:95:A5:DA:31:E2:0A:9F X509v3 Subject Key Identifier: DF:97:4D:E5:43:B3:B0:41:A7:42:F2:90:CF:89:7F:AE:12:57:84:E1 X509v3 Subject Alternative Name: DNS:*.cloudflare-dns.com, IP Address:1.1.1.1, IP Address:1.0.0.1, DNS:cloudflare-dns.com, IP Address:2606:4700:4700:0:0:0:0:1111, IP Address:2606:4700:4700:0:0:0:0:1001 X509v3 Key Usage: critical Digital Signature X509v3 Extended Key Usage: TLS Web Server Authentication, TLS Web Client Jul 16 10:31:12 jack unbound: [29373:0] debug: SSL connection authenticated ip4 1.0.0.1 port 853 (len 16) Jul 16 10:31:12 jack unbound: [29373:0] info: incoming scrubbed packet: ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 0 ;; flags: qr rd ra ; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: 0.pfsense.pool.ntp.org. IN AAAA ;; ANSWER SECTION: ;; AUTHORITY SECTION: pool.ntp.org. 1500 IN SOA a.ntpns.org. hostmaster.pool.ntp.org. 1531751408 5400 5400 1209600 3600 ;; ADDITIONAL SECTION: ;; MSG SIZE rcvd: 95
I thought it may be due to the certificate containing the IP address, but it behaves identically when pointed at a DNS server with a Let's Encrypt cert that only contains a hostname.
Upstream bug opened: https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=658
If the upstream bug is not addressed before 2.4.4 is released, we may need to disable the options for this code.
Updated by Jim Pingle over 6 years ago
- Target version changed from 2.4.4 to 2.5.0
- % Done changed from 100 to 90
Per https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=658 the verification requires OpenSSL 1.1.x, and FreeBSD 11.2 base OpenSSL is 1.0.x.
This will have to wait until FreeBSD base includes OpenSSL 1.1.x.
Updated by Jim Pingle over 6 years ago
- Status changed from Assigned to Feedback
- % Done changed from 90 to 100
Applied in changeset e1ad890e581ad76a17af2860b054ce496a0aa56f.
Updated by Chris Collins almost 6 years ago
if you guys want this before pfsense 2.5, you only need to compile unbound against openssl 1.1, the system binary can still be an older openssl, which many freebsd configurations actually run like this by using openssl from ports, so basically compiling against a newer openssl from ports whilst still having an older base openssl, now I know pfsense doesnt use freebsd ports, but the basic principle still applies that the unbound pfsense package can be compiled statically against its own openssl 1.1. libraries.
Updated by Jim Pingle almost 6 years ago
We have gone down the road of having multiple OpenSSL instances on the firewall before and it was a pain to maintain, have everything use the correct paths, make sure everything was linked against the expected version, and so on. It also confused users to have two different sets of OpenSSL binaries on the system that behaved differently. We'll stick to what's in the FreeBSD base system. When we move to a FreeBSD 12 base, we'll get OpenSSL 1.1.x automatically.
Updated by Jim Pingle almost 6 years ago
Unbound 1.9.0 added support for verifying hosts on OpenSSL 1.0.2, but it still doesn't seem to work. Unbound 1.9.0 is in 2.4.5 snapshots, and I still get the same failure.
Feb 6 11:38:46 jack unbound: [45843:0] error: no name verification functionality in ssl library, ignored name for 9.9.9.9@853#blah.example.com
Looking in the source it's failing a check with this:
#ifndef HAVE_SSL_SET1_HOST
if(auth_name)
log_err("no name verification functionality in "
"ssl library, ignored name for %s", todo);
#endif
There are a couple other checks as well that were not updated.
I patched the checks and it works as expected in a test, I pushed the patches to our ports repo for further testing. I sent the patch to Unbound at https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=4206#c5
Updated by Jim Pingle almost 6 years ago
- Status changed from Assigned to Feedback
Applied in changeset 7e8bfed216304b37342a0800eb35ef7c29546f5d.
Updated by Jim Pingle almost 6 years ago
The next build that includes unbound 1.9.0_1 and the changes referenced on this issue will be ready for testing. Using a patched copy compiled locally, it works. It complains about invalid hosts and notes success of valid hosts:
Deliberately bad/mismatched hostname, fails as expected.
forward-addr: 149.112.112.112@853#somethingwrong.com
Feb 6 13:59:26 jack unbound: [40033:0] error: ssl handshake failed crypto error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed Feb 6 13:59:26 jack unbound: [40033:0] notice: ssl handshake failed ip4 149.112.112.112 port 853 (len 16)
Valid hostname is verified and works:
forward-addr: 9.9.9.9@853#dns.quad9.net
Feb 6 13:59:38 jack unbound: [40033:0] debug: peer certificate: Issuer: C=US, O=DigiCert Inc, CN=DigiCert ECC Secure Server CA Validity Not Before: Sep 20 00:00:00 2018 GMT Not After : Sep 24 12:00:00 2020 GMT Subject: C=US, ST=California, L=Berkeley, O=Quad9, CN=*.quad9.net X509v3 extensions: X509v3 Authority Key Identifier: keyid:A3:9D:E6:1F:F9:DA:39:4F:C0:6E:E8:91:CB:95:A5:DA:31:E2:0A:9F X509v3 Subject Key Identifier: 7F:A9:12:A5:D7:C6:8B:48:02:C7:3D:2A:45:6E:40:1E:40:60:F4:97 X509v3 Subject Alternative Name: DNS:*.quad9.net, DNS:quad9.net, IP Address:9.9.9.9, IP Address:9.9.9.10, IP Address:9.9.9.11, IP Address:9.9.9.12, IP Address:9.9.9.13, IP Address:9.9.9.14, IP Address:9.9.9.15, IP Address:149.112.112.9, IP Address:149.112.112.10, IP Address:149.112.112.11, IP Address:149.112.112.12, IP Address:149.112.112.13, IP Address:149.112.112.14, IP Address:149.112.112 Feb 6 13:59:38 jack unbound: [40033:0] debug: SSL connection authenticated ip4 9.9.9.9 port 853 (len 16)
Updated by Chris Linstruth over 5 years ago
Similar results here. Mismatched FQDN for the server results in a certificate verify error for unbound:
Apr 29 04:48:10 unbound 57201 [57201:0] error: ssl handshake failed crypto error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed
Apr 29 04:48:10 unbound 57201 [57201:0] notice: ssl handshake failed 9.9.9.9 port 853
Updated by Jim Pingle over 5 years ago
- Status changed from Feedback to Resolved
Updated by Jim Pingle over 5 years ago
- Target version changed from 2.5.0 to 2.4.4-p3
Updated by Jim Pingle over 5 years ago
- Status changed from Resolved to Feedback
Updated by Chris Linstruth over 5 years ago
2.4.4-p3:
May 13 19:39:24 unbound 82673:1 error: no name verification functionality in ssl library, ignored name for 149.112.112.112@853#dns.xyzzy.com
Updated by Jim Pingle over 5 years ago
- Status changed from Feedback to Assigned
- Assignee changed from Jim Pingle to Renato Botelho
Looks like we'll need to import Unbound 1.9.0
Updated by Chris Linstruth over 5 years ago
- Status changed from Assigned to Feedback
Looks good with the new build with unbound 1.9.1. Only fails with a bogus hostname defined. Works with either 149.112.112.112 or *.quad9.net which are both CN/SAN in the presented certificate.
Also fails querying another pfSense node providing DNS resolver services with a self-signed certificate matching the configured DNS Hostname/IP address.
Updated by Jim Pingle over 5 years ago
- Status changed from Feedback to Resolved