mydomain.com {
root /path/to/my/root
gzip
rewrite {
if {file} not sitemap.xml
to {path} {path}/ /index.html
}
# Fix for service worker not updating app until 24h later
header /service-worker.js {
Cache-Control no-cache
}
}
www.mydomain.com {
redir https://mydomain.com{uri}
}
I have an error tracking system (Sentry) installed on my production site’s front-end (Angular SPA). I am often seeing errors come in that say something about security problems.
Also, I ran a cross-browser test using browsershots and it showed a bunch of “Secure Connection Failed” errors for old machines on legacy browsers. The errors look related to SSL and/or TLS. Here’s a list of errors from the snapshots:
err_ssl_protocol_error
ssl_error_no_cypher_overlap
ssl_error_protocol_version_alert
err_ssl_version_or_cipher_mismatch
err_no_ssl_versions_enabled
I think the problem is related to Caddy. Maybe it’s an issue that has been fixed and I just need to download the latest version? Or maybe there is a TLS configuration that I am missing?
Caddy error log doesn’t have any relevant information. Please help.
This is expected behaviour - Caddy prefers by default to only use protocols and ciphers that are generally believed to be secure by modern standards.
You can expand Caddy’s compatibility to legacy clients - at the cost of security - by changing its accepted protocol range and/or changing its cipher list with the tls directive.
Great, just making sure I don’t have a configuration error --good to know I don’t have to worry.
However, I’m confused as to why older browsers/clients require special treatment which consequently makes the web application more insecure. It seems like they want you to tighten up some screws in order for them to not freak out. But you’re telling me we would need to looses some screws? Do you mind explaining that to me?
Caddy really only has two options when a request for an insecure protocol or cipher comes in:
Accept it
Deny it
If your legacy client only knows insecure protocols, it can’t talk to Caddy securely. If Caddy needs to allow insecure protocols so your legacy clients can talk to it, any client could use these insecure protocols, including clients designed to exploit vulnerabilities in those protocols. So, by increasing your compatibility, you’re opening up Caddy for possible exploitation.
It is worth noting that Caddy’s defaults are by no means overly restrictive - the vast, vast majority of modern clients will have no issue connecting. It’s really only likely that you’ll see these issues in real life with really old phones, for example, or Internet Of Things devices that never get updated.