set eolBefore for software and add warning to header for versions < eolBefore

[gstrauss]

set eolBefore in configs.js for software and add warning to header for versions < eolBefore

This also reduces string and template duplication, creating a version_tags string and using it to simplify and replace nosupport.hbs and header.hbs with simple javascript in index.js.

[tomato42]

so, this will just add a comment in the config that "the version you're currently using is not maintained by upstream" (or some-such)? or will it forbid generation completely?

There are also situations where the user cannot reasonably upgrade the software without a lot of effort (think appliances and the like), they still will be better off with a better configuration than no configuration at all...

[gstrauss]

so, this will just add a comment in the config that "the version you're currently using is not maintained by upstream" (or some-such)? or will it forbid generation completely?

This change adds a comment and continues to provide a config sample.
This is live on https://ssl-config.mozilla.org/ if you enter a (publicly) EOL software version, e.g. openssl 1.1.1w

nginx 1.27.3, OpenSSL 1.1.1w (UNSUPPORTED; end-of-life), intermediate config
Supports Firefox 27, Android 4.4.2, Chrome 31, Edge, IE 11 on Windows 7, Java 8u31, OpenSSL 1.0.1, Opera 20, Safari 9

# generated 2024-12-08, Mozilla Guideline v5.7, nginx 1.27.3, OpenSSL 1.1.1w (UNSUPPORTED; end-of-life), intermediate config
# https://ssl-config.mozilla.org/#server=nginx&version=1.27.3&config=intermediate&openssl=1.1.1w&guideline=5.7

I am open to suggestions how to do this better, e.g. by adding a footnote ([1]) which links to an explanation.

[gstrauss]

By way of an example, I am not testing the configs produced by ssl-config-generator against openssl 0.9.8, so I think there should be a cut-off for old software versions -- and I am currently using the publicly supported EOL date -- after which we add warnings and in some cases maybe even avoid producing a sample configuration.

Maybe something more strongly worded in a footnote?

"This configuration is aimed at contemporary software versions. If you are unable to upgrade your software versions, you should consider obtaining commercial support, if available, and should follow the advice of said commercial support for how to configure and secure older versions of software no longer publicly maintained."

[tomato42]

I'm not asking for comprehensive and fully maintained support of legacy versions, just of not breaking it intentionally.

and yes, such a note would be good

[gstrauss]

I'm not asking for comprehensive and fully maintained support of legacy versions, just of not breaking it intentionally.

Yes, let's avoid widespread intentional breakage in most cases.

That said, and while not done in this PR, I maintain that there may be a time and place for ancient software versions where we choose to stop providing any config sample.

In #271, it was reported that old versions of Oracle HTTP include SSLv3, and the ssl-config-generator sample for Oracle HTTP was not explicitly excluding SSLv3. While that was brought to our attention and fixed, we are not testing configurations on ancient software and there can be unintended security consequences.

[tomato42]

Sure, if the software is available only in something as old as RHEL-6 or Debian Bullseye, then probably dropping support for it is fine, especially if it makes supporting newer stuff much easier

but really, I'm just asking that "end of upstream support" != "we don't have to care one bit about it any more"