Open Bug 1904238 Opened 4 months ago Updated 2 days ago

https_first wrongly downgrade to http (after 302 & 401)

Categories

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

Firefox 127
defect

Tracking

()

REOPENED

People

(Reporter: pascal, Assigned: maltejur)

References

(Blocks 3 open bugs)

Details

(Whiteboard: [domsecurity-active])

Attachments

(2 files)

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

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';
}

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.

Component: Untriaged → Networking: HTTP
Product: Firefox → Core
Severity: -- → S3
Priority: -- → P2
Whiteboard: [necko-triaged][necko-priority-new]
Component: Networking: HTTP → DOM: Security
Whiteboard: [necko-triaged][necko-priority-new]

(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?

Flags: needinfo?(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.

Flags: needinfo?(pascal)

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?

Flags: needinfo?(pascal)

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

Flags: needinfo?(pascal)

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

Status: UNCONFIRMED → RESOLVED
Closed: 4 months ago
Duplicate of bug: 1747230
Resolution: --- → DUPLICATE

Hum, sorry wrong test on Nightly.

Pb still there on firefox-129.0a1

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?)

Status: RESOLVED → REOPENED
No longer duplicate of bug: 1747230
Ever confirmed: true
Resolution: DUPLICATE → ---
See Also: → 1747230

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.

Flags: needinfo?(manuel)

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

Assignee: nobody → manuel

Was curious and investigated further. Submitted patch.

Assignee: manuel → nobody
Flags: needinfo?(manuel)
Assignee: nobody → manuel
Whiteboard: [domsecurity-active]
Attachment #9410157 - Attachment description: Bug 1904238 - Don't copy over https-first flags on http redirects r=maltejur → Bug 1904238 - Don't copy over https-first and -only flags on http redirects r=maltejur
Pushed by mbucher@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/14fcacb96097 Don't copy over https-first and -only flags on http redirects r=maltejur
Blocks: 1915176

Backed out for causing mochitest failures on test_multiple_redirection.html

Backout link

Push with failures

Failure log

Flags: needinfo?(manuel)
Assignee: manuel → maltejur
Flags: needinfo?(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.

Attachment #9410157 - Attachment description: Bug 1904238 - Don't copy over https-first and -only flags on http redirects r=maltejur → Bug 1904238 - Don't copy over https-first and -only flags on http redirects r?manuel!,freddyb!
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: