[Unbound-users] local control socket; www.unbound.net certificate

W.C.A. Wijngaards wouter at NLnetLabs.nl
Tue Nov 30 15:07:17 UTC 2010

Hash: SHA1

Hi Taylor,

On 11/24/2010 01:43 AM, Taylor R Campbell wrote:
> unbound-control uses public-key authentication and TLS to communicate
> with the Unbound daemon.  Why not just use a local-domain socket?

Well, by default it employs the loopback interface ( which has
similar protection - i.e. no contact possible over the internet.

> In both cases, for local use, the security is really enforced only by
> the file system's permissions model, as far as I can tell.  Using
> public-key authentication and TLS seems needlessly complicated (and
> (marginally) less secure, if the keys are not generated on boot and
> can be read from a cold disk).

Well, the daemon needs to make sure the other end is allowed and also
cache-dumps and trusted keys may benefit from encryption (for privacy),
and I wanted to use an off-the-shelf security mechanism, so TLS.  As
benefit you use this to remotely (not on localhost) administer a
nameserver by setting it from the loopback interface to public IP and
copying the certificates to another place (it is even possible to sign
multiple certs for multiple separate controllers).

So, unbound uses TLS and authenticates both ends, so the daemon is
certain that it talks to the unbound-control and unbound-control is
certain that it talks to the daemon.

That you can read the cert from the disk is not a concern - you could
also e.g. read and write the config file and the daemon binary.  So it
has similar protection to sshd, and that is what I wanted in case you
(allow and want to) approach it over the network.

> By the way, when I point a web browser at <https://www.unbound.net/>,
> the server presents an x.509 certificate with many different
> subjectAltNames, none of which is www.unbound.net.  I presume that the
> certificate (with SHA-1 hash 29309a3b12e588b108ef1132ce3d3daa3a625bcc)
> is not bogus, though, since the names are all related to nlnetlabs.nl,
> and OpenSSL happily verifies the signature from CAcert.

I apologize.  Most people would need to add an exception anyway for
CAcert, hence we did not notice this domain-name oversight in the
certificate.  I hope we can move onto a DNSSEC-secured CERT RR in the
near future :-)

Best regards,
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/


More information about the Unbound-users mailing list