On 01/08/2016 02:17 PM, Fraser Tweedale wrote: > On Fri, Jan 08, 2016 at 02:02:07PM +0100, Martin Kosek wrote: >> On 01/08/2016 01:56 PM, Fraser Tweedale wrote: >>> On Fri, Jan 08, 2016 at 01:26:57PM +0100, Martin Kosek wrote: >>>> Hi Fraser and other X.509 SMEs, >>>> >>>> I wanted to check with you on what we have or plan to have with respect to >>>> certificate/cipher strength in FreeIPA. >>>> >>>> When I visit the FreeIPA public demo for example, I usually see following >>>> errors with recent browsers: >>>> >>>> * Your connection to ipa.demo1.freeipa.org is encrypted using obsolete >>>> cypher >>>> suite. >>>> - The connection uses TLS 1.2 >>>> - The connection is encrypted ising AES_128_CBC, with HMAC-SHA1 for >>>> message >>>> authentication and RSA as the key exchange mechanism >>>> >>> This is a cipher suite / ordering issue, not related to certificate. >>> >>>> I usually do not see the common >>>> * Certificate chain contains a certificate signed with SHA-1 >>>> error, but I am not sure if we are covered for this one. >>>> >>> We are using sha256 for IPA CA and default profiles. Customers >>> could still modify the profile or add profiles to sign using an >>> obsolete hash, if they wanted to, but our default is good. >>> >>>> >>>> When I tested the FreeIPA demo with >>>> https://www.ssllabs.com/ssltest/analyze.html?d=ipa.demo1.freeipa.org >>>> (and ignore the trust issues), we get the mark B with following warnings: >>>> >>>> * This server accepts RC4 cipher, but only with older protocol versions. >>>> Grade >>>> capped to B. >>>> >>>> * The server does not support Forward Secrecy with the reference browsers. >>>> >>> Again a cipher suite tweak will address this. >>> >>>> >>>> What do we miss to turn out Grade A, which is obviously something expected >>>> from >>>> security solution like FreeIPA? Is it just about ECC support >>>> (https://fedorahosted.org/freeipa/ticket/3951) or also maybe some change >>>> to our >>>> default certificate profiles? >>>> >>> Based on what you've written, it is just the cipher suite that needs >>> changing, and maybe a setting about favouring server cipher order >>> over client order. ECC certificate support is not needed (yet) and >>> the default profile is fine, w.r.t. hash used for signing. >>> >>> One important modern certificate requirement is to always include a >>> SAN dnsName for the subject, as required by RFC 2818; this is ticket >>> #4970 and it is on my radar. >>> >>> Cheers, >>> Fraser >> >> Should I then file a ticket to fix the cipher suite? (I did not fully >> understand the specifics though). >> > Yes. I have not checked yet, but we are possibly using > stock-standard mod_nss configuration (as shipped by the RPM). If > so, we should file a ticket against mod_nss to improve their > defaults.
Right. In nss.conf, I see this default cipher suite: NSSCipherSuite +rsa_rc4_128_md5,+rsa_rc4_128_sha,+rsa_3des_sha,-rsa_des_sha,-rsa_rc4_40_md5,- rsa_rc2_40_md5,-rsa_null_md5,-rsa_null_sha,+fips_3des_sha,-fips_des_sha,-fortezza,-fortezza_rc4_128_sha,-fortezza_null,-rsa_des_56_sha,-rsa_rc4_56_sha,+rsa_aes_128_sha,+rsa_aes_256_sha It certainly makes me little nervous. In 389-ds-base case, we had a similar list and solved it my using the list directly from NSS: https://fedorahosted.org/389/ticket/47838 https://fedorahosted.org/freeipa/ticket/4395 CCing Rob here. -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
