URLs from previously generated configurations no longer show the original configuration

[jerrykan]

When a configuration is generated it includes an URL which I assumed was essentially a permalink to be able to look at the same generated configuration again in the future, however I just just noticed that the guidelines parameter (any maybe others?) is ignored and only the configuration for the current guidelines are show.

To provide an example the following URLs should show slightly different SSLCipherSuite values:

• https://ssl-config.mozilla.org/#server=apache&version=2.4.53&config=intermediate&openssl=1.1.1n&ocsp=false&guideline=5.6
• https://ssl-config.mozilla.org/#server=apache&version=2.4.57&config=intermediate&openssl=3.0.8&ocsp=false&guideline=5.7

However the SSLCipherSuite value in both is exactly the same.

[gstrauss]

I have a hunch that the site is built/generated from guideline 5.7, as indicated by the comment at the top of both of the links you provided. The site would need to be rebuilt/regenerated against guideline 5.6 to provide that information.

Guideline version is not a configurable option on the generated page.

I am not convinced this is feature that should be provided by the site, though it might be nice to document how end-users might regenerate the site from source control to access older guidelines. Note that Guideline 5.7 is over 4 years old, so it is not like there are frequent changes being made to the guidelines.

[janbrasna]

At some point in the past the permalink was actually generated for it to be a "permalink", i.e. to be able to open the config in the state it was exported originally, and I understand the sentiment to expect for the link to work. (Or, at least make it extremely visible that you're coming from an old link, and what you see is the current config instead…)

However since then a handful of breaking changes in the spec structure limited the compatibility and at some point only the latest.json symlink was being loaded into the app.

It may be trivial to add this so I keep it open if someone has the appetite to support arbitrary version refs, at least silently accepting any version in the query string and showing the latest config instead without any warning feels like a unfortunate mishap. (I don't expect this to ever be a consumer-facing choice, but when the time comes for a new spec version, people still may need to access the old permalinks to compare what's different to the current outputs etc., so as well as I'd love to see the current version of the specs visibly shown in the UI, I'm not exactly against being able to read older configs based on the query string and rendering those as a best effort.)

[janbrasna]

The other thing is… some of the minor version guidelines were superseded because they contained a bug — so they shouldn't really be used… so it's not an exactly simple topic.

[gstrauss]

Would it be feasible to have multiple github pages? e.g. https://ssl-config.mozilla.org/spec-5.6/... Then, a new spec would generate to a new location and the main page would simply redirect to the latest spec.

[gstrauss]

src/templates/index.ejs already includes build <%= htmlWebpackPlugin.options.revision %> with the git SHA1 revision, and this is already listed in the footer of index.html as, e.g. build cab5c12, generated 2024-12-06

If we generated the site off of the tags, then the site at a given tag revision would be loadable with a link into build/ (or docs/ if preferred). That is one way to serve the site directly from the repository. Creating a tarball of the build artifacts at a given tag is another option.

[gstrauss]

FYI: older versions of the site are available at archive.org in the Wayback Machine
https://web.archive.org/web/20240301000000*/https://ssl-config.mozilla.org/

[gstrauss]

Looking at the code in src/js/state.js, it is a possibility for the code to be modified to read all the guidelines and to render the site using current templates and data from older json guidelines. The current URL generated includes &guideline=5.7 in the URL fragment, though I did not see that parameter included in the 2019 version of the site pulled from archive.org, so it was apparently added some time in between.

This would be a coarse way to somewhat support older guidelines, but would not guarantee an exact replication of what was produced at a prior point in time. For an attempt at exact replication, download the source, git checkout the desired revision, and npm run build the site. ... should we consider including the site git SHA in the URL fragment, in addition to &guideline=5.7?

[gstrauss]

I have removed the 'help wanted' tag since there are numerous different approaches which could be taken, and it would be better to discuss design changes such as versioning and deployment workflows to provide better direction on what might be one of the acceptable solutions.

I might experiment with rendering the current site using data from older guideline version taken from the URL.

[gstrauss]

I looked through the guidelines from 5.0 to 5.7 and the only substantive difference in the guidelines exposed in ssl-config-generator is the change from 5.6 to 5.7 which added DHE-RSA-CHACHA20-POLY1305. (There was a change in the naming of 'secp256r1' to 'prime256v1', but curve names were only recently exposed in the ssl-config-generator in what will likely be tagged 5.7.2, and refers to the same curve.) There were a small number of other changes in the guidelines, but those changes were not data exposed in ssl-config-generator output.

While I have an experimental commit in a development branch
https://github.com/gstrauss/ssl-config-generator/tree/multi-guideline
which supports guidelines 5.0 to 5.7, I think it is completely unnecessary bloat to package all the old guidelines.

If you need to see the output from 5.6, then the Wayback Machine should suffice.

Instead, I think a workaround here is to detect if guideline= requested in the URL does not match the current version of the guidelines, and to correct it in the URL fragment and/or add a note to the page warning the user that the guidelines have been updated since the link they followed was last generated. The HTTP response of the two links in @jerrykan's original post has the same content. Only the URL in the address bar remains different (&guideline=5.6 vs &guideline=5.7) because the URL fragment is not updated on initial page load.

We might also add something to document that it is not a permalink, but rather a link with the input options pre-selected.

We might also add a date=YYYYMMDD to the generated link, too, for use in selecting a snapshot of the ssl-config-generator from the Wayback Machine.

From a practical security perspective, I am not convinced this permalink feature should be implemented. If someone is visiting ssl-config-generator, the current guidance is what should be evaluated and considered by the visitor.

What are your thoughts and opinions?

[gstrauss]

I pushed a change which updates the URL fragment for visitors with old guideline links.
The URL now matches the content, effectively "redirecting" from an old link to a new link.

Regarding the UX, I think we should remove &guideline=5.7 from the URL, replace it with the SHA of the commit and perhaps a date, and add a separate line below that link with a link to the guidelines used when generating the page, i.e. https://ssl-config.mozilla.org/guidelines/5.7.json