https_first wrongly downgrade to http (after 302 & 401)
Categories
(Core :: DOM: Security, defect, P2)
Tracking
()
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';
}
Maybe related ticket : https://bugzilla.mozilla.org/show_bug.cgi?id=1885949
Comment 2•4 months ago
|
||
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.
Updated•4 months ago
|
Updated•4 months ago
|
Comment 3•4 months ago
|
||
(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?
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.
Assignee | ||
Comment 5•4 months ago
|
||
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?
Assignee | ||
Updated•4 months ago
|
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•4 months ago
|
||
Thanks. Given that verification, I'm going to dup this against bug 1747230
Hum, sorry wrong test on Nightly.
Pb still there on firefox-129.0a1
Comment 9•4 months ago
|
||
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?)
Assignee | ||
Comment 10•4 months ago
|
||
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•4 months ago
|
||
From the added tests only the http redirect test cases start passing
with this patch. META and JS redirect already pass before this patch.
Updated•4 months ago
|
Comment 12•4 months ago
|
||
Was curious and investigated further. Submitted patch.
Updated•4 months ago
|
Updated•3 months ago
|
Updated•2 months ago
|
Comment 13•2 months ago
|
||
Comment 14•2 months ago
|
||
Backed out for causing mochitest failures on test_multiple_redirection.html
Assignee | ||
Updated•1 month ago
|
Assignee | ||
Updated•12 days ago
|
Assignee | ||
Comment 15•2 days ago
|
||
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.
Updated•2 days ago
|
Description
•