1887796 - HTTP-Only mode exceptions are ignored when using frame/iframe from a page loaded from file://

Status: UNCONFIRMED

(Core :: DOM: Security, task, P4)

Description

[KKME]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:124.0) Gecko/20100101 Firefox/124.0

Steps to reproduce:

Turned on HTTP-Only Mode

Loaded a webpage from the hard drive using file://
File contains a set of frames to load pages from multiple external sites, two of which do not support HTTPS. Both of the non-HTTPS sites are listed in the HTTPS-Only exceptions list.

Actual results:

The frames on the non-HTTPS sites generated an "HTTPS-Only Mode Alert" even though they are in the exceptions list.
If the identical page is loaded from a web server, the HTTPS-Only Mode exception is honored and all pages load correctly.

Expected results:

Non-HTTPS sites should have loaded in HTTP mode.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::DOM: Security' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Daniel Veditz [:dveditz]]

Malte: I think I heard you say there was debate about whether https-only exceptions should apply to resource loads, and this example is one of many that shows why they should (I know I've so far not been on the winning side of that argument). There's probably a duplicate for this?

Comment 3

[Malte Jürgens [:maltejur]]

Attachment: bug1887796.html

Yes, this seems to be related to Bug 1869995. In both we block insecure subresources on local pages, and it is unclear to the user how to add exceptions for that.

In this bug specifically, I can see the following problems with a small testcase that I also attached here:

1. The HTTPS-Only identity pane UI seems broken. When opening the testcase as a local file with HTTPS-Only enabled, you can see that clicking on the small file icon in the address bar displays a drop-down list with an empty value. The value should be either "On", "Off" or "Off temporarily" though. Setting the value to "Off" also doesn't set any exception permissions.
2. Clicking on the "Continue to insecure site" button in the iframe seems to crash the iframe.
3. Manually adding a exception for file:///<path to>/bug1887796.html in the HTTPS-Only section of the settings allows the iframe to load, but strangely enough still blocks subresources of that iframe. In my testcase you can see that the stylesheet in the iframe gets blocked by HTTPS-Only.

All of these things don't happen when opening the testcase from via a https:// url. There we can correctly add a exception in the identity pane and through the "Continue to insecure site" button in the iframe. In both those cases, a exception for the top-level page will be added. Of course the iframe will still be blocked by mixed content blocking after that, but disabling that through "Address Bar Lock Icon > Connection Secure > Disable Protection for now" will make the iframe load completely, including the iframes subresources.

So I think for this bug, fixing these three problems would resolve this bug, as the user should then have an easy way to add a top-level exception through the "Continue to insecure site" button.

Sidenote: When mixed content blocking blocks a iframe, there seems to be no indication of that to the user, just a white page. That gets especially confusing when the user just allowed the iframe to load for HTTPS-Only mode. Maybe we should do something about that.

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:freddy, could you have a look please?

For more information, please visit BugBot documentation.