HI all, When CentOS 7 was created things like SSLv2 TLSv1 TLSv1.1 etc... were all OK, but now they have fallen out of favor for various reasons. Updating to CentOS 7.7 does not automatically disable these types of items from apache - is there a script that is available that can be ran to bring a box up to current "accepted" levels ? Or is that an edit by hand, do it yourself on all your boxes or create your own script type of thing. Just checking if there is an easier way. Thanks, Jerry
On Oct 11, 2019, at 12:12 PM, Jerry Geis <jerry.geis at gmail.com> wrote:> > is there a script that is available that can be ran to bring > a box up to current "accepted" levels ?I don?t know why you?d use a script for this at all. Just ship a new HTTPS configuration to each server. Apache loads all *.conf files in its configuration directory, so you might be able to just add another file to the existing config set. If not, then replace the existing config file instead. If you?re asking for a pre-crafted config, there are bunches of them floating around: https://httpd.apache.org/docs/2.4/ssl/ssl_howto.html https://www.sslshopper.com/article-how-to-disable-weak-ciphers-and-ssl-2.0-in-apache.html https://raymii.org/s/tutorials/Strong_SSL_Security_On_Apache2.html etc. I?m also surprised by the premise implied by the question, which is that a stable OS vendor would switch HTTPS configurations for you on a point upgrade. That?s pretty much the anti-Red Hat position. If you want local breaking changes like this, you develop and test it locally, then deploy the change locally. Yes, breaking changes. Doing this *will* cut off support for older browsers. On purpose.
> Yes, breaking changes. Doing this *will* cut off support for older browsers. On purpose.Old browsers aren't really the problem. Even ff 45 (?) from CentOS5 will happily access a TLSv1.2-only server. The problem is user that have old versions of software installed with no TLSv1.2 support. SVN, python 2.7 scripts, etc.
On 11.10.19 22:40, Warren Young wrote:> On Oct 11, 2019, at 12:12 PM, Jerry Geis <jerry.geis at gmail.com> wrote: >> >> is there a script that is available that can be ran to bring >> a box up to current "accepted" levels ? > > I don?t know why you?d use a script for this at all. Just ship a new HTTPS configuration to each server. Apache loads all *.conf files in its configuration directory, so you might be able to just add another file to the existing config set. If not, then replace the existing config file instead.Instead of configuring every application separataly it would be nice if "accepted levels of security" could be set system wide. With 8 it seems there is such a thing https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/security_hardening/using-the-system-wide-cryptographic-policies_security-hardening Although I believe that FIPS mode is also available in 7 I did not used neither system wide cryptographic policies nor FIPS mode so my post is more the theoretical one, but I thought it is on topic. -- Kind Regards, Markus Falb
On Fri, Oct 11, 2019 at 02:40:42PM -0600, Warren Young wrote:> On Oct 11, 2019, at 12:12 PM, Jerry Geis <jerry.geis at gmail.com> wrote: > > > > is there a script that is available that can be ran to bring > > a box up to current "accepted" levels ?Bear in mind, there are a number of moving parts here. - Many different services, besides web servers, can be configured to employ SSL/TLS. LDAP databases, SMTP servers, etc. - There are different SSL engines in play. Many services use OpenSSL at their core, but Java-based services have their own SSL engine. GnuTLS is another engine in play. - Services linked to OpenSSL nominally aught to be able to be configured to clamp down as you see fit, but sometimes your service's wrapper of OpenSSL doesn't expose enough of the fine-grained details to accomplish as you want. For example, I have a legacy Perl-based web service that used an old version of Net::SSLeay that hampered my ability to constrain SSL versions/ciphers. - Java-based services have config details all over the place. There's a core set of config items for the JVM itself, but your servlet engine will have it's own config files for describing listeners, etc. Besides things acting as SSL servers on a host, there are any number of things that may act as an SSL _client_. Those need to be considered as well, and there are many vagaries about the semantics within config files. -- Brian Reichert <reichert at numachi.com> BSD admin/developer at large