{
servers {
max_header_size 64KB
protocol {
experimental_http3
}
timeouts {
idle 30s
read_body 30s
read_header 30s
write 30s
}
}
}
(kiss) {
header {
-server
expect-ct "enforce, max-age=9999"
permissions-policy "camera=(), microphone=()"
referrer-policy strict-origin-when-cross-origin
strict-transport-security "max-age=63072000; includesubdomains; preload"
x-content-type-options nosniff
x-frame-options deny
x-xss-protection "1; mode=block"
}
}
(main) {
@end_slash path_regexp xx (.+)/$
@live_server not path /file_server/*
file_server
handle_errors {
file_server
header content-security-policy "base-uri 'none'; default-src 'self'; form-action 'none'; frame-ancestors 'none'; frame-src 'none'; object-src 'none'; script-src 'sha256-●●●●●'; style-src 'sha256-●●●●●'"
import kiss
rewrite * /file_server/maintenance.v1.html
}
import kiss
redir @end_slash {http.regexp.xx.1} 308
root * /etc/caddy
}
mywebsite.com {
import kiss
redir https://www.mywebsite.com{uri} 308
}
pig.mywebsite.com {
@unauthorized not header ●●●●● ●●●●●
import main
respond @unauthorized "The request is understood but has been refused by the proxy server." 403
reverse_proxy @live_server 10.10.1.3:8080
}
www.mywebsite.com {
import main
reverse_proxy @live_server 10.10.1.9:8080
}
3. The problem I’m having:
I would like to redirect all TLS 1.1 and earlier requests to an error page, so that the user gets some feedback as to why he / she cannot access my website. Is this at all possible with Caddy?
4. Error messages and/or full log output:
n/a
5. What I already tried:
I could not find any relevant information.
6. Links to relevant resources:
Perhaps not very helpful, but an old example using nginx is described in this stackoverflow post:
Caddy v2 doesn’t actually support TLS 1.1 or below, meaning the TLS handshake will never complete. If the handshake doesn’t complete successfully, the browser will always display an error. So what you want to do isn’t possible with Caddy. Your users simply need to upgrade to newer clients that support secure protocols.
While this is correct, I want to clarify that Caddy can do this, but you’d have to manually patch in support for TLS 1.1:
A one-line change would make it possible. I don’t recommend this, but in your case if you give a helpful error message on TLS 1.1 then I suppose I won’t judge.
Indeed users need to upgrade. It’s just that, in my case, the average user is a 60 years old male, he uses the internet to do specific things, and our competitors’ websites don’t care about internet security. I therefore fear that our website might be marked dysfunctional, vis-à-vis our permissive (hence operational) competitors, long before the inevitable browser upgrade.
Mine is a bit of an edge case, I know. But I would be thrilled if, one day, Caddy supported this functionality out of the box. It would enable people like me, for example, to discontinue TLS 1.2 support early, instead of having to wait for everyone else to do it first.
That would be a security regression, so the chances of Caddy changing to re-add TLS 1.1 support is close to zero.
Like Matt said, your best bet is to make a custom build of Caddy that enables it. The good news is that building Caddy is very easy since it’s written in Go.
I do not expect TLS 1.1 support to be re-added. My hope was that there might be room for a middle tier between supported and unsupported protocols (say deprecated protocols), of which TLS 1.2 will eventually become the first member. A simple matcher (say tls_deprecated) could then be used to redirect requests (to an informative error page). As I said, this would be a security enhancement, as it would enable Caddy users to discontinue TLS 1.2 support sooner rather than later.
