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