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@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-i... 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 Oct 11, 2019, at 2:52 PM, isdtor isdtor@gmail.com wrote:
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.
IE 10 and older won’t, though: https://caniuse.com/#feat=tls1-2
The problem is user that have old versions of software installed with no TLSv1.2 support. SVN, python 2.7 scripts, etc.
Also true. There’s a lot of stuff still linked to OpenSSL 1.0.0 and 0.98.
Without context it's impossible to make firm statements but, having gone through this a while back (and discovering that less than 1 percent of an examined list of connections couldn't support current ssl - mainly Apple hardware), who do you want to protect? Is it the minority who won't/can't upgrade or the majority who have? And, do you have to protect yourself from liability (regulatory or contractual)? If the environment is in any way sensitive (Personally Identifiable Information, Health data, Credit Card data) then the answer is obvious. ________________________________ From: CentOS centos-bounces@centos.org on behalf of Warren Young warren@etr-usa.com Sent: Friday, October 11, 2019 3:58 PM To: CentOS mailing list centos@centos.org Subject: [EXTERNAL] Re: [CentOS] easy way to stop old ssl's
Harriscomputer
Register now for the dataVoice User Conference, October 9-11 at the Gaylord Rockies in Denver, CO. To register click Herehttps://www.harriscomputer.com/en/events/
Leroy Tennison Network Information/Cyber Security Specialist E: leroy@datavoiceint.com
[cid:Data-Voice-International-LOGO_aa3d1c6e-5cfb-451f-ba2c-af8059e69609.PNG]
2220 Bush Dr McKinney, Texas 75070 www.datavoiceint.comhttp://www..com
This message has been sent on behalf of a company that is part of the Harris Operating Group of Constellation Software Inc.
If you prefer not to be contacted by Harris Operating Group please notify ushttp://subscribe.harriscomputer.com/.
This message is intended exclusively for the individual or entity to which it is addressed. This communication may contain information that is proprietary, privileged or confidential or otherwise legally exempt from disclosure. If you are not the named addressee, you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If you have received this message in error, please notify the sender immediately by e-mail and delete all copies of the message.
On Oct 11, 2019, at 2:52 PM, isdtor isdtor@gmail.com wrote:
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.
IE 10 and older won’t, though: https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fcaniuse.com%2f%23feat%3d...
The problem is user that have old versions of software installed with no TLSv1.2 support. SVN, python 2.7 scripts, etc.
Also true. There’s a lot of stuff still linked to OpenSSL 1.0.0 and 0.98. _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Just saw the original message (Outlook Web Access isn't the greatest in presenting threads). I had to do it manually but the number of settings to change was small (for a fairly simple website). I would think a sed script inside a for loop would do for a system. If you have a large number of systems then it's time to look at Puppet/Ansible/Chef. ________________________________ From: CentOS centos-bounces@centos.org on behalf of Leroy Tennison leroy@datavoiceint.com Sent: Friday, October 11, 2019 11:48 PM To: CentOS mailing list centos@centos.org Subject: Re: [CentOS] easy way to stop old ssl's
Without context it's impossible to make firm statements but, having gone through this a while back (and discovering that less than 1 percent of an examined list of connections couldn't support current ssl - mainly Apple hardware), who do you want to protect? Is it the minority who won't/can't upgrade or the majority who have? And, do you have to protect yourself from liability (regulatory or contractual)? If the environment is in any way sensitive (Personally Identifiable Information, Health data, Credit Card data) then the answer is obvious.
Harriscomputer
Register now for the dataVoice User Conference, October 9-11 at the Gaylord Rockies in Denver, CO. To register click Herehttps://www.harriscomputer.com/en/events/
Leroy Tennison Network Information/Cyber Security Specialist E: leroy@datavoiceint.com
[cid:Data-Voice-International-LOGO_aa3d1c6e-5cfb-451f-ba2c-af8059e69609.PNG]
2220 Bush Dr McKinney, Texas 75070 www.datavoiceint.comhttp://www..com
This message has been sent on behalf of a company that is part of the Harris Operating Group of Constellation Software Inc.
If you prefer not to be contacted by Harris Operating Group please notify ushttp://subscribe.harriscomputer.com/.
This message is intended exclusively for the individual or entity to which it is addressed. This communication may contain information that is proprietary, privileged or confidential or otherwise legally exempt from disclosure. If you are not the named addressee, you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If you have received this message in error, please notify the sender immediately by e-mail and delete all copies of the message.
________________________________ From: CentOS centos-bounces@centos.org on behalf of Warren Young warren@etr-usa.com Sent: Friday, October 11, 2019 3:58 PM To: CentOS mailing list centos@centos.org Subject: [EXTERNAL] Re: [CentOS] easy way to stop old ssl's
Harriscomputer
Register now for the dataVoice User Conference, October 9-11 at the Gaylord Rockies in Denver, CO. To register click Herehttps://linkprotect.cudasvc.com/url?a=https%3a%2f%2fwww.harriscomputer.com%2fen%2fevents%2f&c=E,1,4J7-GGGBpU9KBPfPZ7bL730w7WiyJlctx6iIvi5PWH7ZM8lC_dVONfXLuYIqLeXHJdKEpUhep3pXkJ3H5aKy9zTmVcdXIuVUQwAE9dGXbSxuwQ8,&typo=1
Leroy Tennison Network Information/Cyber Security Specialist E: leroy@datavoiceint.com
[cid:Data-Voice-International-LOGO_aa3d1c6e-5cfb-451f-ba2c-af8059e69609.PNG]
2220 Bush Dr McKinney, Texas 75070 https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fwww.datavoiceint.com&...http://www..com
This message has been sent on behalf of a company that is part of the Harris Operating Group of Constellation Software Inc.
If you prefer not to be contacted by Harris Operating Group please notify ushttps://linkprotect.cudasvc.com/url?a=http%3a%2f%2fsubscribe.harriscomputer.com%2f&c=E,1,5g3DWaevZ_6CRMR9DZ2NvFs6mv0LUL7Ceslt7x0pEY9xRa4IkwRngZxDYuKiPPTTL5ikJeKoHbPkB7LfS3v_n8-NYxZO_2Emr5Y89EPatHmO_a2MY-Ol3A,,&typo=1.
This message is intended exclusively for the individual or entity to which it is addressed. This communication may contain information that is proprietary, privileged or confidential or otherwise legally exempt from disclosure. If you are not the named addressee, you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If you have received this message in error, please notify the sender immediately by e-mail and delete all copies of the message.
On Oct 11, 2019, at 2:52 PM, isdtor isdtor@gmail.com wrote:
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.
IE 10 and older won’t, though: https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fcaniuse.com%2f%23feat%3d...
The problem is user that have old versions of software installed with no TLSv1.2 support. SVN, python 2.7 scripts, etc.
Also true. There’s a lot of stuff still linked to OpenSSL 1.0.0 and 0.98. _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On 11.10.19 22:40, Warren Young wrote:
On Oct 11, 2019, at 12:12 PM, Jerry Geis jerry.geis@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/htm...
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.
On Oct 12, 2019, at 4:06 AM, Markus Falb markus.falb@fasel.at wrote:
On 11.10.19 22:40, Warren Young wrote:
Just ship a new HTTPS configuration to each server.
Instead of configuring every application separataly it would be nice if "accepted levels of security" could be set system wide.
…which implies that there is some authority that defines “accepted level” the way you’d do it if you could be bothered to think through all of the use cases, combinations, and implications.
Who is that central organization? Are you sure their notions match your own?
With 8 it seems there is such a thing
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/htm...
Although I believe that FIPS mode is also available in 7
That’s FIPS 140-2, a standard from 2001, which is three TLS standards ago.
FIPS 140-3 just barely became effective a few weeks ago, which means it won’t be considered for inclusion in RHEL until 9, which I don’t expect to appear until 3-4 years from now, by which time FIPS 140-2 will be around 21 years old.
So, we not only have a situation where adopting FIPS 140-2 requires that you use badly outdated security technologies, it also means you might not be able to communicate with those that do support modern standards, if they’ve dropped compatibility with 2001 era tech sometime in the last 18 years.
If we can be well-guided by past events, there’s a better than 50/50 chance that any given person on this list won’t even be in IT any more when FIPS 140-4 comes out.
On 12.10.19 19:33, Warren Young wrote:
On Oct 12, 2019, at 4:06 AM, Markus Falb markus.falb@fasel.at wrote:
On 11.10.19 22:40, Warren Young wrote:
Just ship a new HTTPS configuration to each server.
Instead of configuring every application separataly it would be nice if "accepted levels of security" could be set system wide.
…which implies that there is some authority that defines “accepted level” the way you’d do it if you could be bothered to think through all of the use cases, combinations, and implications.
Who is that central organization? Are you sure their notions match your own?
You should have the authority discussion with OP who brought that thing with "accepted" up.
On Oct 11, 2019, at 12:12 PM, Jerry Geis jerry.geis@gmail.com wrote: # # is there a script that is available that can be ran to bring # a box up to current "accepted" levels ?
My post was about system wide configuration not about authorities. However, take a look at the subject of this thread. Who defines what is old ? What about best practices like disable SSLv3 or TLSv1? Could the authority be the community or some common knowledge?
With 8 it seems there is such a thing
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/htm...
Although I believe that FIPS mode is also available in 7
That’s FIPS 140-2, a standard from 2001, which is three TLS standards ago.
If I look at the comparison table from the link above FIPS mode does not look that bad. I guess that I would get A rating from ssllabs.
FIPS 140-3 just barely became effective a few weeks ago, which means it won’t be considered for inclusion in RHEL until 9, which I don’t expect to appear until 3-4 years from now, by which time FIPS 140-2 will be around 21 years old.
So, we not only have a situation where adopting FIPS 140-2 requires that you use badly outdated security technologies, it also means you might not be able to communicate with those that do support modern standards, if they’ve dropped compatibility with 2001 era tech sometime in the last 18 years.
I read you saying that FIPS 140-2 is not good enough. Apart from age, why?
On Oct 15, 2019, at 12:26 PM, Markus Falb markus.falb@fasel.at wrote:
I guess that I would get A rating from ssllabs.
None of my CentOS systems have Internet-facing HTTP, much less HTTPS, so I volunteer you to test it and report back. :)
I read you saying that FIPS 140-2 is not good enough. Apart from age, why?
It requires that a conforming application speak only protocols that NIST has approved, and even then, you can only get FIPS 140-2 certification by submitting the software to a third-party validation service, which is very expensive and very time consuming. (I’m seeing numbers like 9 months and US $100,000.) After going through all of that, you aren’t allowed to make *any* changes to the covered parts of the software without going through another validation process.
Let’s say you’re a software vendor and someone discovers a vulnerability not caught by the FIPS certification process. You’re a good citizen, so you fix it quickly and release that fix promptly. Then you must re-file for a new certification (more $$$) and then wait for the independent testing lab and NIST to take months to re-certify your software. Meanwhile, those insisting on FIPS mode have to use the known-vulnerable version — which probably has a public CVE filed against it, thus cluing potential attackers into the problem — because the new one isn’t FIPS-certified yet.
For another example, elliptic curve crypto is currently getting very popular for various reasons, but not all common curve parameters are NIST-certifiable under FIPS 140-2. If you must communicate with an ECC service using non-certified params, you either cannot run your app in FIPS mode or you have to separately get the other end to become FIPS-certified, which means abandoning those params, which might be better than what you can get under FIPS.
Again, I invite you to do a web search for people running into trouble trying to get FIPS-mode apps to communicate with non-FIPS-mode apps. It’s not hard to find people running into problems here.
Here’s some I found:
https://blogs.technet.microsoft.com/secguide/2014/04/07/why-were-not-recomme... https://blogs.oracle.com/security/fips-the-crypto-catch-22 https://bugs.chromium.org/p/chromium/issues/detail?id=194867
If giants like Microsoft, Google, and Oracle are having trouble getting and maintaining their FIPS certifications, what hope do us little guys have?
If you don’t like responses from big corporations, here’s some clueful developers discussing the problems:
https://news.ycombinator.com/item?id=7635321
I don’t have a problem with independent testing and such per se, but when it’s a regulatory gatekeeper to what software *can* be written and used, it’s a problem when it comes to security. If we’ve learned anything about security in these past decades, it’s that fast reaction to vulnerabilities is critical.
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@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 -
isdtor -
Jerry Geis -
Leroy Tennison -
Markus Falb -
Warren Young