Closed rugk closed 7 months ago
Actually, the /
matcher is harmful in this case, because it only matches requests to exactly /
and nothing else. Removing it makes it match all requests which is what it should do.
In Caddy v1, path matching was by prefix, but in v2, path matching is exact, so /
is not correct.
Okay, so this is an argument in favor of this PR, is not it? :thinking:
So it should match all requests, of course.
Yes, definitely. This change needs to be made.
Honestly though, I'd rather if the recommended config in all cases for Caddy is just "use the defaults". It's a bad recommendation to suggest overriding the ciphers or TLS versions at all, unless absolutely necessary.
The docs say as much: https://caddyserver.com/docs/caddyfile/directives/tls
Caddy's default TLS settings are secure. Only change these settings if you have a good reason and understand the implications.
Suggesting that users set ciphers or protocol versions may cause users to shoot themselves in the foot, because if Caddy changes its defaults due to a new vulnerability found in one of those ciphers or versions, users who update Caddy would not get the latest secure defaults.
Really, it should just be this, in all cases:
# {{output.header}}
# {{{output.link}}}
# replace example.com with your domain name
example.com {
{{#if form.hsts}}
# HSTS ({{output.hstsMaxAge}} seconds)
header Strict-Transport-Security "max-age={{output.hstsMaxAge}}"
{{/if}}
}
Caddy v2 does not support TLS 1.0 or TLS 1.1. It's not possible to enable them either. We made the decision to prevent it because they have known security issues, and we want the web to move forwards.
Caddy v2 enables TLS 1.2 and 1.3 by default.
There's currently no good reason to turn off TLS 1.2, because the defaults use known-good cipher suites, driven by Golang's automatic ordering of cipher suites. See https://go.dev/blog/tls-cipher-suites
@rugk Thanks for the fix.
@francislavoie I'm not that familiar with Caddy. The purpose of the 3 configuration profiles is to allow for a worse security posture with Old
to be able to serve older clients while providing a better security posture with Modern
if you don't need to support old clients.
Do you know how Caddy approaches this (balancing good security with support of older clients)? Would the default configuration you suggest support the Old
clients like
Firefox 1, Android 2.3, Chrome 1, Edge 12, IE8 on Windows XP, Java 6, OpenSSL 0.9.8, Opera 5, and Safari 1
If you can share more detail on this in a new GitHub issue, we can work on figuring out how to best balance it.
This is deployed
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.
FWIW the Caddy config supports both Caddy v1.x and v2.x at the same time. So while the defaults are chosen wisely in Caddy v2.x, this tool still helps with configuring Caddy v1.x according to the Mozilla TLS recommendations.
Having safe defaults is great. This config generator doesn't asses any server version's defaults, but rather helps turning Mozilla's JSON recommendations of the three tiers into the server config. Nobody is forced to use them. They're just "recommendations", and reflect the currently published https://ssl-config.mozilla.org/guidelines/latest.json
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.
The matcher
/
for the Caddy header is not really necessary, as it is optional here. The default for matchers is the match *, i.e. every request. Matching everything in the path/
is basically the same (I tested it), so this change should make no difference.See https://caddyserver.com/docs/caddyfile/directives/header