Bugzilla – Bug 658
unbound using TLS in a forwarding configuration does not verify the server's certificate
Last modified: 2017-11-06 09:30:26 CET
(this is for unbound 1.5.3, but i don't see it in the list above)
I have the following unbound.conf to act as forwarder to another TLS-over-TCP unbound implementation:
However, there appears to be no verification of the server's certificate -- the server i'm speaking to has a self-signed certificate, and unbound has no way to know about it initially, so i don't see how it could possibly be verifying the cert.
how to verify the cert itself is an interesting question, though: you can't identify the remote host by name (because we don't want to have to have DNS to do the lookup), and we generally discourage X.509 certs with an IP address in the subjectAltNames.
So i think the configuration mechanism should be one of the following options (maybe we can offer :
* forward-fingerprint: an sha256 sum of the Subject Public Key Info of the server's certificate
* forward-name: the name of upstream server (this is like forward-host, except that it is only used for cert validation, and not looked-up before connection)
* forward-cafile: a file containing the certificates of the root certification authorities allowed to issue certs for the forwarded server; (the verification mechanism looks for a valid cert for forward-name (if present) or forward-host).
Yes the ssl-upstream feature wraps traffic in tls, but does not verify certificates. It's documented. For authentication, perhaps we could see what the dprive IETF WG comes up with in their standardisation? They are currently working on dns over tls. I would not want to pre-empt their solution.
I would recommend to use DNSSEC to authenticate the data across this connection.
(In reply to Wouter Wijngaards from comment #1)
> Yes the ssl-upstream feature wraps traffic in tls, but does not verify
> certificates. It's documented.
Hm, the documentation of this gap wasn't clear to me. I did not see any mention of lack of verification in unbound.conf (i inferred it from the behavior of the tool)
> For authentication, perhaps we could see
> what the dprive IETF WG comes up with in their standardisation? They are
> currently working on dns over tls. I would not want to pre-empt their
Please do not wait on output from dprive; You will not pre-empt anything. If anything, dprive needs input from real-world deployments (which unbound can provide) to drive its decision-making process.
> I would recommend to use DNSSEC to authenticate the data across this
That would be a great step as well, though it is perhaps a chicken-and-egg solution (how do we get the DNSSEC info if all we have is a TLS connection to the upstream server?).
Getting started with something simple like (A) or (B) proposed above would be much more straightforward, and could be overridden by a DNSSEC-verification mechanism (maybe via a TLS extension?) in the future.
Would you be interested in a patch for proposal (A)?
There is some additional information in authenticating dns over tls servers here:
In particular, they propose using SRV records, as long as DNSSEC is verified, or spki's to, if I am understanding correctly, verify the certificate's name.
There is some additional info on authentication here:https://tools.ietf.org/html/draft-ietf-dprive-dtls-and-tls-profiles-01#section-5
In particular, they propose using srv records to authenticate the hosts on the certificate or spki
Example service records (for TLS and DTLS respectively):
_domain-s._tcp.dns.example.com. SRV 0 1 853 dns1.example.com.
_domain-s._tcp.dns.example.com. SRV 0 1 853 dns2.example.com.
_domain-s._udp.dns.example.com. SRV 0 1 853 dns3.example.com.
Hi Matt, Daniel,
The issue is that there is no good proposal in that list in that document. All of them require some sort of pre-distributed keys (hard-coded keys are a recipe for failure), or in fact pre-coded something else (what you use to look up that DNSSEC stuff). All of that only works for hardcoded 'use this public resolver' and not actually for the normal resolving cases.
I would like to have code that implements authentication. Preferably in a good way (eg. won't cause further problems, I mean keys can change, you know, like X509 certificates allow key changes). It is just that all the current proposals are bad, and a lot a similar, they simply fail to be usable. Because they are all similarly bad, eg. only for public resolvers, not enabled by default, not for 10.0.0.0/8 resolvers, and so on. I don't want to move ahead of the vetted 'this is the correct solution', because I cannot choose and I do not want to choose a bad security solution.
So, anyway, that stuff is in progress. And in the document the actual problem changed to 'public resolver', 'fixed destination' and 'pre-configured parameters'. Which is vastly different from the workgroup mission, DNS privacy, which starts somewhere when you log on. And this has mostly 10.0.0.0/8 (LAN) DNS, with no authenticated components.
So, in summary, I want good security too, but the proposals are bad, and I don't want to implement 'too early' a bad solution.
Best regards, Wouter