[Freeipa-users] let's encrypt integration and best practices for mod_nss/mod_ssl
Prasun Gera
prasun.gera at gmail.com
Sun Nov 8 05:15:52 UTC 2015
Thanks for the discussion. If someone can update the documentation with
mozilla style old, intermediate and modern cipher lists for mod_nss, that
would be great. Better still would be to add that option to the installer
scripts so that you can choose it during installation. Integrating that in
the package would also have the added benefit of settings remaining up to
date without manual intervention as standards evolve.
On Thu, Nov 5, 2015 at 9:23 PM, Fraser Tweedale <ftweedal at redhat.com> wrote:
> On Thu, Nov 05, 2015 at 11:52:32PM -0500, Rob Crittenden wrote:
> > 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.
> >
> Definitely not a show-stopper. The main reason this is an "orange"
> alert in SSLLabs is because the server is assigning Session IDs but
> then ignoring them; although confusing it is a fairly common default
> behaviour and doesn't cause any issues with compliant client
> implementation
>
> > 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
> > > > > >
> > > > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20151107/fce6d364/attachment.htm>
More information about the Freeipa-users
mailing list