On Fri, 08 Jan 2016, Martin Kosek wrote:
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.
Here is what I have in my setup that goes to A- according to ssllabs:
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
NSSProtocol TLSv1.0,TLSv1.1,TLSv1.2
This gets A- due to lack of forward secrecy support.
--
/ Alexander Bokovoy
--
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
