Show Posts
1
18.1 Legacy Series / Re: ***call for testing*** DNS TLS encryption using Quad9 and Cloudflare DNS servers
« on: April 07, 2018, 12:43:44 am »
Great initiative. It would be amazing to have DNS-over-TLS support i Opnsense.
But just to be clear: the long term goal would be to support DNS-over-(TLS/HTTPS) on all links, that is
a) Client stub (desktop/laptop/smartphone) -> local forwarder (Opnsense)
b) local forwarder (Opnsense) -> resolver (external, eg 1.1.1.1/Quad9)
c) resolver -> authoritative nameservers
What we are focusing on right now is link b).
Link a) might be considered "private", since it's on our local subnet. But anyway, the configuration of any local clients can not be easily automated. (It must be done manually until a new DHCP-option is standardised some time in the future.)
Link c) we don't control (unless we run a resolver on Opnsense). Either way, the "resolver-to-auth" spec is still in early draft stage (1).
As for b):
Unfortunately, Unbound does not (yet) support authenticating the upstream TLS server (2).
Since the connection is not authenticated, it only protects against passive attackers (eavesdropping), not active on-path attackers (man-in-the-middle).
Unbound also does not support configuring the TLS client options(?) (specify supported versions, ciphersuites etc).
Stubby has partial support for this:
One alternative listed by the dnsprivacy-project is to use Unbound+Stubby together (4):
Stubby (aka getdns) can authenticate the upstream resolver, using the dnsName in the certificate, and by verifying that the certificate chains to a trust anchor (list of CAs) (5)
The dnsprivacy-project (6) is a great resource for understanding the challenges with DNS-privacy, and how DNS privacy is supported in various DNS software (10).
Just for reference, the relevant standards are:
"DNS-over-TLS" (7)
"Usage Profiles for DNS over TLS and DNS over DTLS" (8 )
- just published (march 2018)
- specifies 2 privacy profiles
- strict (authenticate upstream server either via pubkey fingerprint, or by trust-chain+dns-name)
- opportunistic (authentication of upstream server not required, basically what Unbound supports today)
"DNS-over-HTTPS" (9)
- still in draft, but supported by both 1.1.1.1 and GoogleDNS
(1) https://tools.ietf.org/html/draft-bortzmeyer-dprive-resolver-to-auth-01
(2) https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=658
(3) https://dnsprivacy.org/wiki/display/DP/About+Stubby
(4) https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Clients
(5) https://github.com/juzam/docker-getdns-stubby/blob/master/stubby.yml
(6) https://dnsprivacy.org
(7) https://tools.ietf.org/html/rfc7858
(8 ) https://tools.ietf.org/html/rfc8310
(9) https://tools.ietf.org/html/draft-ietf-doh-dns-over-https-05
(10) https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Implementation+Status
And while we are discussing Cloudflare DNS, privacy and sharing logs with others:
https://community.cloudflare.com/t/privacy-policy-link/14890/4
But just to be clear: the long term goal would be to support DNS-over-(TLS/HTTPS) on all links, that is
a) Client stub (desktop/laptop/smartphone) -> local forwarder (Opnsense)
b) local forwarder (Opnsense) -> resolver (external, eg 1.1.1.1/Quad9)
c) resolver -> authoritative nameservers
What we are focusing on right now is link b).
Link a) might be considered "private", since it's on our local subnet. But anyway, the configuration of any local clients can not be easily automated. (It must be done manually until a new DHCP-option is standardised some time in the future.)
Link c) we don't control (unless we run a resolver on Opnsense). Either way, the "resolver-to-auth" spec is still in early draft stage (1).
As for b):
Unfortunately, Unbound does not (yet) support authenticating the upstream TLS server (2).
Since the connection is not authenticated, it only protects against passive attackers (eavesdropping), not active on-path attackers (man-in-the-middle).
Unbound also does not support configuring the TLS client options(?) (specify supported versions, ciphersuites etc).
Stubby has partial support for this:
Quote
"Stubby supports TLS v1.2. In 'Strict' mode Stubby is limited to using the 4 Cipher Suites recommended in RFC7525, in Opportunistic mode is uses the default OpenSSL Cipher suites." (3)
One alternative listed by the dnsprivacy-project is to use Unbound+Stubby together (4):
Code: [Select]
local client -> unbound (caching proxy) -> stubby (running on same host as unbound) -> (DNS-over-TLS) -> external resolver (1.1.1.1/quad9 etc)Stubby (aka getdns) can authenticate the upstream resolver, using the dnsName in the certificate, and by verifying that the certificate chains to a trust anchor (list of CAs) (5)
The dnsprivacy-project (6) is a great resource for understanding the challenges with DNS-privacy, and how DNS privacy is supported in various DNS software (10).
Just for reference, the relevant standards are:
"DNS-over-TLS" (7)
"Usage Profiles for DNS over TLS and DNS over DTLS" (8 )
- just published (march 2018)
- specifies 2 privacy profiles
- strict (authenticate upstream server either via pubkey fingerprint, or by trust-chain+dns-name)
- opportunistic (authentication of upstream server not required, basically what Unbound supports today)
"DNS-over-HTTPS" (9)
- still in draft, but supported by both 1.1.1.1 and GoogleDNS
(1) https://tools.ietf.org/html/draft-bortzmeyer-dprive-resolver-to-auth-01
(2) https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=658
(3) https://dnsprivacy.org/wiki/display/DP/About+Stubby
(4) https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Clients
(5) https://github.com/juzam/docker-getdns-stubby/blob/master/stubby.yml
(6) https://dnsprivacy.org
(7) https://tools.ietf.org/html/rfc7858
(8 ) https://tools.ietf.org/html/rfc8310
(9) https://tools.ietf.org/html/draft-ietf-doh-dns-over-https-05
(10) https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Implementation+Status
And while we are discussing Cloudflare DNS, privacy and sharing logs with others:
https://community.cloudflare.com/t/privacy-policy-link/14890/4