Skip to content

Initial implementation of client side XoT.#149

Merged
wtoorop merged 7 commits into
NLnetLabs:masterfrom
ShivanKaul:xot
Jul 9, 2021
Merged

Initial implementation of client side XoT.#149
wtoorop merged 7 commits into
NLnetLabs:masterfrom
ShivanKaul:xot

Conversation

@saradickinson
Copy link
Copy Markdown
Contributor

  • Requires TLS 1.3 support
  • Uses a new tls-auth clause in the request-xfr pattern to specify the authentication domain name to use.

- Requires TLS 1.3 support
- Uses a new `tls-auth` clause in the `request-xfr` pattern to specify the authentication domain name to use.
Comment thread configparser.y Outdated
Co-authored-by: Wouter Wijngaards <wcawijngaards@users.noreply.github.com>
Comment thread tpkg/checkconf.tdir/checkconf.check2 Outdated
Comment thread xfrd-tcp.c
Comment thread xfrd-tcp.c
Comment thread xfrd-tcp.c
Comment thread xfrd-tcp.c
Comment on lines +677 to +698
// TODO: There is a nasty case where the far end is listening on TCP
// but not TLS. In that case the SSL_do_handshake function will loop,
// returning SSL_ERROR_WANT_READ for the tcp_timeout (120s). This can
// be handled various ways, not sure of the best one, need to discuss
// with Wouter...
int ret, err;
while (1) {
ERR_clear_error();
if ((ret = SSL_do_handshake(tp->ssl)) == 1) {
DEBUG(DEBUG_XFRD, 1, (LOG_INFO, "xfrd: TLS handshake sucessful"));
break;
}
err = SSL_get_error(tp->ssl, ret);
if (err != SSL_ERROR_WANT_READ && err != SSL_ERROR_WANT_WRITE) {
log_msg(LOG_ERR, "xfrd: TLS handshake failed for %s to %s with value: %d",
zone->apex_str, zone->master->ip_address_spec, err);
close(fd);
xfrd_set_refresh_now(zone);
return 0;
}
/* else wants to be called again */
}
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So I cannot see a lot wrong with this. You could add if(ret == 0) { close(fd); xfrd_set_refresh_now(zone); return 0; } before the 'else wants to be called again' line. Then it would be fairly similar to other code that does not really have this issue.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So this is indeed problematic, because it is spinning on the while loop (causing 100% cpu) and blocking the transfer daemon while doing that. This is resolved in commit 458519a (in PR #183 ) which moves the handshake into the async io based handling of the xfrd_tcp_pipe.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is the best fix! Makes the patch unproblematic for merge, in my opinion.

Comment thread xfrd-tcp.c Outdated
Comment thread xfrd-tcp.c Outdated
Comment thread xfrd-tcp.c Outdated
Comment thread xfrd-tcp.c Outdated
Comment thread xfrd-tcp.c
Comment thread xfrd-tcp.c
Comment thread xfrd-tcp.c Outdated
Comment thread xfrd-tcp.c Outdated
Comment thread xfrd-tcp.c
log_msg(LOG_ERR, "xfrd: incomplete write of tls");
break;
default:
log_msg(LOG_ERR, "xfrd: generic write problem with tls");
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be nice to print more details, either from errno, or perhaps the function log_crypto_err() for ssl details, depending on what failed. Perhaps also after other SSL_write and SSL_read and SSL_do_handshake failures.

Copy link
Copy Markdown
Member

@wcawijngaards wcawijngaards left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code looks good, would want to fix a couple of the issues that I reported (awkward typo that stops SSL_free) before merge, otherwise it looks good once you fixed things.

Re-add close(fd) instead of shutdown
@ShivanKaul
Copy link
Copy Markdown
Contributor

Hi @wcawijngaards - the git commit history on this PR became very messy with this so I begrudgingly had to cherry pick commits and force push. I believe it should address all your comments, let me know!

@wcawijngaards
Copy link
Copy Markdown
Member

You missed the item from xfrd-tcp.c line 677.

The fix commit makes three log_msg calls of type LOG_INFO. That is less then the error level, but it still spams the logs with unused messages during normal operations. For debug and verbosity messages we have higher output levels defined. Please move the log at 1065 until after the EOF check below it. Please move the log at 1016 until after the EOF check below it, it is then fine to use LOG_ERR. At 749 and 827 use something like DEBUG(DEBUG_QUERY,2, (LOG_INFO, "text")); because it is a normal operational thing that can happen for every query (in this case because of packetization of TCP content). Or just remove those incomplete write log messages.

Sara Dickinson added 3 commits March 11, 2021 13:28
- move 2 log messages to after EOF
- clean up some whitespace
…ect error line is reported and confcheck unit test now passes

Add 1 zone to confcheck unit text to include XoT
@cesarkuroiwa
Copy link
Copy Markdown

Hello

We managed to do some tests of NSD as XoT client
against our own server implementation. We'd like add a few comments.

We didn't find in the configuration how to set a path for a custom CA,
in order for the TLS handshake to succeed. So we did a small change on
the code to set our custom CA file on the SSL context.

Additionally, we find also that it would be nice if, in the "tls-auth"
section of nsd.conf, there was a possibility to set a path for the
client certificate and key as well, in case the server opts to do
client certificate verification.

@saradickinson
Copy link
Copy Markdown
Contributor Author

@cesarkuroiwa thanks for the feedback! Agreed - those are two features that are missing and it would be good to add them both to support the mTLS mode of authentication specified in the draft for XoT.

@cesarkuroiwa
Copy link
Copy Markdown

cesarkuroiwa commented May 7, 2021

If there is interest, I've made a few changes to include some configuration variables and managed to successfully request a XFR from our implemention of a XoT server using mutual TLS authentication by passing a client certificate:

xot-server...cesarkuroiwa:xot-client

@wtoorop
Copy link
Copy Markdown
Member

wtoorop commented Jul 5, 2021

@cesarkuroiwa What are you using for XoT server to authenticate the client? I think it would be nice to include mutual authentication once we have the server side for that too. I'll keep an eye on your fork :)

The custom CA is nice, but I prefer to use the same name for the option as we use in unbound, which is tls-cert-bundle

@cesarkuroiwa
Copy link
Copy Markdown

@wtoorop We tested NSD acting as a XoT client against our in-house implementation of a DNS server, which currently act as a hidden master for our zones

I believe the tls-cert-bundle approach would be fine, since we would probably use our own private root certificate

@wtoorop wtoorop merged commit c2d1b84 into NLnetLabs:master Jul 9, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants