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.

[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).

[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)