Secure Connection Failed on old browsers


(Kevin Le Starge) #1

Caddy version: 0.10.4

Caddyfile:

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.


(Matthew Fay) #2

Hi @kblestarge,

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.

https://caddyserver.com/docs/tls


(Kevin Le Starge) #3

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?


(Matthew Fay) #4

Caddy really only has two options when a request for an insecure protocol or cipher comes in:

  1. Accept it
  2. 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.


(Kevin Le Starge) #5

Got it. Thank you!


(Matthew Fay) #6

No worries.

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.


(system) #7

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.