TLS and local unbound-control

Unbound
1

Hi all,

(Please bear with me in the following; some of this might be mere correlation and not causation.)

I've recently switched from OpenSSL 0.9.8 to 1.0.1. I've noticed that my unbound-control commands now take significantly longer to complete. The "stats" command in particular takes ~3 seconds on my (mediocre) hardware.

Looking at unbound-control.c, it seem like it's always using TLS to communicate with the unbound process, even though I use local sockets i.e.
  control-interface: /var/unbound/control-0

Am I reading the code correctly here?

If so, it seems silly to use TLS on such a connection. Is there a config setting that would avoid using TLS?

(I haven't done a rigorous A/B test to see if the different OpenSSL version is really causing the slowdown. Maybe the older version was just using lighter crypto. But I might be barking up the completely wrong tree.)

On a related note, I am contemplating using stats_shm instead anyway, though I'm a little concerned about its connection to statistics-interval and logging. That is, statistics-interval also sets the frequency at which the stats are logged. If I want a small shm-update interval, I'm a tiny bit concerned about the extra packets being thrown at syslogd (even if they're ignored). Especially if I'm running dozens of unbounds on some beefy-but-busy hardware.

So I'd like to request that: (a) unbound-control avoids using TLS when communicating over a local socket; and (b) there be a config setting to control only the shm stats update frequency, without the extra cruft of statistics-interval.

Does that sound reasonable?

Thanks,

    M.

2

Hi Marc,

3

(Sorry for the duplicate, Simon -- replying to the list this time.)

Thanks, I'd neglected to mention my remote config. I do have that already set to no:

  remote-control:
    control-enable: yes
    control-use-cert: no

Thanks,

    M.

4

Hi all,

(Please bear with me in the following; some of this might be mere correlation and not causation.)

I've recently switched from OpenSSL 0.9.8 to 1.0.1. I've noticed that my unbound-control commands now take significantly longer to complete. The "stats" command in particular takes ~3 seconds on my (mediocre) hardware.

Sorry, that should be ~0.7 seconds! My brain's already on the weekend...

    M.

5

I just tested "control-use-cert: no" locally. `unbound-control status`
says "options: control(ssl)" but strace'ing the process shows no access
to the control cert/key. Toggling it to yes shows it in strace. So it
seems to work here despite having misleading status output.

Simon

6

Hi Marc,

Hi Marc,

So I'd like to request that: (a) unbound-control avoids using TLS when
communicating over a local socket

You can use "control-use-cert: no" in the remote-control section.

The code tries to set the eNULL cipher, that would not have the
slowdown. In openssl 1.1.0 it then sets SSL_CTX_set_security_level(0)
and this allows the eNULL cipher. At 1.0.0 that call is not available.
At 1.1.1 the TLSv1.3 doesn't allow eNULL, or securitylevel0, and the
code sets TLSv1.2 too.

So, if you upgrade openssl, the problem may go away, as eNULL likely
doesn't tax the machine so much. An option to not write lines to log
when the stats timeout is reached is certainly possible;
shm-squelch-stats-to-log or so? Or should shm enabled always squelch
stats written to log, unless verbosity is suitably high (4 or so) ?

Best regards, Wouter

7

Hi Marc,

So I'd like to request that: (a) unbound-control avoids using TLS when
communicating over a local socket

(sorry for the late reply), I'd quite like that too...

You can use "control-use-cert: no" in the remote-control section.

(Sorry for the duplicate, Simon -- replying to the list this time.)

Thanks, I'd neglected to mention my remote config. I do have that
already set to no:

        remote-control:
               control-enable: yes
               control-use-cert: no

I just tested "control-use-cert: no" locally. `unbound-control status`
says "options: control(ssl)" but strace'ing the process shows no access
to the control cert/key. Toggling it to yes shows it in strace. So it
seems to work here despite having misleading status output.

It doesn't use a cert, but it does use SSL.