<div dir="ltr">Thanks. After the changes, most things seem to be in order. I see two orange flags though:<div> <div><table class="" style="border-collapse:collapse;width:670px;margin:0px 10px 0px 0px;padding:0px;font-size:12px;line-height:20px;font-family:Arial,Helvetica,sans-serif;background-color:rgb(253,253,253)"><tbody><tr class=""><td class="" style="padding:3px 10px 3px 0px;color:rgb(68,68,68);border-bottom-width:1px;border-bottom-style:solid;border-bottom-color:rgb(240,240,240);vertical-align:middle;font-weight:bold;width:230px">Secure Client-Initiated Renegotiation</td><td class="" style="padding:3px 0px;border-bottom-width:1px;border-bottom-style:solid;border-bottom-color:rgb(240,240,240);vertical-align:middle;word-wrap:break-word">Supported DoS DANGER (<a href="https://community.qualys.com/blogs/securitylabs/2011/10/31/tls-renegotiation-and-denial-of-service-attacks" style="color:rgb(248,128,23)">more info</a>)</td></tr></tbody></table><table class="" style="border-collapse:collapse;width:670px;margin:0px 10px 0px 0px;padding:0px;font-size:12px;line-height:20px;font-family:Arial,Helvetica,sans-serif;background-color:rgb(253,253,253)"><tbody><tr class=""><td class="" style="padding:3px 10px 3px 0px;color:rgb(68,68,68);border-bottom-width:1px;border-bottom-style:solid;border-bottom-color:rgb(240,240,240);vertical-align:middle;font-weight:bold;width:230px">Session resumption (caching)</td><td class="" style="padding:3px 0px;border-bottom-width:1px;border-bottom-style:solid;border-bottom-color:rgb(240,240,240);vertical-align:middle;word-wrap:break-word">No (IDs assigned but not accepted)</td></tr></tbody></table> </div><div>Are these relevant/serious ? Can they be mitigated ?</div></div><div> </div></div><div class="gmail_extra"> <div class="gmail_quote">On Thu, Nov 5, 2015 at 6:51 AM, Rob Crittenden <<a href="mailto:rcritten@redhat.com" target="_blank">rcritten@redhat.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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 <<a href="mailto:ftweedal@redhat.com">ftweedal@redhat.com</a> > <mailto:<a href="mailto:ftweedal@redhat.com">ftweedal@redhat.com</a>>> 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] > <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> > > Cheers, > Fraser > > > > > On Wed, Nov 4, 2015 at 4:44 PM, Fraser Tweedale <div class="HOEnZb"><div class="h5">> <<a href="mailto:ftweedal@redhat.com">ftweedal@redhat.com</a> <mailto:<a href="mailto:ftweedal@redhat.com">ftweedal@redhat.com</a>>> 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 <a href="https://letsencrypt.org/" rel="noreferrer" target="_blank">https://letsencrypt.org/</a>, > 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: <a href="https://fedorahosted.org/freeipa/ticket/5431" rel="noreferrer" target="_blank">https://fedorahosted.org/freeipa/ticket/5431</a> > > > > > > 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. > > > > > <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 > > > 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 > > > > <a href="https://www.ssllabs.com/ssltest/" rel="noreferrer" target="_blank">https://www.ssllabs.com/ssltest/</a> and > <a href="https://weakdh.org/sysadmin.html" rel="noreferrer" target="_blank">https://weakdh.org/sysadmin.html</a> > > > > 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: > > > > <a href="https://www.redhat.com/mailman/listinfo/freeipa-users" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/freeipa-users</a> > > > > Go to <a href="http://freeipa.org" rel="noreferrer" target="_blank">http://freeipa.org</a> for more info on the project > > > > > > > > > > </div></div></blockquote></div> </div>