Hello, we installed the standard OpenLDAP package on Debian 11. Checking the TLS ciphers offered by the server we could see that all six Camellia ciphers are gone (128 and 256, for TLS 1.0, 1.1, 1.2) compared with the standard OpenLDAP package on Debian 9.
Is this special to the Debian package? Or: Has Gnutls changed something?
We did run into this issue because some special devices (e.G. Cisco Prime Collaboration Assurance) cannot connect to the new OpenLDAP server. The server logfile states: TLS handshake: negotiation failure. It's not yet clear whether they really can "speak" only Camellia ...
Regards Jochen.
Jochen Keutel wrote:
Hello, we installed the standard OpenLDAP package on Debian 11. Checking the TLS ciphers offered by the server we could see that all six Camellia ciphers are gone (128 and 256, for TLS 1.0, 1.1, 1.2) compared with the standard OpenLDAP package on Debian 9.
Is this special to the Debian package? Or: Has Gnutls changed something?
Sounds like a question for Debian or Gnutls communities.
We did run into this issue because some special devices (e.G. Cisco Prime Collaboration Assurance) cannot connect to the new OpenLDAP server. The server logfile states: TLS handshake: negotiation failure. It's not yet clear whether they really can "speak" only Camellia ...
Regards Jochen.
Am 30.07.22 um 20:46 schrieb Jochen Keutel:
We did run into this issue because some special devices (e.G. Cisco Prime Collaboration Assurance) cannot connect to the new OpenLDAP server. The server logfile states: TLS handshake: negotiation failure. It's not yet clear whether they really can "speak" only Camellia ...
it's called "openssl security level". Debian 11 defaults to seclevel=2, camellia cipher are available in the seclevel=1
$ grep PRETTY_NAME /etc/os-release PRETTY_NAME="Debian GNU/Linux 11 (bullseye)"
$ openssl ciphers -v | grep -i camellia | wc -l 0
$ openssl ciphers -v 'ALL;@SECLEVEL=1' | grep -i camellia | wc -l 28
Andreas
--On Saturday, July 30, 2022 10:10 PM +0200 "A. Schulze" sca@andreasschulze.de wrote:
Am 30.07.22 um 20:46 schrieb Jochen Keutel:
We did run into this issue because some special devices (e.G. Cisco Prime Collaboration Assurance) cannot connect to the new OpenLDAP server. The server logfile states: TLS handshake: negotiation failure. It's not yet clear whether they really can "speak" only Camellia ...
it's called "openssl security level". Debian 11 defaults to seclevel=2, camellia cipher are available in the seclevel=1
$ grep PRETTY_NAME /etc/os-release PRETTY_NAME="Debian GNU/Linux 11 (bullseye)"
$ openssl ciphers -v | grep -i camellia | wc -l 0
$ openssl ciphers -v 'ALL;@SECLEVEL=1' | grep -i camellia | wc -l 28
As far as I'm aware, both Debian and Ubuntu continue to link OpenLDAP to GnuTLS, so pointing out how openssl behaves probably doesn't help them progress much. I'm guessing though that similar changes were done to the GnuTLS defaults.
--Quanah
Am 01.08.22 um 16:30 schrieb Quanah Gibson-Mount:
As far as I'm aware, both Debian and Ubuntu continue to link OpenLDAP to GnuTLS, so pointing out how openssl behaves probably doesn't help them progress much. I'm guessing though that similar changes were done to the GnuTLS defaults.
right! As Quanah mentioned, OpenLDAP on Debian uses GnuTLS. see https://packages.debian.org/bullseye/libldap-2.4-2 So, sorry for my noise about OpenSSL...
Andreas
Hello, thanks very much for your hints. Unfortunately, I couldn't solve the problem so far ... What I've tried:
- create /etc/gnutls/config with content:
[overrides] default-priority-string = NORMAL:+CAMELLIA-256-GCM:+CAMELLIA-256-CBC
- set and export GNUTLS_SYSTEM_PRIORITY_FILE=/etc/gnutls/config and start slapd directly from this shell
- setting various strings for TLSCipherSuite in slapd.conf (e.g. the string mentioned above)
Nothing helps ... Still Camellia is not offered by slapd.
Does OpenLDAP use a different GnuTLS priority file than /etc/gnutls/config? Does OpenLDAP (or the libgnutls used by OpenLDAP) use the priority file at all?
I've found in the code (./libraries/libldap/tls_g.c, line 110 (OpenLDAP 2.5.13):
gnutls_priority_init( &ctx->prios, "NORMAL", NULL );
Does this mean that OpenLDAP always uses NORMAL independent on priority file? (This could explain the behaviour - if "NORMAL" on Debian 11 is restricted than you get less cipher suites than on Debian 10 and before.)
Regards Jochen.
Am 01.08.2022 um 19:11 schrieb A. Schulze:
Am 01.08.22 um 16:30 schrieb Quanah Gibson-Mount:
As far as I'm aware, both Debian and Ubuntu continue to link OpenLDAP to GnuTLS, so pointing out how openssl behaves probably doesn't help them progress much. I'm guessing though that similar changes were done to the GnuTLS defaults.
right! As Quanah mentioned, OpenLDAP on Debian uses GnuTLS. see https://packages.debian.org/bullseye/libldap-2.4-2 So, sorry for my noise about OpenSSL...
Andreas
--On Wednesday, August 3, 2022 5:03 PM +0200 Jochen Keutel mlists@keutel.de wrote:
Hello, thanks very much for your hints. Unfortunately, I couldn't solve the problem so far ... What I've tried:
Honestly, I'd advise using an OpenLDAP that's linked to OpenSSL (and from a current supported release series, which the Debian 11 build are not).
Both Symas (https://repo.symas.com) and the LTB project (https://ltb-project.org/download.html) offer no-charge current builds of OpenLDAP for Debian11 that are based on OpenSSL.
Regards, Quanah
On Sat, Jul 30, 2022 at 2:47 PM Jochen Keutel mlists@keutel.de wrote:
Hello, we installed the standard OpenLDAP package on Debian 11. Checking the TLS ciphers offered by the server we could see that all six Camellia ciphers are gone (128 and 256, for TLS 1.0, 1.1, 1.2) compared with the standard OpenLDAP package on Debian 9.
Is this special to the Debian package? Or: Has Gnutls changed something?
We did run into this issue because some special devices (e.G. Cisco Prime Collaboration Assurance) cannot connect to the new OpenLDAP server. The server logfile states: TLS handshake: negotiation failure. It's not yet clear whether they really can "speak" only Camellia ...
They may be removed due to lack of support for RFC 6367. I _think_ that may be the case for TLS 1.3. If I am not mistaken, TLS 1.3 removed lesser used cipher suites, like ARIA, Camellia and IDEA. Cf., https://www.redhat.com/en/blog/transport-layer-security-version-13-red-hat-e... . And according to IANA, AEAD ciphers are not defined for Camellia. Cf., https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-par... .
Try running `gnutls-cli -l` or `gnutls-cli-debug <host>` and see what is supported.
Jeff
openldap-technical@openldap.org
-
A. Schulze -
Howard Chu -
Jeffrey Walton -
Jochen Keutel -
Quanah Gibson-Mount