dnsdist 1.3.x local console no longer seems to work without using setKey()

[aj-gh]

• Program: dnsdist
• Issue type: Bug report

Short description

Local console commands on dnsdist 1.2.x worked without having to use setKey() - in 1.3.x it seems that setKey() is required, otherwise the console client does not work at all and closes the command connection. dnsdist itself logs "Could not decrypt message".
Improvement of console output on mismatched keys is requested in #6683.

Environment

• Operating system: Ubuntu 16.04
• Software version: dnsdist 1.3.0-1pdns.xenial
• Software source: PowerDNS repository

Steps to reproduce

1. Create dnsdist.conf with controlSocket("127.0.0.1") but without setKey()
2. Start dnsdist and attempt to connect to the console with -c
3. Compare to behavior of 1.2.x with the same config, then 1.3.x with setKey() configured

Expected behaviour

Local console access working even without using setKey()

Actual behaviour

Local console access fails in 1.3.x without setKey() but works in 1.2.x

[rgacogne]

Hi, thanks for reporting this! Using the console without setKey() doesn't work when dnsdist has been compiled with libsodium support enabled, and that hasn't changed between 1.2.x and 1.3.0. We did however change libsodium's default detection from no to auto, meaning that it's now automatically enabled if the library is present.
I'm not 100% sure on how to fix this, we could make the console work without any defined key regardless of whether libsodium support is enabled, but this would have security implications, even on localhost where it would allow any user to connect to the console.

[hlindqvist]

Isn't it a good thing if it always requires a key to allow console connections? (With appropriate error messages, of course)

[aj-gh]

@rgacogne, well, it seems it did work here ;)

# dnsdist --version
dnsdist 1.2.0 (Lua 5.1.4)
Enabled features: dnscrypt libsodium protobuf re2 systemd
# grep -i setkey /etc/dnsdist/dnsdist.conf
# dnsdist -c
> showVersion();
dnsdist 1.2.0
>

@hlindqvist, I'm also fine with it requiring a key locally but then I'd propose a few documentation changes because at the moment the docs only strongly suggest to enable encryption (setKey) when using remote connections, not that everything including local would fail when not having used setKey().
I agree that enforcing a key makes sense when having untrusted local users.

[rgacogne]

Fixed by #6715.