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

[Christian Heimes]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20160129/b34121b4/attachment.sig>