[Freeipa-users] netapp unable to do ldap lookups over ssl to RHEL 7.2 ipa server

Wed Feb 3 16:35:29 UTC 2016

On 29/01/16 12:27, Christian Heimes wrote:
> On 2016-01-29 13:03, Roderick Johnstone wrote:
>> On 29/01/16 10:31, Christian Heimes wrote:
>>> On 2016-01-28 19:56, Roderick Johnstone wrote:
>>>> On 28/01/16 13:39, Christian Heimes wrote:
>>>>> On 2016-01-28 13:51, Roderick Johnstone wrote:
>>>>>> Hi
>>>>>>
>>>>>> My netapp filer is happily doing ldap over ssl lookups for account
>>>>>> information to my RHEL 6.7 testing ipa server
>>>>>> (ipa-server-3.0.0-47.el6_7.1.x86_64).
>>>>>>
>>>>>> However, when I switch the filer to use my RHEL 7.2 ipa server
>>>>>> (ipa-server-4.2.0-15.el7_2.3.x86_64) the lookup doesn't work.
>>>>>>
>>>>>> In the dirsrv log file I see entries like this:
>>>>>>
>>>>>> [28/Jan/2016:09:17:45 +0000] conn=1338 fd=112 slot=112 SSL connection
>>>>>> from xxx.xxx.xxx.xxx to yyy.yyy.yy.yyy
>>>>>> [28/Jan/2016:09:17:45 +0000] conn=1338 op=-1 fd=112 closed - Cannot
>>>>>> communicate securely with peer: no common encryption algorithm(s).
>>>>>>
>>>>>> (xxx.xxx.xxx.xxx is the filer ip address and yyy.yyy.yyy.yyy is the
>>>>>> ipa
>>>>>> server ip address).
>>>>>>
>>>>>> Looking in the ldap directory for fields with cipher in the name
>>>>>> shows a
>>>>>> very different set of nssslenabledciphers between the two ipa-server
>>>>>> versions.
>>>>>>
>>>>>> I wonder if this might be the issue?
>>>>>>
>>>>>> Can the ldap server tell me what ciphers its being requested to use by
>>>>>> the filer?
>>>>>
>>>>> Yes, it looks like it is the issue. The supported cipher suites were
>>>>> hardened a while ago. The ticket
>>>>> https://fedorahosted.org/freeipa/ticket/4395 contains more information.
>>>>>
>>>>> During the TLS handshake the client sends a list of supported cipher
>>>>> suites to the server. The server also has a list of supported cipher
>>>>> suites. But the server never sends this list to the client. Instead it
>>>>> picks one common cipher suite (usually the most secure) from the common
>>>>> set of cipher suites.
>>>>>
>>>>> I don't know if you can get 389 DS to print the cipher suites. But you
>>>>> can snoop the ciper suites from the TLS handshake with wireshark or
>>>>> tshark. The handshake isnt't encrypted and can be captures on either
>>>>> the
>>>>> host or the server.
>>>>>
>>>>> # tshark -Vx -Y "ssl.handshake.ciphersuites" -i YOUR_INTERFACE tcp port
>>>>> ldaps
>>>>>
>>>>> Christian
>>>>>
>>>>
>>>> Thanks Christian. Thats really helpful.
>>>>
>>>> Now I have a list of ciphers being asked for and I found that the ldap
>>>> server logs which ciphers its using when it starts up file
>>>> /var/log/dirsrv/slapd-<domain>/error. There isn't any overlap.
>>>>
>>>> I noticed that there is a setting in the
>>>> dn: cn=encryption,cn=config
>>>> allowWeakCipher: off
>>>>
>>>> and
>>>> nsSSL3Ciphers: +all
>>>>
>>>> and found some documentation on this here:
>>>> http://directory.fedoraproject.org/docs/389ds/design/nss-cipher-design.html
>>>>
>>>>
>>>> So, maybe I could add one (or several) of the required ciphers to
>>>> nsSSL3Ciphers or possibly as a last resort set allowWeakCipher: on?
>>>
>>> Hi Roderick,
>>>
>>> I highly recommend against lowering the settings. Weak ciphers are
>>> broken and insecure ciphers, some even with NULL encryption or no
>>> authentication. At best weak ciphers may (!) protect your against a
>>> passive sniffer and incompetent attacker. They won't protect you against
>>> a serious attack.
>>>
>>> Are you able to reconfigure or update the client? Does the client even
>>> speak TLS 1.0 to the server or is it restricted to SSLv2 and SSLv3?
>>>
>>> If you show me the complete handshake, I can give you further advice.
>>> The handshake output of tshark starts like this:
>>>
>>> Secure Sockets Layer
>>>     SSL Record Layer: Handshake Protocol: Client Hello
>>>       Content Type: Handshake (22)
>>>       Version: TLS 1.0 (0x0301)
>>>
>>> Christian
>>>
>>>
>>
>> Christian
>>
>> I don't think we have much control over the available client ciphers. We
>> are running the latest Data OnTap version for our natapps so we have
>> what we have. The netapp can do TLSv1 though.
>>
>> We do have firewalling on the ipa servers so that will help until one of
>> our trusted networks is compromised!
>>
>> I'll send you the handshake output from tshark off list.
>
> Hi Roderick,
>
> thanks for the handshake. It looks like the application initiates a
> SSLv2 handshake and then does a protocol upgrade to TLS 1.0. This alone
> makes the connection vulnerable to a man-in-the-middle attacks. You
> should disable SSLv2 and SSLv3 on the client app ASAP. The broken
> versions must be disabled on both sides.
>
> The cipher suite list is horrible, too. You don't want anything with
> SSL2, RC2, RC4, DES, DSS, DHE, MD5 or EXPORT in its name.
> TLS_RSA_WITH_3DES_EDE_CBC_SHA is the only cipher suite that is remotely
> good. 3DES is slow but not entirely broken as RC4. TLS/SSL in CBC mode
> has issues with padding, because TLS does MAC-then-encrypt.
>
> Christian
>
Christian

If I wanted to enable TLS_RSA_WITH_3DES_EDE_CBC_SHA in the LDAP server 
can you advise the best way to do that please?

I'm not quite sure how adding TLS_RSA_WITH_3DES_EDE_CBC_SHA to
nsSSL3Ciphers: +all

interacts with the
allowWeakCipher: off

ie does adding TLS_RSA_WITH_3DES_EDE_CBC_SHA to nsSSL3Ciphers: override 
its rejection in allowWeakCipher: off or do I need to set
allowWeakCipher: on and then explicitly exclude all the other weak 
ciphers in the nsSSL3Ciphers: line?

Thanks

Roderick