1904238 - https_first wrongly downgrade to http (after 302 & 401)

Status: RESOLVED FIXED

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

Description

[pascal]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:127.0) Gecko/20100101 Firefox/127.0

Steps to reproduce:

http://a redirects to https://a
https://a redirects to https://b
https://b respond html with HTTP 401 and header "WWW-Authenticate: Negotiate"

Access http://a with dom.security.https_first
or access http://a with dom.security.https_first_pbm in private window

Actual results:

firefox will

• follow redirects
• ignore the result of https://b request
• go to http://b

Expected results:

firefox should not downgrade to http after redirect.
Or at least not downgrade to http after redirect on another host.

Workaround if site "b" is https only : enforce Strict-Transport-Security header on https://b responses.

NB : HTTP 401 is not the only error code which will cause the downgrade to http. 404 and 503 will do it too.

Simple PHP test case :

if (isset($_GET["redirect_https"])) {
header('Location: https://xxx/foo.php?redirect');
} else if (isset($_GET["redirect"])) {
header('Location: foo.php');
} else {
header('HTTP/1.0 503"');
echo 'error';
}

Comment 1

[pascal]

Maybe related ticket : https://bugzilla.mozilla.org/show_bug.cgi?id=1885949

Comment 2

[BugBot [:suhaib / :marco]]

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

Comment 3

[Daniel Veditz [:dveditz]]

(In reply to pascal from comment #1)

Maybe related ticket : https://bugzilla.mozilla.org/show_bug.cgi?id=1885949

That bug was fixed in 127, and you filed this against Firefox 127. Are you just noting the similarity? Or is this a new problem for you and didn't happen in Firefox 126?

Comment 4

[pascal]

Sorry it was not clear: I was just noting the similarity.

The pb is present since at least Firefox 91.9ESR . It was of course not present in 52.9ESR. It is present in 115ESR.

Comment 5

[Malte Jürgens [:maltejur]]

Due to your testcases using query parameters, and your test description, to me this looks very much like a variation of Bug 1747230, for which a fix landed recently in Nightly. Can you check if this is still happening in the latest Firefox Nightly?

Comment 6

[pascal]

I could not reproduce the issue in Nightly : it seems there is no more downgrade to http in case of HTTP 4xx/5xx.

Comment 7

[Randell Jesup [:jesup] (needinfo me)]

Thanks. Given that verification, I'm going to dup this against bug 1747230

Comment 8

[pascal]

Hum, sorry wrong test on Nightly.

Pb still there on firefox-129.0a1

Comment 9

[Manuel Bucher [:manuel] {{ FYI: OOO Jul 30 - Aug 16 }}]

Reopening due to problem still occurring for reporter.

From the problem description, we seem to downgrade too many requests in https://searchfox.org/mozilla-central/rev/2f48061aef8c8976b73749ee845e7b85751f5f2f/dom/security/nsHTTPSOnlyUtils.cpp#461,491-495 (also requests that didn't got upgraded via https-first?)

Comment 10

[Malte Jürgens [:maltejur]]

I can reproduce this in Nightly 129.0a1 (2024-06-24). I have set up your PHP example here:

http://php.httpsonly.polar.onl/foo.php?redirect_https

Visiting that the first time lands me on http://php.httpsonly.polar.onl/foo.php. Due to us then exempting that host from HTTPS-First, subsequent loads behave as expected. This is the log I am getting:

HTTPS-First Mode: Upgrading insecure request “http://php.httpsonly.polar.onl/foo.php?redirect_https” to use “https”.
HTTPS-First Mode: Upgrading insecure request “https://php.httpsonly.polar.onl/foo.php” failed. Downgrading to “http” again.
HTTPS-First Mode: Website does not appear to support HTTPS. Further attempts to load “http://php.httpsonly.polar.onl” securely will be skipped temporarily.

So we indeed seem to downgrade a different url than we upgraded. Manuel, due to your recent work on the loop detection, do you want to look further into this? If not, I'd also be happy to investigate further.

Comment 11

[Manuel Bucher [:manuel] {{ FYI: OOO Jul 30 - Aug 16 }}]

Attachment: Bug 1904238 - Don't copy over https-first and -only flags on http redirects r?manuel!,freddyb!

From the added tests only the http redirect test cases start passing
with this patch. META and JS redirect already pass before this patch.

Comment 12

[Manuel Bucher [:manuel] {{ FYI: OOO Jul 30 - Aug 16 }}]

Was curious and investigated further. Submitted patch.

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/14fcacb96097
Don't copy over https-first and -only flags on http redirects r=maltejur

Comment 14

[Norisz Fay [:noriszfay]]

Backed out for causing mochitest failures on test_multiple_redirection.html

Backout link

Push with failures

Failure log

Comment 15

[Malte Jürgens [:maltejur]]

Attachment: Bug 1904238 - Fix bad URL in file_multiple_redirection.sjs r?manuel!

I am not sure what the original idea was here, but REDIRECT_DOWNGRADE_URI_HTTP
seems to be unused, while the places where REDIRECT_DOWNGRADE_URI is used really
seem to need REDIRECT_DOWNGRADE_URI_HTTP. Strangely, this didn't actually cause
problems in this test until the fixes from Bug 1904238 are included.

Comment 16

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/a21b67c460b4
Fix bad URL in file_multiple_redirection.sjs r=manuel
https://hg.mozilla.org/integration/autoland/rev/e6d0a3055805
Don't copy over https-first and -only flags on http redirects r=manuel,freddyb

Comment 17

[Cristina Horotan [:chorotan]]

https://hg.mozilla.org/mozilla-central/rev/a21b67c460b4
https://hg.mozilla.org/mozilla-central/rev/e6d0a3055805