[Freeipa-users] let's encrypt integration and best practices for mod_nss/mod_ssl
Rob Crittenden
rcritten at redhat.com
Fri Nov 6 04:52:32 UTC 2015
Prasun Gera wrote:
> Thanks. After the changes, most things seem to be in order. I see two
> orange flags though:
>
> Secure Client-Initiated Renegotiation *Supported* *DoS DANGER* (more
> info
> <https://community.qualys.com/blogs/securitylabs/2011/10/31/tls-renegotiation-and-denial-of-service-attacks>)
Renegotiation is required for the CA so you need to leave this enabled.
> Session resumption (caching) *No (IDs assigned but not accepted)*
I'll need to look at this in more detail. At worst it would slow new
connection performance slightly as it means every connection requires a
full SSL/TLS handshake. I don't think it's a show-stopper.
rob
>
> Are these relevant/serious ? Can they be mitigated ?
>
>
> On Thu, Nov 5, 2015 at 6:51 AM, Rob Crittenden <rcritten at redhat.com
> <mailto:rcritten at redhat.com>> wrote:
>
> Prasun Gera wrote:
> > Yes, that's what I was planning to do. i.e. Convert cipher names from
> > SSL to NSS. I wasn't sure about the other settings though. Is there an
> > equivalent NSSHonorCipherOrder ? Is that implicit ? Similarly, are there
> > equivalent configs for HSTS on the mozilla page? Does NSS allow using
> > generated DH parameters instead of standard ones ? For SSL, the
> > suggested modification to the config is 'SSLOpenSSLConfCmd DHParameters
> > "{path to dhparams.pem}"' after generating the params.
>
> NSS does not let the user specify cipher order. It uses its own internal
> sorting from strongest to weakest.
>
> HSTS is a header and not dependent upon SSL provider.
>
> mod_nss doesn't support DH ciphers.
>
> rob
>
> >
> > On Wed, Nov 4, 2015 at 8:21 PM, Fraser Tweedale <ftweedal at redhat.com <mailto:ftweedal at redhat.com>
> > <mailto:ftweedal at redhat.com <mailto:ftweedal at redhat.com>>> wrote:
> >
> > On Wed, Nov 04, 2015 at 05:03:29PM -0800, Prasun Gera wrote:
> > > Thanks for the ticket information. I would still be interested in
> > > configuring mod_nss properly (irrespective of whether the certs are ipa
> > > generated or 3rd party). These are the worrying notes from ssllabs test:
> > >
> > > The server supports only older protocols, but not the current best TLS 1.2.
> > > Grade capped to C.
> > > This server accepts the RC4 cipher, which is weak. Grade capped to B.
> > > The server does not support Forward Secrecy with the reference browsers.
> > >
> > Use the "Modern" cipher suite[1] recommended by Mozilla as a
> > starting point. See also the "Cipher names correspondence table" on
> > the same page for translating it to cipher names understood by NSS
> > to construct a valid setting for the `NSSCipherSuite' directive.
> >
> > [1]
> > https://wiki.mozilla.org/Security/Server_Side_TLS#Modern_compatibility
> >
> > Cheers,
> > Fraser
> >
> > >
> > > On Wed, Nov 4, 2015 at 4:44 PM, Fraser Tweedale
> > <ftweedal at redhat.com <mailto:ftweedal at redhat.com>
> <mailto:ftweedal at redhat.com <mailto:ftweedal at redhat.com>>> wrote:
> > >
> > > > On Wed, Nov 04, 2015 at 03:20:22PM -0800, Prasun Gera wrote:
> > > > > I'm using idm (4.1.x) on a RHEL 7.1 with the webui
> accessible
> > publicly.
> > > > I'm
> > > > > using a stock configuration which uses the certs signed by
> > ipa's CA for
> > > > the
> > > > > webui. This is mostly for convenience since it manages
> renewals
> > > > seamlessly.
> > > > > This, however, requires users to add the CA as trusted
> to their
> > > > browsers. A
> > > > > promising alternative to this is https://letsencrypt.org/,
> > which issues
> > > > > browser trusted certs, and will manage auto renewals too (in
> > the future).
> > > > > As a feature request, it would be nice to have closer
> > integration between
> > > > > ipa and the letsencrypt client which would make managing
> certs
> > simple.
> > > > I'm
> > > > > about to set this up manually right now using the
> external ssl
> > certs
> > > > guide.
> > > > >
> > > > Let's Encrypt is on our radar. I like the idea of being
> able to
> > > > install FreeIPA with publicly-trusted certs for HTTP and
> LDAP from
> > > > the beginning. This would require some work in
> ipa-server-install
> > > > in addition to certmonger support and a good, stable Let's
> Encrypt /
> > > > ACME client implementation for Apache on Fedora.
> > > >
> > > > Installing publicly-trusted HTTP / LDAP certs is a common
> activity
> > > > so I filed a ticket:
> https://fedorahosted.org/freeipa/ticket/5431
> > > >
> > > > Cheers,
> > > > Fraser
> > > >
> > > > > Secondly, since the webui uses mod_nss, how would one set it
> > up to prefer
> > > > > security over compatibility with older clients ? The vast
> > majority of
> > > > > documentation online (for eg.
> > > > >
> >
> https://mozilla.github.io/server-side-tls/ssl-config-generator/) is
> > > > about
> > > > > mod_ssl and I think the configuration doesn't transfer
> directly to
> > > > mod_nss.
> > > > > Since this is the only web facing component, I would like to
> > set it up to
> > > > > use stringent requirements. Right now, a test on
> > > > > https://www.ssllabs.com/ssltest/ and
> > https://weakdh.org/sysadmin.html
> > > > > identifies
> > > > > several issues. Since these things are not really my area of
> > expertise, I
> > > > > would like some documentation regarding this. Also,
> would manually
> > > > > modifying any of the config files be overwritten by a
> yum update ?
> > > >
> > > > > --
> > > > > Manage your subscription for the Freeipa-users mailing list:
> > > > > https://www.redhat.com/mailman/listinfo/freeipa-users
> > > > > Go to http://freeipa.org for more info on the project
> > > >
> > > >
> >
> >
> >
> >
>
>
More information about the Freeipa-users
mailing list