Project

General

Profile

Actions

Feature #8602

closed

DNS over TLS host verification

Added by Andrew M over 6 years ago. Updated over 5 years ago.

Status:
Resolved
Priority:
Normal
Category:
DNS Resolver
Target version:
Start date:
06/26/2018
Due date:
% Done:

100%

Estimated time:
Plus Target Version:
Release Notes:

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.

Actions #1

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.

Actions #2

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
Actions #3

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.

Actions #4

Updated by Jim Pingle over 6 years ago

  • Status changed from New to Feedback
  • % Done changed from 0 to 100
Actions #5

Updated by Jim Pingle about 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.

Actions #6

Updated by Jim Pingle about 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.

Actions #7

Updated by Jim Pingle about 6 years ago

  • Status changed from Assigned to Feedback
  • % Done changed from 90 to 100
Actions #8

Updated by Jim Pingle about 6 years ago

  • Status changed from Feedback to Assigned
Actions #9

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.

Actions #10

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.

Actions #11

Updated by Jim Pingle over 5 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

Actions #12

Updated by Jim Pingle over 5 years ago

  • Status changed from Assigned to Feedback
Actions #13

Updated by Jim Pingle over 5 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)

Actions #14

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

Actions #15

Updated by Jim Pingle over 5 years ago

  • Status changed from Feedback to Resolved
Actions #16

Updated by Jim Pingle over 5 years ago

  • Target version changed from 2.5.0 to 2.4.4-p3
Actions #17

Updated by Jim Pingle over 5 years ago

  • Status changed from Resolved to Feedback
Actions #18

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

Actions #19

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

Actions #20

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.

Actions #21

Updated by Jim Pingle over 5 years ago

  • Status changed from Feedback to Resolved
Actions

Also available in: Atom PDF