Alexander Bokovoy wrote:
> 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 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
>>>>>> (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
>>>>>> ( 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:
>> 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.

An IPA ticket for this exists,

For mod_nss I was going to do this as part of

If you add in some EC ciphers you'd probably get PFS too. DH ciphers
aren't supported yet.


Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA:

Reply via email to