Changes requested for Caddy

[gene1wood]

From the server authors:

Caddy v2 doesn't support lower than TLS 1.2 at all (because older TLS versions are completely broken). So all those clients won't work.

IMO the "old" option for Caddy should be totally disabled. The intermediate option should remove all tls config (irrelevant) and turning off TLS 1.2 with "modern" is kinda silly and counterproductive, so I'd also just remove the tls config for that option as well.

Caddy's defaults are secure, there's no reason to tune cipher suites, and configuring cipher suites has no effect at all when using TLS 1.3 because the Go stdlib automatically ordering them. See https://go.dev/blog/tls-cipher-suites as I mentioned earlier.

Also, Caddy doesn't use OpenSSL, the website makes it seem like it uses it by showing the OpenSSL version on the right. And Caddy v2.1.1 is a long-since EOL version.

Caddy v1 is no longer supported, so it does not make sense at all to continue showing config for it. Don't recommend config for EOL software, please.

— Originally posted in #153 by @francislavoie

[gstrauss]

@gene1wood @janbrasna I agree with @francislavoie that the config should be much simpler since Caddy defaults and Go TLS library defaults are solid. I have submitted #261 with a much simpler config, though I have retained the ciphers specification for the moment due to prior historical discussions. I hope that Mozilla will update the specs and that we discuss preferring to use practical, common sense, and secure settings from apps such as Caddy and lighttpd which provide secure settings, rather than pedantically trying to shoehorn configurations to match specifications, which may reduce security and may be outdated.

[gene1wood]

I hope that Mozilla will update the specs and that we discuss preferring to use practical, common sense, and secure settings from apps such as Caddy and lighttpd which provide secure settings, rather than pedantically trying to shoehorn configurations to match specifications, which may reduce security and may be outdated.

@gstrauss Would it make sense to start an issue here https://github.com/mozilla/server-side-tls on this topic? I'm not sure if the solution here is a change to the TLS profile recommendations or something else.

[janbrasna]

1. I'd like to discuss such "meta" things outside of otherwise actionable issues & PRs; and separately before trying to get such changes in, in individual cases (without any broader visibility and systemic take on it.) — for some configs there are consumers expecting the exact setup they then test against using the same spec and expect that to match etc.; TBD separate discussion.
2. The Caddy config needs major fixes nonetheless, and while I'll open separate discussion about how to approach the servers where the authors wish to use defaults instead, the more important topic of this particular request is dropping old versions. Generally, I'd like to discuss that too — but in this particular case we only supported the v1.x product up to v5.4 specs and left them "frozen in time" in that state, and that's something I'm okay with dropping as we don't have the bandwidth to keep them (manually) up to the current recommendations. In such cases removing old template logic is A-OK.
3. What I will open, is the reduction of different cipher dictionaries, because the only reason to keep iana, go and caddy separately was some naming wrinkles that should be resolved in real world by aliasing the cipher names on Go side… (also spec issue, will open there.)

Other than that — if there is a spec condition that can't be satisfied by the product, a comment pointing it out is just fine to make sure consumers know what to expect (and we will be adding a lot of those as products remove the ability to do stupid things even for those who have a reason to;D).

[gstrauss]

I agree with @janbrasna that we should discuss a variety of things before making specific actionable requests. This sounds like an agenda for our Nov meeting. :smile:

https://github.com/mozilla/server-side-tls does not look like it has had any activity from maintainers in a year and a half since @gene1wood added TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256. I think it would be a good idea to establish stewardship of that repo and would like to request that the specifications be reviewed at least once a year, though not necessarily updated yearly. If Mozilla is not able to commit to regular periodic maintenenance, then I think we should discuss whether or not to shift this repo to follow the better-maintained recommendations from one of the larger CDNs, which also have lots of data on which to check compatibility and to back their recommendations.

[gstrauss]

While I understand @janbrasna desire to have reproducible recommendations via permalinks, that is not a current feature of the site, e.g. with the implementation detail of the site generation following latest.json. There is a feature request in #240 and we should continue that discussion there.

Both the caddy developer and I (lighttpd developer) have expressed sincere misgivings about this site being out-of-date and failing to provide new site consumers with configuration advice for current best practices. It is my focus to fix this deficiency sooner rather than later.

I humbly request that we prioritize updating this site to be at least as strict as the specifications, but stricter is OK. After the now 4+ year-old (out-of-date) guidelines are updated, we can revisit providing configurations which more strictly match the guidelines.

[janbrasna]

This had nothing to do with accessing old configs via permalinks. The actual v5.4-era config was hardcoded inside the Caddy1 template, served even for current v5.7 config data. That was the biggest reason to drop the support.

[janbrasna]

@gstrauss It attracts a different group of interested parties; there are consumers of the specs who are not consumers of the configs here so are not part of the discussions here, but should have the visibility into the topics over there.

(New ownership is promised from MoCo Security Assurance if I understood it right. Once set up, I believe we'll be in sync a lot more, upstreaming some changes that we collect here…)

I would like to avoid having to discuss "meta" topics in every single PR or issue, so within a few weeks I'll start raising those general themes either as issues, or discussion posts, we'll see what works better…

Until then, I'll just resort to "TBD" of sorts not having to fish for the info across dozens of tickets when time comes for collecting all of that into one single thread.

TL;DR: The content of configs change. Features should trigger a "not supported" errors instead of basing that on "name" of config etc. Whether something should be omitted or not is decided elsewhere, and I'll open the discussion about how to handle the defaults where the authors want their defaults instead of the guideline data (aside from removing the server from the tool, or capping the versions for which we return the configs to some older-only, that needed it, and just showing a message explaining that situation for current versions).

Also, Caddy doesn't use OpenSSL, the website makes it seem like it uses it by showing the OpenSSL version on the right.

This was a bug, fixed now, disabling the input for servers not using it.

And Caddy v2.1.1 is a long-since EOL version.

Anyone can submit PRs updating server versions. We usually only bump them when making changes to the actual logic, i.e. when new versioning conditions need to be added or something fixed.

Caddy v1 is no longer supported, so it does not make sense at all to continue showing config for it. Don't recommend config for EOL software, please.

Nothing is being recommended, only folks can manually generate outputs for any version that was ever supported and not explicitly removed, by manually changing the input value, or following a permalink. As long as there's no extra effort to keep the logic in, it stays. It's never presented to anyone, only the most recent configured version.

Some of the topics were spun out to separate issues, some will warrant a broader discussion.

Also, for the laughs: #3 (Caddy was mentioned years ago as the reason to actually disable any recommendation selection etc. in favour of its defaults;D)