Unable to specify only TLSv1.3 ciphersuites in named.conf
Summary
We recently played around with XoT and discovered that we were unable to configure only TLSv1.3 ciphersuites in the tls
section of named.conf
, even though we specified TLSv1.3 as the only protocol.
This is rather low priority (since to my knowledge all of the TLSv1.3 ciphersuites are considered secure for the time being), but it is at least unexpected behaviour.
BIND version used
BIND 9.18.6 (Stable Release) <id:8dbd488>
running on Linux x86_64 3.10.0-1160.71.1.el7.x86_64 #1 SMP Tue Jun 28 15:37:28 UTC 2022
built by make with '--prefix=/usr/local/denic-bind918-9.18.6' '--exec-prefix=/usr/local/denic-bind918-9.18.6' '--bindir=/usr/local/denic-bind918-9.18.6/bin' '--sbindir=/usr/local/denic-bind918-9.18.6/bin' '--libexecdir=/usr/local/denic-bind918-9.18.6/lib' '--localstatedir=/var' '--without-libxml2' '--enable-full-report' '--with-tuning=large' '--disable-doh' '--disable-geoip' '--disable-auto-validation' '--with-openssl=/usr' 'LIBUV_CFLAGS= ' 'LIBUV_LIBS=-luv -ldl ' 'OPENSSL_CFLAGS=-I/usr/include/openssl11' 'OPENSSL_LIBS=-L/usr/lib64/openssl11 -lssl -lcrypto'
compiled by GCC 4.8.5 20150623 (Red Hat 4.8.5-44)
compiled with OpenSSL version: OpenSSL 1.1.1k FIPS 25 Mar 2021
linked to OpenSSL version: OpenSSL 1.1.1k FIPS 25 Mar 2021
compiled with libuv version: 1.44.2
linked to libuv version: 1.44.2
compiled with json-c version: 0.11
linked to json-c version: 0.11
compiled with zlib version: 1.2.7
linked to zlib version: 1.2.7
threads support is enabled
default paths:
named configuration: /usr/local/denic-bind918-9.18.6/etc/named.conf
rndc configuration: /usr/local/denic-bind918-9.18.6/etc/rndc.conf
DNSSEC root key: /usr/local/denic-bind918-9.18.6/etc/bind.keys
nsupdate session key: /var/run/named/session.key
named PID file: /var/run/named/named.pid
named lock file: /var/run/named/named.lock
Steps to reproduce
try to start named
with a named.conf
containing only TLSv1.3 ciphersuites in a tls
block's cipher
key.
What is the current bug behavior?
named
does not start because the named.conf
validation fails ("'ciphers' in the 'tls' clause 'tlsclients' is not a valid cipher list string")
What is the expected correct behavior?
named
sets the specified TLSv1.3 ciphersuites and starts.
Relevant configuration files
Using the following tls
block in named.conf will trigger the observed behaviour:
tls tlsclients {
key-file "/path/to/key";
cert-file "/path/to/cert";
protocols { TLSv1.3; };
ciphers "TLS_AES_256_GCM_SHA384";
dhparam-file "/path/to/dhparam";
prefer-server-ciphers yes;
session-tickets no;
};
# same with ciphers "TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256"
If we append some ciphers (TLSv1.2-Style), the check succeeds and named
starts:
tls tlsclients {
key-file "/path/to/key";
cert-file "/path/to/cert";
protocols { TLSv1.3; };
ciphers "TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256";
dhparam-file "/path/to/dhparam";
prefer-server-ciphers yes;
session-tickets no;
};
(Realized that the dhparam-file is not needed if we use TLSv1.3 only, but leaving it in here in case it might be relevant to the observed behaviour)
Possible fixes
We suspect that this is due to the use of SSL_CTX_set_cipher_list()
in the validation function isc_tls_cipherlist_valid()
- according to the OpenSSL manpages, this function can only set the ciphers for TLSv1.2 and below, whereas SSL_CTX_set_ciphersuites()
can be used to set ciphersuites for TLSv1.3.
Maybe we can pass the cipher string to both Functions and return true
if either of them returns 1
?