Doesn't load silk.apana.org.au with "Enable HTTPS-Only Mode in all windows" setting
Categories
(Core :: DOM: Security, defect)
Tracking
()
People
(Reporter: lbotka2, Unassigned)
References
Details
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:83.0) Gecko/20100101 Firefox/83.0
Steps to reproduce:
- connect http://silk.apana.org.au/
- connect http://silk.apana.org.au/fc.html
Actual results:
https://silk.apana.org.au/
Forbidden
You don't have permission to access this resource.
Apache/2.4.38 (Debian) Server at silk.apana.org.au Port 443
https://silk.apana.org.au/fc.html
Not Found
The requested URL was not found on this server.
Apache/2.4.38 (Debian) Server at silk.apana.org.au Port 443
Expected results:
Load the site
When the error appears, HTTPS-Only is ON on the Lock icon, setting OFF doesn't help either.
To use this site I have to disable the "Enable HTTPS-Only Mode in all windows" setting.
An exception feature would be useful to the "Enable HTTPS-Only Mode in all windows" setting. to disable this setting for such sites.
It seems like we set the permission to not upgrade from HTTP to HTTPS on the current principal. If the current principal is for a HTTPS page that this is not really useful. There is already code the change the scheme from HTTPS to HTTP in certain cases (_isAboutHttpsOnlyErrorPage), but that doesn't help for servers that respond successfully with HTTPS content, but with an useless page.
This code needs to be adjusted: https://searchfox.org/mozilla-central/rev/cbcd544b1cd13b2fc0175bc9fae3d7909ca941e7/browser/base/content/browser-siteIdentity.js#585
|
||
Comment 2•4 years ago
|
||
Hi László, thanks for reporting this!
You came across a weird edge case where web-servers are able to respond with HTTPS, but don't serve the correct content. Sadly we can't detect that, because for Firefox the site is responding and seems to work just fine.
Your suggestion for an interface to add exceptions is a good idea, and we already created bug 1662710 for that, so I'm gonna mark this one as a duplicate.
Since this is a web compatibility issue, what you could do is try to reach out to the websites-owner.
@evilpie For the permissions-API – which we're using for HTTPS-Only Mode – pages with the same hostname but different schemes are treated separately :( That's why there is this differentiation in the code.
If a user is on the error-page we know there is no HTTPS-Version at all, so we set the exemption for the http-page and redirect the user there. But if the user is on a working HTTPS-Page the assumption is that the server can serve the page just fine, but subresources can't get upgraded. So the HTTPS-page is exempt from further upgrades.
You're right, that doesn't help in cases where the server responds with useless content, but as this is probably an edge-case anyway, the best way to help users out is to implement the UI proposed in bug 1662710.
Description
•