DNS over TLS host verification
- 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: 220.127.116.11@853#dns.quad9.net or 18.104.22.168@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.
Revert "Add fields for DNS server hostnames for TLS verification. Implements #8602"
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 reverts commit ad08a8242ca45907e0486712d218a5f8f34c7332.
Add back DNS over TLS host verification code. Fixes #8602
Requires Unbound 1.9.0_1 from pfsense/freebsd-ports, which fixes a bug
in Unbound 1.9.0 which did not fully implement OpenSSL 1.0.2 host
validation support. See https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=4206#c5
#5 Updated by Jim Pingle 8 months 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: 22.214.171.124@853#blah.example.com forward-addr: 126.96.36.199@853#doesnotexist.com forward-addr: 188.8.131.52@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 184.108.40.206 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:220.127.116.11, IP Address:18.104.22.168, 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 22.214.171.124 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.
#6 Updated by Jim Pingle 8 months 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.
#9 Updated by Chris Collins 3 months 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.
#10 Updated by Jim Pingle 3 months 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.
#11 Updated by Jim Pingle about 1 month 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 126.96.36.199@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
#13 Updated by Jim Pingle about 1 month 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.
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 188.8.131.52 port 853 (len 16)
Valid hostname is verified and works:
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:184.108.40.206, IP Address:220.127.116.11, IP Address:18.104.22.168, IP Address:22.214.171.124, IP Address:126.96.36.199, IP Address:188.8.131.52, IP Address:184.108.40.206, IP Address:220.127.116.11, IP Address:18.104.22.168, IP Address:22.214.171.124, IP Address:126.96.36.199, IP Address:188.8.131.52, IP Address:184.108.40.206, IP Address:149.112.112 Feb 6 13:59:38 jack unbound: [40033:0] debug: SSL connection authenticated ip4 220.127.116.11 port 853 (len 16)