[Freeipa-devel] FreeIPA and modern requirements on certificates

[Fraser Tweedale]

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.

Cheers,
Fraser