On Thu, Jun 18, 2020 at 5:53 PM Chris Herdt <[email protected]> wrote: > > > On Wed, Jun 17, 2020 at 8:52 AM Mark Reynolds <[email protected]> > wrote: > >> >> On 6/16/20 6:07 PM, Chris Herdt via FreeIPA-users wrote: >> >> >> >> On Tue, Jun 16, 2020 at 12:58 PM Chris Herdt <[email protected]> wrote: >> >>> I have an appliance that I want to use with our FreeIPA-provided LDAP >>> servers. The appliance only supports the following ciphers: >>> >>> TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024) >>> TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023) >>> TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a) >>> TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009) >>> >>> I tried changing the following in dse.ldif, based on >>> http://www.port389.org/docs/389ds/design/nss-cipher-design.html: >>> >>> nsSSL3Ciphers: +all >>> >> This should allow all the ciphers that the NSS supports. Keep in mind >> you do need to restart the server after changing nsSSL3Ciphers. >> >> Run this ldapsearch: >> >> # ldapsearch -D "cn=directory manager" -W -xLLL -b >> cn=encryption,cn=config nsSSLEnabledCiphers nsSSLSupportedCiphers >> >> This will show what is available to the server, and what is enabled. Do >> you see your ciphers in the available list and/or enabled list? >> > Thanks for your reply! Yes, I see the ciphers listed both in the available > and enabled lists. Excerpt: > > nsSSLEnabledCiphers: > TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384::AES::SHA384::256 > nsSSLSupportedCiphers: > TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384::AES::SHA384::2 > 56 > > However, a connection using those ciphers fails: > > openssl s_client -connect freeipa-01.example.com:636 -cipher > ECDHE-ECDSA-AES256-SHA384 > > (According to https://testssl.sh/openssl-iana.mapping.html, OpenSSL uses > ECDHE-ECDSA-AES256-SHA384 for 0xc024.) > > Additionally, the nmap script I mentioned previously checks for the > ciphers supported by the appliance (as well as others), but does not find > the matching ciphers on the LDAP server. > > It appears I overlooked an error with the openssl s_client output when > specifying the desired cipher, so I've included the output below in case it > is helpful. (I added the -servername as I saw several forum posts > indicating the error may be due to SNI.) > > $ openssl s_client -connect freeipa-01.example.com:389 -starttls ldap > -cipher ECDHE-ECDSA-AES256-SHA384 -servername freeipa-01.example.com > CONNECTED(00000003) > 140205386876816:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 > alert handshake failure:s23_clnt.c:769: > --- > no peer certificate available > --- > No client certificate CA names sent > --- > SSL handshake has read 104 bytes and written 183 bytes > --- > New, (NONE), Cipher is (NONE) > Secure Renegotiation IS NOT supported > Compression: NONE > Expansion: NONE > No ALPN negotiated > SSL-Session: > Protocol : TLSv1.2 > Cipher : 0000 > Session-ID: > Session-ID-ctx: > Master-Key: > Key-Arg : None > Krb5 Principal: None > PSK identity: None > PSK identity hint: None > Start Time: 1592520534 > Timeout : 300 (sec) > Verify return code: 0 (ok) > --- > > It appears that the 389 directory service only supports certificates that use the RSA signature algorithm: https://pagure.io/389-ds-base/issue/50010
Connections using any supported cipher that use the RSA signature algorithm succeed. Connections using theoretically supported ciphers that use ECDSA or DSS fail. > I should note the connection succeeds with a number of other ciphers. I > appears the server supports the ciphers, but the connection still fails. > > So can try to do: >> >> >> nsSSL3Ciphers: +all,+TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,+ >> TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,+ >> TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,+ >> TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA >> >> Restart the server, check that ldapsearch command to see if these ciphers >> are now enabled. >> >> HTH, >> >> Mark >> >> >>> However, this enabled only the following 7 ciphers (based on the output >>> of nmap --script ssl-enum-ciphers -p 636 freeipa-01.example.com): >>> >>> TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA >>> TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA >>> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 >>> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 >>> TLS_RSA_WITH_CAMELLIA_128_CBC_SHA >>> TLS_RSA_WITH_CAMELLIA_256_CBC_SHA >>> TLS_RSA_WITH_SEED_CBC_SHA >>> >>> Here's the content of the dn: cn=encryption,cn=config section: >>> >>> dn: cn=encryption,cn=config >>> CACertExtractFile: >>> /etc/dirsrv/slapd-EXAMPLE-COM/CN3dUSERTrust20RSA20Certif >>> >>> >>> ication20Authority2cO3dThe20USERTRUST20Network2cL3dJersey20City2cST3dNew20Jer >>> sey2cC3dUS.pem >>> allowWeakCipher: off >>> cn: encryption >>> createTimestamp: 20181108213233Z >>> creatorsName: cn=server,cn=plugins,cn=config >>> modifiersName: cn=server,cn=plugins,cn=config >>> modifyTimestamp: 20181108213359Z >>> nsSSL3Ciphers: +all >>> nsSSLClientAuth: allowed >>> nsSSLSessionTimeout: 0 >>> objectClass: top >>> objectClass: nsEncryptionConfig >>> sslVersionMin: TLS1.2 >>> numSubordinates: 1 >>> >>> Any ideas why this change isn't enabling the additional ciphers? Thanks! >>> >> >> I should have mentioned, my FreeIPA servers are running ipa-server 4.6.6 >> on CentOS 7.8. >> >> >> _______________________________________________ >> FreeIPA-users mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> Fedora Code of Conduct: >> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >> List Archives: >> https://lists.fedorahosted.org/archives/list/[email protected] >> >> -- >> >> 389 Directory Server Development Team >> >> > -- Chris Herdt Security Analyst | University Information Security (UIS) University of Minnesota | umn.edu | 612-301-2232 Information Security is a shared responsibility. Learn more at: https://it.umn.edu/what-security-incident he, him, his
_______________________________________________ FreeIPA-users mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/[email protected]
