On Thu, Jun 18, 2020 at 5:53 PM Chris Herdt <cherdt(a)umn.edu> wrote:
On Wed, Jun 17, 2020 at 8:52 AM Mark Reynolds <mreynolds(a)redhat.com>
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 <cherdt(a)umn.edu> 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 -- freeipa-users(a)lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org
> 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/freeipa-users@lists.fedoraho...
>
> --
>
> 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