Hi Philip Thanks very much for this educational reply. I only enabled use of the 'HIGH' keyword during this debugging period. I plan to name several strong ciphers explicitly, once I get things working.
Looking at https://man7.org/linux/man-pages/man5/slapd-config.5.html, I see the ' olcTLSECName ' directive documented: olcTLSDHParamFile: <filename> This directive specifies the file that contains parameters for Diffie-Hellman ephemeral key exchange. This is required in order to use a DSA certificate on the server, or an RSA certificate missing the "key encipherment" key usage. Note that setting this option may also enable Anonymous Diffie-Hellman key exchanges in certain non- default cipher suites. Anonymous key exchanges should generally be avoided since they provide no actual client or server authentication and provide no protection against man-in-the-middle attacks. You should append "!ADH" to your cipher suites to ensure that these suites are not used. olcTLSECName: <name> Specify the name of the curve(s) to use for Elliptic curve Diffie-Hellman ephemeral key exchange. This option is only used for OpenSSL. This option is not used with GnuTLS; the curves may be chosen in the GnuTLS ciphersuite specification. olcTLSProtocolMin: <major>[.<minor>] but in the slapd-config man page that comes with the openldap2-2.4.41-22.16.1.x86_64 distribution available in SLES 12 SP5, I don't see that directive documented: olcTLSDHParamFile: <filename> This directive specifies the file that contains parameters for Diffie-Hellman ephemeral key exchange. This is required in order to use a DSA certificate on the server. If multiple sets of parameters are present in the file, all of them will be processed. Note that setting this option may also enable Anonymous Diffie-Hellman key exchanges in certain non-default cipher suites. You should append "!ADH" to your cipher suites if you have changed them from the default, otherwise no certificate exchanges or verification will be done. When using GnuTLS or Mozilla NSS these parameters are always generated randomly so this directive is ignored. olcTLSProtocolMin: <major>[.<minor>] And, it appears that this directive is unknown in my environment: ldpdd041:/tmp # cat set-ecname.ldif dn: cn=config changetype: modify add: olcTLSECName olcTLSECName: secp384r1 ldpdd041:/tmp # ldapmodify -H ldapi:// -Y EXTERNAL -f set-ecname.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 modifying entry "cn=config" ldap_modify: Undefined attribute type (17) additional info: olcTLSECName: attribute type undefined ldpdd041:/tmp # Is this expected? Thanks! tl Internal Use - Confidential -----Original Message----- From: Philip Guenther <pguent...@proofpoint.com> Sent: Wednesday, April 19, 2023 7:18 PM To: Lemons, Terry Cc: openldap-technical@openldap.org Subject: Re: Use of olcTLSECName directive returns ‘wrong attibuteType’ error [EXTERNAL EMAIL] On Wed, 19 Apr 2023, Lemons, Terry wrote: > I’m attempting to modify the TLS ciphers that are used in an > openldap2-2.4.41-22.16.1.x86_64 environment in our lab, running on > SLES > 12 SP5. I’ve used the following command to set the cipher list value > to the returned value of ‘openssl ciphers HIGH’: > > ldpdd041:/tmp # cat set-ciphersuite.ldif > dn: cn=config > changetype: modify > add: olcTLSCipherSuite > olcTLSCipherSuite: HIGH > ldpdd041:/tmp # ldapmodify -H ldapi:// -Y EXTERNAL -f > set-ciphersuite.ldif SASL/EXTERNAL authentication started SASL > username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth > SASL SSF: 0 > modifying entry "cn=config" > > ldpdd041:/tmp # openssl ciphers HIGH > ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AE > S256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA > -AES256-SHA:SRP-DSS-AES-256-CBC-SHA:SRP-RSA-AES-256-CBC-SHA:SRP-AES-25 > 6-CBC-SHA:DH-DSS-AES256-GCM-SHA384:DHE-DSS-AES256-GCM-SHA384:DH-RSA-AE > S256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:DHE-DS > S-AES256-SHA256:DH-RSA-AES256-SHA256:DH-DSS-AES256-SHA256:DHE-RSA-AES2 > 56-SHA:DHE-DSS-AES256-SHA:DH-RSA-AES256-SHA:DH-DSS-AES256-SHA:DHE-RSA- > CAMELLIA256-SHA:DHE-DSS-CAMELLIA256-SHA:DH-RSA-CAMELLIA256-SHA:DH-DSS- > CAMELLIA256-SHA:AECDH-AES256-SHA:ADH-AES256-GCM-SHA384:ADH-AES256-SHA2 > 56:ADH-AES256-SHA:ADH-CAMELLIA256-SHA:ECDH-RSA-AES256-GCM-SHA384:ECDH- > ECDSA-AES256-GCM-SHA384:ECDH-RSA-AES256-SHA384:ECDH-ECDSA-AES256-SHA38 > 4:ECDH-RSA-AES256-SHA:ECDH-ECDSA-AES256-SHA:AES256-GCM-SHA384:AES256-S > HA256:AES256-SHA:CAMELLIA256-SHA:PSK-AES256-CBC-SHA:ECDHE-RSA-AES128-G > CM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE- > ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:SRP-DS > S-AES-128-CBC-SHA:SRP-RSA-AES-128-CBC-SHA:SRP-AES-128-CBC-SHA:DH-DSS-A > ES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:DH-RSA-AES128-GCM-SHA256:DH > E-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-SHA256:DHE-DSS-AES128-SHA256:DH > -RSA-AES128-SHA256:DH-DSS-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES > 128-SHA:DH-RSA-AES128-SHA:DH-DSS-AES128-SHA:DHE-RSA-CAMELLIA128-SHA:DH > E-DSS-CAMELLIA128-SHA:DH-RSA-CAMELLIA128-SHA:DH-DSS-CAMELLIA128-SHA:AE > CDH-AES128-SHA:ADH-AES128-GCM-SHA256:ADH-AES128-SHA256:ADH-AES128-SHA: > ADH-CAMELLIA128-SHA:ECDH-RSA-AES128-GCM-SHA256:ECDH-ECDSA-AES128-GCM-S > HA256:ECDH-RSA-AES128-SHA256:ECDH-ECDSA-AES128-SHA256:ECDH-RSA-AES128- > SHA:ECDH-ECDSA-AES128-SHA:AES128-GCM-SHA256:AES128-SHA256:AES128-SHA:C > AMELLIA128-SHA:PSK-AES128-CBC-SHA > ldpdd041:/tmp # > > So I had expected to see that all of these ciphers were being offered > for use by the OpenLDAP server; instead, I see that only a subset of > the list is offered: You're on the right trail for why the ciphers using the EDH/DHE and ECDHE key-exchange methods are not being offered. In addition, the authentication method of a cipher, as reported in the 4th column of "openssl ciphers -v" output, may imply a requirement for a specific type of certificate or other credential. In particular, the au=RSA ciphers require a cert+key for an RSA keypair, while au=DSS requires a DSS keypair and au=ECDSA reuqires an ECDSA cert, etc. I don't believe slapd supports configuring multiple cert+key pairs; if that's correct then you'll be limited to only supporting a subset of the ciphers at any given time. WARNING: you see those ADH-* ciphers in your list, like ADH-AES256-GCM-SHA384? Be aware that those are _unauthenticated_ ciphers suites. Since they don't authenticate the server (no cert used at all), they are subject to Machine-in-the-Middle attack. (In openssl-style cipher specs, 'HIGH' is only a requirement on the symmeteric cipher strength and says nothing about other security properties like authentication and forward-security. In practice, if any sort of confidential data in on the server or non-anonymous binds are used then you should almost certainly either a) list the specific ciphers you want to permit, or b) at the very least exclude unauthenticated ciphers, ala olcTLSCipherSuite: HIGH!aNULL If you believe you know what you're doing is safe then sure, go wild...) Philip Guenther
