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

Status: VERIFIED FIXED

(Core :: Networking, defect, P1)

Description

[Fanolian]

Attachment: hkepc https redirect.png

+++ 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.

Comment 1

[Kershaw Chang [:kershaw]]

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.

Comment 2

[Kershaw Chang [:kershaw]]

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.

Comment 3

[Kershaw Chang [:kershaw]]

Attachment: Bug 1725800 - Also check if the uri path is the same when doing upgrade and downgrade loop check, r=ckerschb

Comment 4

[Pulsebot]

Pushed by [e-mail]:
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

Comment 5

[Narcis Beleuzu [:NarcisB]]

https://hg.mozilla.org/mozilla-central/rev/033420d6bd56

Comment 6

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

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.

Comment 7

[Kershaw Chang [:kershaw]]

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

Comment 8

[Ciprian Georgiu, Desktop QA]

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.