Use implicit settings for lighttpd ≥1.4.68

[gstrauss]

lighttpd updates for lighttpd 1.4.76
This PR modifies only the lighttpd version in src/js/configs.js
The rest of the changes in this PR are limited to src/templates/partials/lighttpd.hbs

lighttpd 1.4.56 and later default to MinProtocol TLSv1.2

lighttpd 1.4.68 and later default to a strict set of PFS ciphers and
to -ServerPreference, since a strict set of PFS ciphers is the default.

Simplify intermediate and modern configs for lighttpd 1.4.68 and later.
lighttpd defaults will incrementally be made more secure in the future
and using lighttpd secure defaults (without explicitly hard-coding the
defaults at a point in time) will allow users to get more secure
defaults along with lighttpd upgrades, instead of accidentally
continuing to use explicitly set older, less-secure config settings.

lighttpd 308 redirect code from http to https
   (for lighttpd 1.4.31 to lighttpd 1.4.74;
    has become default in lighttpd 1.4.75 for HTTP/1.1 (and later) requests)

[gene1wood]

@gstrauss It seems like this logic doesn't work. When I check this PR out and run it, selecting Intermediate and lighthttpd version 1.4.67 I get

...
ssl.pemfile = "/path/to/signed_cert_followed_by_intermediates"
ssl.openssl.ssl-conf-cmd += ("Options" => "-ServerPreference")
# TLS modules besides mod_openssl might name ciphers differently
...

And the ssl.openssl.ssl-conf-cmd = ("MinProtocol" => "TLSv1.2") line is missing.

I'm unsure of the logic you intended.

The Intermediate configuration has a output.protocols list of ["TLSv1.2", "TLSv1.3"]

• What MinProtocol should lighthttpd have for Intermediate on version 1.4.67?

Also if you change the {{#if (minver "1.4.56" form.serverVersion)}}{{else}} line to use unless instead of if with an empty else it will fix the formatting issue that causes the line to be preceded by 4 spaces causing it to look like

    ssl.openssl.ssl-conf-cmd += ("Options" => "-ServerPreference")

Here's what it would look like with unless

    {{#unless (minver "1.4.56" form.serverVersion)}}
ssl.openssl.ssl-conf-cmd = ("MinProtocol" => "TLSv1.2")
    {{/unless}}

[gstrauss]

"MinProtocol" => "TLSv1.2" is the default in lighttpd TLS modules since lighttpd 1.4.56.
It is preferred that people use lighttpd's secure defaults -- which are periodically reviewed, announced, and updated -- rather than specifying something which may then be cargo-culted for years and never revisited in user configurations.

I'll make the suggested unless change shortly and will push an updated branch rebased on master.

[gstrauss]

requested changes have been made

[gstrauss]

FYI, the commit message for a56011b in this PR explains:

lighttpd updates for lighttpd 1.4.68

lighttpd 1.4.56 and later default to MinProtocol TLSv1.2

lighttpd 1.4.68 and later default to a strict set of PFS ciphers and
to -ServerPreference, since a strict set of PFS ciphers is the default.

Simplify intermediate and modern configs for lighttpd 1.4.68 and later.
lighttpd defaults will incrementally be made more secure in the future
and using lighttpd secure defaults (without explicitly hard-coding the
defaults at a point in time) will allow users to get more secure
defaults along with lighttpd upgrades, instead of accidentally
continuing to use explicitly set older, less-secure config settings.

[gstrauss]

Besides rebasing this PR onto tip of current master branch, the only substantive change in the push below is your requested change to use unless in src/templates/partials/lighttpd.hbs

[gstrauss]

@janbrasna have you looked at https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/308 recently? All modern, supported browser clients support 308. If you have a specific concern, please be more specific. "Fear, Uncertainty, and Doubt" absent any real data are not strong arguments or productive contributions to a conversation.

RFC7538 "The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect)" was published in 2015, almost 9 years ago.

[gene1wood]

@gstrauss Thanks for the unless fix to the indentation.

"MinProtocol" => "TLSv1.2" is the default in lighttpd TLS modules since lighttpd 1.4.56.

Got it, what I meant is that it looks like the logic you wrote is intended to output the line

ssl.openssl.ssl-conf-cmd = ("MinProtocol" => "TLSv1.2")

However it doesn't.

Even with the default you mention, will the subsequent line

    ssl.openssl.ssl-conf-cmd += ("Options" => "-ServerPreference")

work given that it's using a += which I imagine concatenates onto an existing string? I ask because in the code's current state there is no existing string to add to.

Here's the output when I run this PR's code and choose lighthttp 1.4.67

Ya, I'd been intending to try to work on the HTTP 308 topic distinct from this PR, but don't worry about that, I can fix this up. Once we have the logic for the MinProtocol fixed I'll fix things up and add more comments to #117

[gstrauss]

Even with the default you mention, will the subsequent line

ssl.openssl.ssl-conf-cmd += ("Options" => "-ServerPreference")

work given that it's using a += which I imagine concatenates onto an existing string? I ask because in the code's
current state there is no existing string to add to.

@gene1wood: Yes, it will work as intended.

[gene1wood]

Ok cool, ya appending to empty lists like this was added in 1.4.17 as you say.

[janbrasna]

@gstrauss No need to worry about me, I work with MDN daily. If pointing to previous maintainers' decisions (as a reason why more related HTTP 308 issues/PRs are still hanging around unresolved) feels like a FUD then I'm sorry, but I felt co-authors' decisions were more relevant, than e. g. my recollections of why this hasn't moved forward. That said… I just tried to explain that separating the 308 feature into its own might help expedite the proposed changes.

(There's no consensus on 308s and once decided, that should be projected into all server templates, behind their appropriate version conditionals i. e. ~ sure I'd love to see them given the POST handling, but historically there was the question if they belong to intermediate where IE11@W7 is buggy and old where most of the UAs claimed to be compatible can't redirect it. That's why I wanted to move this discussion to its own issue, and iron out the details there.)

[janbrasna]

I'm not sure I understand the changes either, could you please confirm the meaning behind:

[janbrasna]

Is it worth differentiating? The JSON specs say either set preference, or don't set preference. Is it better to just omit it and leave to server default?

[janbrasna]

(I mean, the original +/- satisfied the specs exactly. Is there a reason starting ≥v1.4.68 for not setting -ServerPreference explicitly?)

[gstrauss]

@janbrasna the commit message cut-n-paste into the original description of this PR submission explains that it is best to use the lighttpd TLS defaults. You're welcome to disagree and I am happy to discuss further. However, I do not see how repeating that text a third time in this PR would be useful when I think that text already answers your question.

Is it better to just omit it and leave to server default?

Yes. I am a lighttpd developer and answer user questions on lighttpd forums. Yes, it is better to use lighttpd defaults.

[janbrasna]

Ah gotcha, so adding the complexity to the template logic this way makes the output configs actually simpler for newer versions, where you positively know you provide the same result. OK. It's not exactly readable from the partial, but if the end result is the same…

(SImilar issue was with certbot on httpd where locally overriding values explicitly set to defaults here was tricky.)

[janbrasna]

@gstrauss I sure read it… and expected the defaults to be unnecessary old protocols and such, not completely omitting @mozilla/server-side-tls's intermediate cipher suites ;D that's why I raised the additional questions if I read it correctly and the resulting output is really meant that way and not a mistake.

[janbrasna]

This means not setting the cipher suites since ≥v1.4.68 unless old, i. e. modern and intermediate won't set the suites at all according to json specs? Isn't the intention of the configs to explicitly set the cipher suites according to the specs, instead of leaving it to the server defaults?

[janbrasna]

@gene1wood or do I read it wrong? I understand there are more and more great defaults provided by the servers, but that doesn't mean the generator should give up and not output the cipher suites according to the current .json recommendations (which is whole another discussion TBH).

Is there a consensus when the actual output should be left out for server defaults behind a version conditional?

[gstrauss]

@janbrasna as above, yes, it is better to use lighttpd secure TLS defaults.

[gstrauss]

@janbrasna if you have further questions how to configure lighttpd securely, please refer to the lighttpd TLS docs

[janbrasna]

@gstrauss Nope, I don't have further questions how to configure lighttpd securely, I don't think I need to. Surprisingly that's not the issue.

My question is about this change, that basically disallows the output of https://statics.tls.security.mozilla.org/server-side-tls-conf-*.json and leaves that to the vendor's definition. While claiming it's the @mozilla/server-side-tls's e. g. intermediate … when it is no longer so;)
(even if the effectively used suites match today, that might not be true tomorrow — and that's why Mozilla's TLS specs are versioned and explicit, to be predictable, if needed for any given usecase e. g. PCI DSS testing etc.)

This PR basically reads for intermediate and latestVersion i. e. the default in the UI: "Claim it's Mozilla's https://wiki.mozilla.org/Security/Server_Side_TLS#Intermediate_compatibility_.28recommended.29 while in reality supplying Lighty's https://redmine.lighttpd.net/projects/lighttpd/wiki/Docs_SSL#Perfect-Forward-Secrecy-PFS …"

There are more vendors wishing the output not to mess with their secure TLS defaults so I'll open a broader discussion for it. I understand it, servers with great defaults should get their credit for having safe defaults, yet I don't see the need to cripple the json specs output to achieve this.

[janbrasna]

Quickly comparing the lists, lighty's includes CCM/8s & PSKs for embeds that are not too important here, but misses DHE-RSA-GCMs from server-side-tls-conf-* specs.

So the end output claiming to be @mozilla intermediate is in reality not that:

See I'm no @april to have a say in this, I'm just testing the rendered output — and with no configurations.intermediate.ciphers[] present in the output at all, in the current state of affairs, that seemed like a bug. That's why I raised it for others to decide.

The need to somehow endorse great defaults where applicable is a whole another topic, unrelated to keeping the @mozilla's intermediate config output for lighty still to @mozilla's specs;)

[gstrauss]

@janbrasna as you mentioned already, the mozilla TLS recommendation specification is probably due for review, and I agree.

The last substantial updates to the ssl-config-generator specs were in 2020, when April published versions 5.3, 5.4, 5.5, and 5.6 (July 2020), now 3 1/2 years ago. Gene published 5.7 in May 2023, with the simple change to add DHE-RSA-CHACHA20-POLY1305.

I am not suggesting whether or not dhe-rsa-aes128-gcm-sha256 or dhe-rsa-aes256-gcm-sha384 should be included. I am saying that the spec should be reviewed to see if they should, or should not be removed from the intermediate cipher list. Once that is refreshed (and not 3 1/2 years old), then we can have a more relevant conversation about whether or not ssl-config-generator should emit a cipher list to include those in the ssl-config-generator "Intermediate" lighttpd config.

One data point to compare with others: the current Cloudflare recommendations include only ciphers using elliptic curve diffie hellman ephemeral (ECDHE) for key exchange in both their "Modern" and "Compatible" cipher lists. https://developers.cloudflare.com/ssl/reference/cipher-suites/recommendations/

Another data point is that I have not received any complaints about lighttpd TLS defaults since lighttpd updated its TLS defaults in Jan 2023 (after having announced the scheduled change throughout all of 2022). I have received zero requests for lighttpd to include those dhe ciphers in the lighttpd TLS defaults, and I do not have any plans to add them.

[gstrauss]

mozilla/server-side-tls#285 notes "Note that DHE suites in TLS 1.2 are problematic." and discusses why Gene added DHE-RSA-CHACHA20-POLY1305 in ssl-config-generator 5.7.json

[janbrasna]

Yes, for grading/testing consistency. Which is my point exactly with almost any similar change. If we promise a config tier, and a tool down the road uses that same definition to probe such config, and we fall short of the promise, that sucks.

E.g.. from another thread:

"I humbly request that we prioritize updating this site to be at least as strict as the specifications, but stricter is OK."

Is presence of any CCM8 "stricter", or "at least as strict"? Who decides that? (RHEL folks would say "no", FWIW…)

So to avoid similar discussions, unless the usage of the tool warrants such one-off deviation from the recommendation data (think known issues with interop, key size or rotation etc.), I'd prefer not to challenge that HERE, but be helpful upstream, in defining what should the recommended profiles be, and align with other security folks from other domains adding another views to the issue as well (it's not all http servers and web browsers…). More secure defaults are only better for everyone, and pointing that out via comments is a good way to show no fine-tuning is really needed — but at the same time, however you may dislike the Mozilla TLS recommendations, this is only to turn them consistently into a config example, as little opinionated as possible TBH.

If you want to add a band-aid over the recommendations you don't agree with as a server author, it should be clearly stated though (for visibility, and to find a way folks are aware of).

[gstrauss]

however you may dislike the Mozilla TLS recommendations

That is not the issue. The Mozilla TLS recommendations are outdated and currently appear to be unmaintained. They have been supplanted by more up-to-date and maintained security recommendations from other qualified professional organizations. One example: Cloudflare CDN https://developers.cloudflare.com/ssl/edge-certificates/additional-options/cipher-suites/recommendations/

As such, the Mozilla TLS recommendations, currently over 4 years old, should be reviewed and updated by Mozilla. Until then, they should be discarded and ignored in favor of current and maintained TLS recommendations from other qualified professional organizations. This is my professional opinion as a systems security programmer. I would defend this statement to any CISO, CIO, or CTO if any project manager tried to pull "but look at this spec!"

[gstrauss]

To hopefully keep this PR fresh and unblocked, I rebased this PR on the master branch and added a commit to emit 308 redirect only for Intermediate and Modern configs, leaving the existing lighttpd default redirect behavior (sending 301 for redirects) for the Old config.

--- a/src/templates/partials/lighttpd.hbs
+++ b/src/templates/partials/lighttpd.hbs
@@ -115,9 +115,11 @@ $HTTP["scheme"] == "https" {
     )
 }
 else $HTTP["scheme"] == "http" {
+ {{#unless (includes "old" form.config)}}
  {{#if (minver "1.4.31" form.serverVersion)}}
     url.redirect-code = 308
  {{/if}}
+ {{/unless}}
  {{#if (minver "1.4.50" form.serverVersion)}}
     url.redirect = ("" => "https://${url.authority}${url.path}${qsa}")
  {{else}}

@gene1wood: If that is still a blocker for you, please remove url.redirect-code from the lighttpd config and use the lighttpd defaults.

@janbrasna I updated #117 with links that note that Windows versions before Windows 10 are all end-of-life and no longer receiving security updates, and IE in Windows 10 is end-of-life and no longer receiving security updates, so any concern or questions about widespread support for 308 status code should have been resolved over a year ago.

[gstrauss]

@gene1wood: ping

Are there remaining questions or feedback preventing this PR from moving forwards?

---

With the release of lighttpd 1.4.75, the discussion over the almost !!! 3 year old !!! 308 Permanent Redirect issue #137 for Apache, and subsequent #139 for lighttpd is mostly moot for lighttpd since lighttpd 1.4.75 mod_redirect by default uses 308 for HTTP/1.1 (and later) requests, though lighttpd 1.4.75 still defaults to use 301 for HTTP/1.0 requests. This PR does not add url.redirect-code for lighttpd 1.4.75 and later, which is the same as the current behavior in ssl-config-generator.

To avoid sending information in query strings, POST is often used, so using 308 instead of 301 is important for proper security postures when URL redirects are necessary to maintain compatibility with site changes. It is a sad state of affairs that #137 has not been resolved in almost 3 years (!!!) with usage/transition guidance though modern, intermediate, and old configs.

[gstrauss]

To summarize the above points of potential contention:

Regarding cipher lists, I previously wrote:

I am not suggesting whether or not dhe-rsa-aes128-gcm-sha256 or dhe-rsa-aes256-gcm-sha384 should be included. I am saying that the [Mozilla] spec should be reviewed to see if they should, or should not be removed from the intermediate cipher list. Once that is refreshed (and not 3 1/2 years old), then we can have a more relevant conversation about whether or not ssl-config-generator should emit a cipher list to include those in the ssl-config-generator "Intermediate" lighttpd config.

The mozilla spec is now over 4 years old. I will commit to updating lighttpd.hbs to match the Mozilla specs as soon as the Mozilla specs are updated. @janbrasna, @gene1wood if you feel strongly that those ciphers should be included in the lighttpd intermediate config, please let's continue the conversation.

Regarding HSTS redirects with 308 Permanent Redirect, I previously wrote:

With the release of lighttpd 1.4.75, the discussion over the almost !!! 3 year old !!! 308 Permanent Redirect issue #137 for Apache, and subsequent #139 for lighttpd is mostly moot for lighttpd since lighttpd 1.4.75 mod_redirect by default uses 308 for HTTP/1.1 (and later) requests, though lighttpd 1.4.75 still defaults to use 301 for HTTP/1.0 requests. This PR does not add url.redirect-code for lighttpd 1.4.75 and later, which is the same as the current behavior in ssl-config-generator.

In this PR, the change in spec produced by ssl-config-generator is for lighttpd 1.4.31 - lighttpd 1.4.74 to add url.redirect-code = 308, but is once again removed (the same as current spec) for lighttpd 1.4.75 - lighttpd 1.4.76, the current release of lighttpd. @janbrasna if you have concerns, then I will remove the url.redirect-code = 308, as most users coming to ssl-config-generator for the first time are hopefully configuring the current version of lighttpd, where this is a non-issue.

https://repology.org/project/lighttpd/badges?exclude_unsupported=1 shows that the current releases of many popular distros are running lighttpd 1.4.76.

[gstrauss]

@gene1wood you are currently listed as reviewer on this PR. To give you a chance to comment, if you like, I'll wait another week before removing you as reviewer. I then plan to merge this PR. Thanks!

[janbrasna]

I've deliberately changed the title to better reflect the content — and will look into the individual changes and the complexity vs. benefits they add.

I originally envisioned this to be split into more actionable chunks if some of the changes are blocked on the specs, but will look into the formal compatibility and think about adding some comments to let the consumers know if the declared support profile from the sstls json can't be satisfied 100%.

The proposed logic is asking for another lighttpd author to review tbh;)

[gstrauss]

The proposed logic is asking for another lighttpd author to review tbh;)

lol. Please consider reviewing the commits individually. They are somewhat smaller.

I'm willing to create further smaller commits based on your feedback, and am interested in moving this forwards so that new users to this site benefit from recently updated recommendations, rather than outdated, years-old recommendations.

[gstrauss]

I am going to push a change so that for lighttpd 1.4.68 and later, for Intermediate config, the ciphers are listed, but commented out:

# lighttpd TLS defaults are widely supported by clients and should be preferred
#ssl.openssl.ssl-conf-cmd += ("CipherString" => "ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305")

[gstrauss]

The proposed logic is asking for another lighttpd author to review tbh;)

I am the sole author of the TLS modules in lighttpd since lighttpd 1.4.56 when I rewrote the older lighttpd mod_openssl code to openssl 1.0.2 interfaces and subsequently added support for openssl 1.0.0, 1.1.0, and 3.0.0. In lighttpd 1.4.56, I also wrote the lighttpd modules supporting alternative TLS libraries: GnuTLS, mbedTLS, wolfSSL, and NSS.

If you have more specific questions, I'll certainly pass them along to stbuehler, but I am not sure it is a good use of his time to bother him to wade into HandlebarJS and how its limitations and its use in ssl-config-generator logic leads to long, complex code conditions and duplication of results between various conditional statements.

Modern lighttpd still works with very old OpenSSL (though not recommended for security reasons), and supporting the matrix of many openssl and many lighttpd versions unfortunately leads to many conditions.

[janbrasna]

Yes, commented out with a reasoning info might be the way to expose that. (But would like to discuss in a broader meeting first.)

Please note this is currently not broken or buggy, so the priority is lower than some of the bugfixes and compatibility updates that will need more attention first (quite the opposite, the new edge cases this brings need to be documented etc., so it actually introduces new known issues to tiptoe around…) — I think we should do a review meeting, or raise the more "meta" questions, that shouldn't be mixed up with feature bumps, beforehand, though. I will be able to address these within the next weeks, not hours or days.

@gstrauss When you have a chance, please squash any version bumps that don't include any actual output logic impact into the next feature commit, trying to fixup as much of the noise for easier review of the whole timeline… Thanks.

[janbrasna]

The proposed logic is asking for another lighttpd author to review tbh;)

lol. Please consider reviewing the commits individually. They are somewhat smaller.

They certainly include more rationale individually, with explainers in commit messages, but still as a whole this brings so much tribal knowledge necessary to understand what's the reason for every single condition, that nobody else would be able to maintain it;)

I'm looking into some reasonable hbs comments (i.e. not published to output, but describing the template code), but they do seem to muck up the output whitespace, so I had not much luck trying them out…

[gstrauss]

@gstrauss When you have a chance, please squash any version bumps that don't include any actual output logic impact into the next feature commit, trying to fixup as much of the noise for easier review of the whole timeline… Thanks.

squashed and rebased on tip of master

Please note this is currently not broken or buggy, so the priority is lower than some of the bugfixes and compatibility updates that will need more attention first

It is years out-of-date, so should be considered buggy, similar to providing advice for EOL openssl versions and not providing the best advice for supported openssl 3.x versions (#256). Yes, broken parts of the site should get priority. Then buggy issues immediately after.

[gstrauss]

I'm looking into some reasonable hbs comments (i.e. not published to output, but describing the template code), but they do seem to muck up the output whitespace, so I had not much luck trying them out…

Have you tried HTML comments? <!-- ... --> It would be better not to bloat the pages, but appropriate comments are better than none.

[gstrauss]

Added comment to the template:

 # lighttpd TLS defaults are widely supported by clients and should be preferred
 # See https://wiki.lighttpd.net/Docs_SSL
+# Uncomment to better match the *less secure* Mozilla {{form.config}} spec.
 #ssl.openssl.ssl-conf-cmd += ("CipherString" => "{{{join output.ciphers ":"}}}")