Closed Bug 1725800 Opened 4 months ago Closed 4 months ago

Don't consider it's a upgrade downgrade loop if the uri path is different

Categories

(Core :: Networking, defect, P1)

Firefox 91
defect

Tracking

()

VERIFIED FIXED
93 Branch
Tracking Status
firefox-esr78 --- unaffected
firefox-esr91 --- wontfix
firefox91 --- wontfix
firefox92 --- wontfix
firefox93 --- verified

People

(Reporter: Fanolian+BMO, Assigned: kershaw)

References

(Regression, )

Details

(Keywords: nightly-community, regression, reproducible, Whiteboard: [necko-triaged])

Attachments

(2 files)

+++ This bug was initially created as a clone of Bug #1725026 +++

The issue below is similar to bug 1725026 but that does not fix my issue.

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:93.0) Gecko/20100101 Firefox/93.0
Build ID: 20210814094200

Steps to reproduce

  1. Enable HTTPS-Only Mode in all windows. Make sure dom.security.https_only_mode_break_upgrade_downgrade_endless_loop is true.
  2. Open https://www.hkepc.com/ (a Chinese tech forum)
  3. Click on 討論區, which locates at the end of the top bar which writes "主頁 專題報導 新聞中心 新品快遞 超頻領域 流動數碼 生活娛樂 會員消息 討論區". (See the attached screenshot if you cannot find it.)

Actual result

HTTPS-Only Mode Alert is triggered. Clicking Continue to HTTP Site will load https://www.hkepc.com/forum/.

Expected result

No alert is triggered.

Notes

  1. The link at 討論區 points to https://www.hkepc.com/forum but the final destination is https://www.hkepc.com/forum/ (with a trailing slash).
  2. Left/Middle/Right click at the link -> Open Link in New YYY all trigger the alert.
  3. Unlike bug 1725026 comment 2, copying https://www.hkepc.com/forum -> open a blank new tab -> paste link will also trigger the alert.

Workarounds

  1. Set dom.security.https_only_mode_break_upgrade_downgrade_endless_loop to false. Or
  2. Disable HTTPS-Only Mode. (it will still reach https://www.hkepc.com/forum/.)

Regression

Same with bug 1725026, this is regressed by bug 1716069.

Flags: needinfo?(kershaw)
Has Regression Range: --- → yes
Has STR: --- → yes
Regressed by: 1716069
See Also: → 1725026

A short summary for this issue:

  1. The case in bug 1725026: The load is triggered by user gesture and we do HTTPS upgrade because of HTTPS-only mode.
    I think the patch in bug 1725026 is reasonable, since we do user gesture check for the first load.

  2. The case in this bug: A link points to https://www.hkepc.com/forum and the server returns a 301 with location http://www.hkepc.com/forum/.
    This is not a upgrade and downgrade loop, since the uri path is actually different. The problem here is that we only check host name in nsHTTPSOnlyUtils::IsUpgradeDowngradeEndlessLoop. To fix this, I think we should also check the path here.

  3. The case in bug 1716069: this is actually an upgrade and downgrade loop.
    If we revert the changes in bug 1716069, nsHTTPSOnlyUtils::IsUpgradeDowngradeEndlessLoop will return false and we'll reach redirection limit (NS_ERROR_REDIRECT_LOOP)in the end. Note that not just HTTPS RR leads to NS_ERROR_REDIRECT_LOOP, but also HTTPS-only mode.

Assignee: nobody → kershaw
Flags: needinfo?(kershaw)
Whiteboard: [necko-triaged]

The previous comment was edited, since I think the root cause of this bug is that we only check if the host in identical in nsHTTPSOnlyUtils::IsUpgradeDowngradeEndlessLoop. When a page/server wants to redirect a uri with a different path, it should not be a upgrade and a downgrade loop.

Summary: HTTPS-only mode no longer works as it did before Firefox 91 (Part 2) → Don't consider it's a upgrade downgrade loop if the uri path is different
Pushed by kjang@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/033420d6bd56
Also check if the uri path is the same when doing upgrade and downgrade loop check, r=ckerschb
Status: UNCONFIRMED → RESOLVED
Closed: 4 months ago
Resolution: --- → FIXED
Target Milestone: --- → 93 Branch

The patch landed in nightly and beta is affected.
:kershaw, is this bug important enough to require an uplift?
If not please set status_beta to wontfix.

For more information, please visit auto_nag documentation.

Flags: needinfo?(kershaw)

I think we can let it ride the train. Thanks.

Flags: needinfo?(kershaw)
Flags: qe-verify+

I was able to reproduce this bug by using the steps from comment 0, on an affected Nightly build (2021-08-14).

The issue is verified as fixed on latest Beta 93.0b7, across platforms: Win 10 x64, macOS 11 and Ubuntu 18.04 x64.

Status: RESOLVED → VERIFIED
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.