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:



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.

Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Reply via email to