You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
HTTPS-RR is a relatively recent mechanism to allow sites to advertise HTTPS support over DNS. Browsers are expected to always redirect to HTTPS for domains with HTTPS records, but this is currently unreliable (per https://bugs.chromium.org/p/chromium/issues/detail?id=1441214). Cloudflare will always serve an HTTPS record for proxied subdomains when HTTPS is enabled for the domain, even if the subdomains have HTTPS disabled or broken (as is the case for example.com.psim.us-style domains).
I'm not sure what the correct solution here is, but this will cause more and more problems over time if unaddressed. It already causes inconvenience for development, and makes connecting to an unregistered third-party generally require changing browser settings.
Perhaps a solution for unregistered servers might be to use a live domain supporting ?~~host:port?
The text was updated successfully, but these errors were encountered:
HTTPS-RR is a relatively recent mechanism to allow sites to advertise HTTPS support over DNS. Browsers are expected to always redirect to HTTPS for domains with HTTPS records, but this is currently unreliable (per https://bugs.chromium.org/p/chromium/issues/detail?id=1441214). Cloudflare will always serve an HTTPS record for proxied subdomains when HTTPS is enabled for the domain, even if the subdomains have HTTPS disabled or broken (as is the case for example.com.psim.us-style domains).
Per https://community.cloudflare.com/t/http-only-site-broken-in-chrome-only-chromium-said-the-problem-is-https-rr-bug-report/506153/10, Cloudflare recommends disabling TLS entirely for domains where some subdomains may need to be connected to via HTTP. This seemingly makes TLS support for psim.us all-or-nothing. Additionally, it's impossible to support TLS for example.com.psim.us-style domains, due to limitations of wildcard certificates.
I'm not sure what the correct solution here is, but this will cause more and more problems over time if unaddressed. It already causes inconvenience for development, and makes connecting to an unregistered third-party generally require changing browser settings.
Perhaps a solution for unregistered servers might be to use a live domain supporting
?~~host:port
?The text was updated successfully, but these errors were encountered: