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 <rcrit...@redhat.com > > <mailto:rcrit...@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 <ftwee...@redhat.com > > <mailto:ftwee...@redhat.com> > > > <mailto:ftwee...@redhat.com <mailto:ftwee...@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 > > > <ftwee...@redhat.com <mailto:ftwee...@redhat.com> > > <mailto:ftwee...@redhat.com <mailto:ftwee...@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 > > > > > > > > > > > > > > > > > > > > > > > > > > > -- 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
