Hi Rob, I stopped IPA, modified dse.ldif, restarted with the cipher list and it started without issue however Same 13 ciphers. You know.. thinking about this now.. I going to try something. The box I am testing on it a replica master and not the first replica. I did not think this would make a difference since I removed the replica from the realm before testing but maybe it will not change anything thinking its stuck in the old realm?
Starting Nmap 5.51 ( http://nmap.org ) at 2016-04-29 11:51 EDT Nmap scan report for Host is up (0.000082s latency). PORT STATE SERVICE 636/tcp open ldapssl | ssl-enum-ciphers: | TLSv1.2 | Ciphers (13) | SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA | SSL_RSA_FIPS_WITH_DES_CBC_SHA | TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA | TLS_RSA_EXPORT1024_WITH_RC4_56_SHA | TLS_RSA_WITH_3DES_EDE_CBC_SHA | TLS_RSA_WITH_AES_128_CBC_SHA | TLS_RSA_WITH_AES_128_CBC_SHA256 | TLS_RSA_WITH_AES_128_GCM_SHA256 | TLS_RSA_WITH_AES_256_CBC_SHA | TLS_RSA_WITH_AES_256_CBC_SHA256 | TLS_RSA_WITH_DES_CBC_SHA | TLS_RSA_WITH_RC4_128_MD5 | TLS_RSA_WITH_RC4_128_SHA | Compressors (1) dn: cn=encryption,cn=config objectClass: top objectClass: nsEncryptionConfig cn: encryption nsSSLSessionTimeout: 0 nsSSLClientAuth: allowed nsSSL2: off nsSSL3: off creatorsName: cn=server,cn=plugins,cn=config modifiersName: cn=directory manager createTimestamp: 20150420131850Z modifyTimestamp: 20150420131906Z nsSSL3Ciphers: -rsa_null_md5,-rsa_rc4_128_sha,-rsa_rc4_128_md5,-rsa_rc4_40_md5 ,-rsa_rc2_40_md5,-rsa_des_sha,-rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_ sha,-fortezza,-fortezza_rc4_128_sha,-fortezza_null,-tls_rsa_export1024_with_r c4_56_sha,-tls_rsa_export1024_with_des_cbc_sha numSubordinates: 1 Sean Hogan Security Engineer Watson Security & Risk Assurance Watson Cloud Technology and Support email: scho...@us.ibm.com | Tel 919 486 1397 From: Rob Crittenden <rcrit...@redhat.com> To: Sean Hogan/Durham/IBM@IBMUS, Noriko Hosoi <nho...@redhat.com> Cc: freeipa-users@redhat.com Date: 04/29/2016 08:30 AM Subject: Re: [Freeipa-users] IPA vulnerability management SSL Sean Hogan wrote: > Hi Noriko, > > Thanks for the suggestions, > > I had to trim out the GCM ciphers in order to get IPA to start back up > or I would get the unknown cipher message The trick is getting the cipher name right (it doesn't always follow a pattern) and explicitly disabling some ciphers as they are enabled by default. Try this string: -rsa_null_md5,-rsa_rc4_128_sha,-rsa_rc4_128_md5,-rsa_rc4_40_md5,-rsa_rc2_40_md5,-rsa_des_sha,-rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha,-fortezza,-fortezza_rc4_128_sha,-fortezza_null,-tls_rsa_export1024_with_rc4_56_sha,-tls_rsa_export1024_with_des_cbc_sha I have an oldish install but I think it will still do what you need: 389-ds-base-1.2.11.15-68.el6_7.x86_64 Starting Nmap 7.12 ( https://nmap.org ) at 2016-04-29 11:24 EDT Nmap scan report for pacer.example.com (192.168.126.2) Host is up (0.00053s latency). PORT STATE SERVICE 636/tcp open ldapssl | ssl-enum-ciphers: | TLSv1.2: | ciphers: | TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A | TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 2048) - A | TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 2048) - A | SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C | TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C | compressors: | NULL | cipher preference: server |_ least strength: C Nmap done: 1 IP address (1 host up) scanned in 0.19 seconds $ sslscan pacer.example.com:636 |grep Accept Accepted TLSv1 256 bits AES256-SHA Accepted TLSv1 128 bits AES128-SHA Accepted TLSv1 112 bits DES-CBC3-SHA Accepted TLS11 256 bits AES256-SHA Accepted TLS11 128 bits AES128-SHA Accepted TLS11 112 bits DES-CBC3-SHA Accepted TLS12 256 bits AES256-SHA256 Accepted TLS12 256 bits AES256-SHA Accepted TLS12 128 bits AES128-GCM-SHA256 Accepted TLS12 128 bits AES128-SHA256 Accepted TLS12 128 bits AES128-SHA Accepted TLS12 112 bits DES-CBC3-SHA rob > > Nmap is still showing the same 13 ciphers as before though like nothing > had changed and I did ipactl stop, made modification, ipactl start > > tarting Nmap 5.51 ( http://nmap.org <http://nmap.org/> ) at 2016-04-28 > 18:44 EDT > Nmap scan report for > Host is up (0.000053s latency). > PORT STATE SERVICE > 636/tcp open ldapssl > | ssl-enum-ciphers: > | TLSv1.2 > | Ciphers (13) > | SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA > | SSL_RSA_FIPS_WITH_DES_CBC_SHA > | TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA > | TLS_RSA_EXPORT1024_WITH_RC4_56_SHA > | TLS_RSA_WITH_3DES_EDE_CBC_SHA > | TLS_RSA_WITH_AES_128_CBC_SHA > | TLS_RSA_WITH_AES_128_CBC_SHA256 > | TLS_RSA_WITH_AES_128_GCM_SHA256 > | TLS_RSA_WITH_AES_256_CBC_SHA > | TLS_RSA_WITH_AES_256_CBC_SHA256 > | TLS_RSA_WITH_DES_CBC_SHA > | TLS_RSA_WITH_RC4_128_MD5 > | TLS_RSA_WITH_RC4_128_SHA > | Compressors (1) > |_ uncompressed > > Nmap done: 1 IP address (1 host up) scanned in 0.21 seconds > > Current Config: > > dse.ldif > dn: cn=encryption,cn=config > objectClass: top > objectClass: nsEncryptionConfig > cn: encryption > nsSSLSessionTimeout: 0 > nsSSLClientAuth: allowed > nsSSL2: off > nsSSL3: off > creatorsName: cn=server,cn=plugins,cn=config > modifiersName: cn=directory manager > createTimestamp: 20150420131850Z > modifyTimestamp: 20150420131906Z > nsSSL3Ciphers: > -rsa_null_md5,-rsa_null_sha,-rsa_null_sha,-rsa_rc4_56_sha,-tls_ > rsa_export1024_with_rc4_56_sha,-tls_dhe_dss_1024_rc4_sha,+tls_rsa_aes_128_sha > ,+rsa_aes_128_sha,+tls_dhe_dss_aes_128_sha,+tls_dhe_rsa_aes_128_sha,+tls_rsa_ > aes_256_sha,+rsa_aes_256_sha > numSubordinates: 1 > > > nss.conf > # SSL 3 ciphers. SSL 2 is disabled by default. > NSSCipherSuite > -rsa_null_md5,-rsa_null_sha,-rsa_null_sha,-rsa_rc4_56_sha,-tls_rsa_export1024_with_rc4_56_sha,-tls_dhe_dss_1024_rc4_sha,+tls_rsa_aes_128_sha,+rsa_aes_128_sha,+tls_dhe_dss_aes_128_sha,+tls_dhe_rsa_aes_128_sha,+tls_rsa_aes_256_sha,+rsa_aes_256_sha,+tls_rsa_aes_128_gcm_sha,+tls_dhe_rsa_aes_128_gcm_sha,+tls_dhe_dss_aes_128_gcm_sha > > NSSProtocol TLSv1.0,TLSv1.1,TLSv1.2 > > > Does nss.conf have anything to do with the dir srv ciphers? I know the > 389 docs says they are tied together so the way I have been looking at > it is nss.conf lists the allowed ciphers where dse.ldif lists which ones > to use for 389 from nss.conf. Is that correct? Is there any other place > where ciphers would be ignored? > > nss-3.19.1-8.el6_7.x86_64 > sssd-ipa-1.12.4-47.el6_7.4.x86_64 > ipa-client-3.0.0-47.el6_7.1.x86_64 > ipa-server-selinux-3.0.0-47.el6_7.1.x86_64 > ipa-pki-common-theme-9.0.3-7.el6.noarch > ipa-python-3.0.0-47.el6_7.1.x86_64 > ipa-server-3.0.0-47.el6_7.1.x86_64 > libipa_hbac-python-1.12.4-47.el6_7.4.x86_64 > ipa-admintools-3.0.0-47.el6_7.1.x86_64 > ipa-pki-ca-theme-9.0.3-7.el6.noarch > 389-ds-base-1.2.11.15-68.el6_7.x86_64 > 389-ds-base-libs-1.2.11.15-68.el6_7.x86_64 > > > I need to get rid of any rc4s > > Sean Hogan > Security Engineer > Watson Security & Risk Assurance > Watson Cloud Technology and Support > email: scho...@us.ibm.com | Tel 919 486 1397 > > > > > > > Inactive hide details for Noriko Hosoi ---04/28/2016 12:08:59 PM---Thank > you for including me in the loop, Ludwig. On 04/28/201Noriko Hosoi > ---04/28/2016 12:08:59 PM---Thank you for including me in the loop, > Ludwig. On 04/28/2016 04:34 AM, Ludwig Krispenz wrote: > > From: Noriko Hosoi <nho...@redhat.com> > To: Ludwig Krispenz <lkris...@redhat.com>, freeipa-users@redhat.com > Date: 04/28/2016 12:08 PM > Subject: Re: [Freeipa-users] IPA vulnerability management SSL > Sent by: freeipa-users-boun...@redhat.com > > ------------------------------------------------------------------------ > > > > Thank you for including me in the loop, Ludwig. > > On 04/28/2016 04:34 AM, Ludwig Krispenz wrote: > > If I remember correctly we did the change in default ciphers and the > option for handling in 389-ds > 1.3.3, so it would not be in RHEL6, > adding Noriko to get confirmation. > > Ludwig is right. The way how to set nsSSL3Ciphers has been changed > since 1.3.3 which is available on RHEL-7. > > This is one of the newly supported values of nsSSL3Ciphers: > > Notes: if the value contains +all, then *-<cipher>*is removed > from the list._ > __http://www.port389.org/docs/389ds/design/nss-cipher-design.html#available-by-setting-all----nss-3162-1_ > > On the older 389-ds-base including 389-ds-base-1.2.11.X on RHEL-6.X, if > "+all" is found in the value, all the available ciphers are enabled. > > To workaround it, could you try explicitely setting ciphers as follows? > nsSSL3Ciphers: > -rsa_null_md5,-rsa_null_sha,-rsa_null_sha,-rsa_rc4_56_sha,-tls_rsa_export1024_with_rc4_56_sha,-tls_dhe_dss_1024_rc4_sha, > +tls_rsa_aes_128_sha,+rsa_aes_128_sha,+tls_dhe_dss_aes_128_sha,+tls_dhe_rsa_aes_128_sha,+tls_rsa_aes_256_sha,+rsa_aes_256_sha, > +tls_rsa_aes_128_gcm_sha,+tls_dhe_rsa_aes_128_gcm_sha,+tls_dhe_dss_aes_128_gcm_sha > > Thanks, > --noriko > > On 04/28/2016 04:34 AM, Ludwig Krispenz wrote: > > wanted to add Noriko, but hit send to quickly > > On 04/28/2016 01:26 PM, Ludwig Krispenz wrote: > > On 04/28/2016 12:06 PM, Martin Kosek wrote: > On 04/28/2016 01:23 AM, Sean Hogan wrote: > Hi Martin, > > No joy on placing - in front of the RC4s > > > I modified my nss.conf to now read > # SSL 3 ciphers. SSL 2 is disabled by > default. > NSSCipherSuite > +aes_128_sha_256,+aes_256_sha_256,+ecdhe_ecdsa_aes_128_gcm_sha_256,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_sha,+ecdhe_rsa_aes_128_gcm_sha_256,+ecdhe_rsa_aes_128_sha,+ecdhe_rsa_aes_256_sha,+rsa_aes_128_gcm_sha_256,+rsa_aes_128_sha,+rsa_aes_256_sha > > > # SSL Protocol: > # Cryptographic protocols that provide > communication security. > # NSS handles the specified protocols as > "ranges", and automatically > # negotiates the use of the strongest > protocol for a connection starting > # with the maximum specified protocol > and downgrading as necessary to the > # minimum specified protocol that can be > used between two processes. > # Since all protocol ranges are > completely inclusive, and no protocol in > the > NSSProtocol TLSv1.0,TLSv1.1,TLSv1.2 > > dse.ldif > > dn: cn=encryption,cn=config > objectClass: top > objectClass: nsEncryptionConfig > cn: encryption > nsSSLSessionTimeout: 0 > nsSSLClientAuth: allowed > nsSSL2: off > nsSSL3: off > creatorsName: > cn=server,cn=plugins,cn=config > modifiersName: cn=directory manager > createTimestamp: 20150420131850Z > modifyTimestamp: 20150420131906Z > nsSSL3Ciphers: > +all,-rsa_null_sha,-rsa_rc4_56_sha,-tls_rsa_export1024_with_rc4 > > _56_sha,-tls_dhe_dss_1024_rc4_sha > numSubordinates: 1 > > > > But I still get this with nmap.. I > thought the above would remove > -tls_rsa_export1024_with_rc4_56_sha but > still showing. Is it the fact that I am not > offering > -tls_rsa_export1024_with_rc4_56_sha? If > so.. not really understanding > where it is coming from cept the +all > from DS but the - should be negating that? > > Starting Nmap 5.51 ( _http://nmap.org_ > <http://nmap.org/>_<http://nmap.org/>_ > <http://nmap.org/>) at 2016-04-27 17:37 EDT > Nmap scan report for > Host is up (0.000086s latency). > PORT STATE SERVICE > 636/tcp open ldapssl > | ssl-enum-ciphers: > | TLSv1.2 > | Ciphers (13) > | SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA > | SSL_RSA_FIPS_WITH_DES_CBC_SHA > | TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA > | TLS_RSA_EXPORT1024_WITH_RC4_56_SHA > | TLS_RSA_WITH_3DES_EDE_CBC_SHA > | TLS_RSA_WITH_AES_128_CBC_SHA > | TLS_RSA_WITH_AES_128_CBC_SHA256 > | TLS_RSA_WITH_AES_128_GCM_SHA256 > | TLS_RSA_WITH_AES_256_CBC_SHA > | TLS_RSA_WITH_AES_256_CBC_SHA256 > | TLS_RSA_WITH_DES_CBC_SHA > | TLS_RSA_WITH_RC4_128_MD5 > | TLS_RSA_WITH_RC4_128_SHA > | Compressors (1) > |_ uncompressed > > Nmap done: 1 IP address (1 host up) > scanned in 0.32 seconds > > > > It seems no matter what config I put > into nss.conf or dse.ldif nothing changes > with my nmap results. Is there supposed > to be a be a section to add TLS ciphers > instead of SSL Not sure now, CCing Ludwig who was involved in > the original RHEL-6 > implementation. If I remember correctly we did the change in default > ciphers and the option for handling in 389-ds > 1.3.3, > so it would not be in RHEL6, adding Noriko to get > confirmation. > > but the below comments about changing ciphers in > dse.ldif could help in using the "old" way to set ciphers > Just to be sure, when you are modifying > dse.ldif, the procedure > should be always following: > > 1) Stop Directory Server service > 2) Modify dse.ldif > 3) Start Directory Server service > > Otherwise it won't get applied and will get > overwritten later. > > In any case, the ciphers with RHEL-6 should be > secure enough, the ones in > FreeIPA 4.3.1 should be even better. This is for > example an nmap taken on > FreeIPA Demo instance that runs on FreeIPA 4.3.1: > > $ nmap --script ssl-enum-ciphers -p 636 > ipa.demo1.freeipa.org > > Starting Nmap 7.12 ( _https://nmap.org_ > <https://nmap.org/>) at 2016-04-28 12:02 CEST > Nmap scan report for ipa.demo1.freeipa.org > (209.132.178.99) > Host is up (0.18s latency). > PORT STATE SERVICE > 636/tcp open ldapssl > | ssl-enum-ciphers: > | TLSv1.2: > | ciphers: > | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 > (secp256r1) - A > | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA > (secp256r1) - A > | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 > (secp256r1) - A > | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA > (secp256r1) - A > | TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (dh > 2048) - A > | TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh > 2048) - A > | TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (dh > 2048) - A > | TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh > 2048) - A > | TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (dh > 2048) - A > | TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa > 2048) - A > | TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A > | TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa > 2048) - A > | TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A > | TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa > 2048) - A > | compressors: > | NULL > | cipher preference: server > |_ least strength: A > > Nmap done: 1 IP address (1 host up) scanned in > 21.12 seconds > > Martin > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go to http://freeipa.org for more info on the project > > > >
-- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project