Local control socket; www.unbound.net certificate

Unbound
1

unbound-control uses public-key authentication and TLS to communicate
with the Unbound daemon. Why not just use a local-domain socket?

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).

By the way, when I point a web browser at <https://www.unbound.net/&gt;,
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.

2

Hi Taylor,

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 (127.0.0.1) 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/&gt;,
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 :slight_smile:

Best regards,
   Wouter

3

Hello Wouter,

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 :slight_smile:

CAcert is a really interesting concept and judging by their news page,
their even seems to be some progress again.

But DNSSEC has much more potential, especially because the root is
already signed and because DNS delegates authority.

Chromium does have the --enable-dnssec-certs option so that is a start,
but it's experimental.

I think OpenSSH is the only application at this point which supports the
dnssec and in this case with SSHFP-RR.

But I do wonder when we can really start to see some kind of widespread
deployment other then to fight something like the "Kaminsky attack".

DNSSEC can be used for so much more.

4

Chromium does have the --enable-dnssec-certs option so that is a start,
but it's experimental.

What does that option do? As there is no real standard yet...

I think OpenSSH is the only application at this point which supports the
dnssec and in this case with SSHFP-RR.

openswan supports raw RSA keys for IPsec in DNS.

DNSSEC can be used for so much more.

It's coming, but it will take a few more months.

Paul

5

Chromium does have the --enable-dnssec-certs option so that is a start,
but it's experimental.

What does that option do? As there is no real standard yet...

It does a number of checks from this page:
http://www.imperialviolet.org/2010/08/16/dnssectls.html

From looking at the wire, I see a request for the TXT RR with DO-bit set

and EDNS0 (payload size: 4096).

I haven't checked the actual code. It's more a proof of concept I think.

I think OpenSSH is the only application at this point which supports the
dnssec and in this case with SSHFP-RR.

openswan supports raw RSA keys for IPsec in DNS.

Forgot about that one. Opportunistic encryption, I don't think anyone
else implemented that and openswan is not in the mainline kernel. So it
isn't widely deployed, which is to bad. It's an interresting idea.