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/> ) at 2016-04-27 17:37 EDT
Nmap scan report for rtpvxl0077.watson.local (10.110.76.242)
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 ) 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

Reply via email to