NLnetLabs / nsd

The NLnet Labs Name Server Daemon (NSD) is an authoritative, RFC compliant DNS nameserver.

Home Page:https://nlnetlabs.nl/nsd

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

mutual tls authentication is not complete

bilias opened this issue · comments

nsd.conf(5) specifies:

client-cert: <file name of clientcert.pem>
              If  you  want to use mutual TLS authentication, this is where the client certificates can be configured that NSD uses to connect to the upstream server to download the zone. The client public  key  pem  cert file can be configured here. Also configure a private key with client-key.

client-key: <file name of clientkey.key>
              If  you  want  to  use  mutual  TLS authentication, the private key file can be configured here for the client authentication.

So somehow mutual auth should work, but it doesn't

Client (slave/secondary) indeed verifies servers's (master/primary) certificate by using:
tls-cert-bundle: for the server's certificate (ca store)
tls-auth: auth-domain-name: for verifying the certificate CN.

However, server accepts whatever certificate is presented by the client (in the tls-auth sertting /client-cert/client-key)

Looking at the code:
SSL_CTX* server_tls_ctx_create(struct nsd nsd, char verifypem, char* ocspfile);
is called in nsd.c:1580

if(!(nsd.tls_ctx = server_tls_ctx_create(&nsd, NULL, 
      nsd.options->tls_service_ocsp)))

So, verifypem is always NULL, thus server does not perform any authentication for the client side of the connection. This is not mutual auth, only client verifies/authenticates the tls connection.

Either the manual page has to change, or maybe put an extra tls-auth field in
provide-xfr: to force tls-auth for the client
This can by done again by looking at
tls-cert-bundle: for the client's certificate
tls-auth: auth-domain-name: for verifying the certificate CN.

Ideally each tls-auth could also include server ca-pem/cert-bundle dinstict from global tls-cert-bundle. You don't want clientA to be able to authenticate with clientB's certificate/key on server even if both are valid and listed in tls-cert-bundle.

Can provide test setup on localhost that shows the issue clearly.

Thanks again @bilias! With the changes merged, I think this can be closed?

commented

@k0ekk0ek
Yes, both sides of TLS-AUTH were covered by the merge. Can be closed.