HTTPS-Only mode interstitial shown for a broken site
Categories
(Core :: DOM: Security, defect, P3)
Tracking
()
People
(Reporter: mt, Unassigned)
References
(Blocks 1 open bug)
Details
STR:
- Type "revoked.badssl.com" into the address bar.
What happens:
The HTTPS-Only interstitial is shown.
You can click through that screen, but you then land on the error page showing that the certificate has been revoked.
What should happen.
If TLS is busted in a finite and knowable way, skip the interstitial. If the unencrypted version redirects to HTTPS, skip the interstitial.
Comment 1•6 months ago
|
||
Mh, I wonder if our error page comes to early to know if why the HTTPS connection failed. Doesn't it warn before a link is actually followed (which would then subsequently allow us to learn that there's a broken cert)?
I think we should look at it and I believe the code to display the error is somewhere near https://searchfox.org/mozilla-central/rev/527d691a542ccc0f333e36689bd665cb000360b2/docshell/base/nsDocShell.cpp#3642
Comment 2•6 months ago
•
|
||
(In reply to Frederik Braun [:freddy] from comment #1)
Mh, I wonder if our error page comes to early to know if why the HTTPS connection failed.
No, at the point we show the HTTPS-Only error, we already know it is a SEC_ERROR_REVOKED_CERTIFICATE
. We currently just consider that error code to be a reason to potentially downgrade again if the user chooses to do so. This is the place where this is decided.
So we are behaving more or less as expected here. But we can discuss if we should change the current behavior.
(In reply to Martin Thomson [:mt:] from comment #0)
What should happen.
If TLS is busted in a finite and knowable way, skip the interstitial.
If this is indeed what we want, that can be easily achieved by adding the relevant error codes to the function I also linked to earlier. But do we really want to do this? If a site has a revoked/expired certificate and a user still wants to visit it (maybe the site owner just forgot to renew the certificate and the site just contains static content), normally they can just change the scheme in the address bar. But if HTTPS-Only is enabled, and with us not showing the HTTPS-Only page, there will be no obvious way for the user to visit the HTTP version of the site. They could add an exception under the HTTPS-Only section in the settings or under the lock icon, but I don't think users would intuitively go there.
Instead of skipping the HTTPS-Only error page for tls errors, I wonder if we should just surface the underlying error code on the HTTPS-Only page better. So include a sentence or a paragraph on the page, explaining why the secure site is not available. I know there is currently ongoing work on refreshing all the necko error pages, so maybe we could tie that in there if we want to.
If the unencrypted version redirects to HTTPS, skip the interstitial.
This is different from the first point, and I think not a good idea. When the HTTPS-Only error currently is being shown, we have no idea what would happen on http. To figure that out, we would need to do a new http request to the same site after the https request fails. That would mean:
- The user would need to wait longer (the duration of the http request) before the error page can be shown
- In a configuration where it would be otherwise hidden (with ECH, etc.), the hostname of the site we try to connect to would be leaked through the http request
Comment 3•5 months ago
|
||
If the unencrypted version redirects to HTTPS, skip the interstitial.
This is different from the first point, and I think not a good idea. [...] To figure that out, we would need to do a new http request to the same site after the https request fails.
I agree 100% with Malte. the "ONLY" in HTTPS-only is a promise we won't be leaking things to http without explicit user consent. That leads to many user annoyances like the whole HTTPS-Only error page in the first place, but that's what these hard-core "HTTPS-Everywhere" refugees want. Normal people want HTTPS-First which will not have this problem.
Description
•