Open Bug 1847918 Opened 1 year ago Updated 1 year ago

HTTPS-only mode is ignored when reopening closed tab

Categories

(Core :: DOM: Security, defect, P2)

Product:
Core
Component:
DOM: Security
Version:
Firefox 117
Type:
defect

Tracking

()

Status:
ASSIGNED
Tracking Flags:
Tracking Status
firefox-esr102 --- unaffected
firefox-esr115 --- unaffected
firefox116 --- unaffected
firefox117 --- fix-optional
firefox118 --- affected
firefox119 --- affected

People

(Reporter: 6k64x4ma, Assigned: mjurgens, NeedInfo)

References

(Regression)

Details

(Keywords: regression, Whiteboard: [domsecurity-active])

Attachments

(2 files)

Kooha-2023-08-09-13-51-34.webm
(deleted), video/webm
Details
Bug 1847918 - Limit `nsDocShellLoadState::IsExemptFromHTTPSOnlyMode` to HTTPS-First r?freddyb
(deleted), text/x-phabricator-request
Details

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

Steps to reproduce:

  1. Set dom.security.https_only_mode to true.
  2. Go to http://http.badssl.com/ in the new tab. Secure Site Not Available page appears.
  3. Close the tab (ctrl + w).
  4. Reopen the tab (ctrl + shift + t).

Actual results:

http.badssl.com is loaded.

Expected results:

Loading HTTP site should be blocked.

Regression window
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=29a59c4a2f6ab17b86054f5d8c0d18893b0da18a&tochange=b242365f7a2f1101b3edf116b24ba5a2bac9bc7b

Flags: needinfo?(mjurgens)

I can not reproduce this on my end. I tested the latest Nightly, and mozilla-central builds from 2023-06-10 (before the commits you linked) and 2023-06-12 (after the commits you linked). I will attach a screen recording of my attempt.

Just to confirm, did you click the "Continue to HTTP Site" button? Because if you did, what you describe would be the expected behavior.

Flags: needinfo?(mjurgens) → needinfo?(6k64x4ma)
Attached video Kooha-2023-08-09-13-51-34.webm (deleted) —

I didn't click the button.

On the latest Nightly with a new profile, I followed the exact same steps as you did in the screen recording, but http.badssl.com is loaded.

Flags: needinfo?(6k64x4ma)

I can reproduce the problem now. I tested the wrong date because I misread it, it should be 2023-07-12, not 2023-06-12, and it seems I did something wrong when testing it with Nightly originally, my bad.

Assignee: nobody → mjurgens
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Keywords: regression
Regressed by: 1838183
No longer regressed by: 1838183
Regressed by: 1839612

Thanks a lot for the report. This seems to be the code causing the page to load here.

The same issue is also happening with history navigation, so for example:

  1. Set dom.security.https_only_mode to true
  2. Open http://http.badssl.com
  3. In the same tab, open https://google.com
  4. Press the back button

Result: http://http.badssl.com is loaded via HTTP.
Expected: http://http.badssl.com should be prevented from loading.

Set release status flags based on info from the regressing bug 1839612

status-firefox116: --- → unaffected
status-firefox117: --- → affected
status-firefox118: --- → affected
status-firefox-esr102: --- → unaffected
status-firefox-esr115: --- → unaffected
Attachment #9348212 - Attachment description: WIP: Bug 1847918 - Limit nsILoadInfo::HTTPS_ONLY_EXEMPT_NEXT_LOAD to HTTPS-First → WIP: Bug 1847918 - Limit nsDocShellLoadState::IsExemptFromHTTPSOnlyMode to HTTPS-First r?freddyb
Attachment #9348212 - Attachment description: WIP: Bug 1847918 - Limit nsDocShellLoadState::IsExemptFromHTTPSOnlyMode to HTTPS-First r?freddyb → WIP: Bug 1847918 - Limit `nsDocShellLoadState::IsExemptFromHTTPSOnlyMode` to HTTPS-First r?freddyb
Attachment #9348212 - Attachment description: WIP: Bug 1847918 - Limit `nsDocShellLoadState::IsExemptFromHTTPSOnlyMode` to HTTPS-First r?freddyb → Bug 1847918 - Limit `nsDocShellLoadState::IsExemptFromHTTPSOnlyMode` to HTTPS-First r?freddyb
Severity: -- → S3
Priority: -- → P2
Whiteboard: [domsecurity-active]

Tom, IIUC, Freddy is on PTO at the moment. Do you have cycles to review this given that 117 goes to RC next week?

Flags: needinfo?(tom)

I'm sorry, with Freddy and Christoph out I think we're going to have to wait - I don't feel comfortable reviewing this.

Flags: needinfo?(tom)

Not likely to make Fx117 before it goes to RC in that case. We'll keep it on the radar for a dot release at least.

Set release status flags based on info from the regressing bug 1839612

status-firefox119: --- → affected

Malte, are you working on this one for a potential uplift or should it ride the trains?

Flags: needinfo?(mjurgens)
Flags: needinfo?(fbraun)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: