Firefox redirects to wrong domains on its own
Categories
(Core :: Networking, defect)
Tracking
()
People
(Reporter: bugzilla, Unassigned)
Details
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:83.0) Gecko/20100101 Firefox/83.0
Steps to reproduce:
- Open https://staging.katmai.app
- Use the application (you can't do this without an account but loading the start page might be enough)
- Open https://katmai.app
Actual results:
Firefox, with cache cleared and disabled through F12 tools network view, claims that the server had responded with a 301 moved permanently message redirecting to staging.katmai.app, which cannot be true and does not occur in other browsers or other computers. It's just my Firefox instance that does it most of the time (not always).
Expected results:
The entered URL should be opened, as requested by the user. Wrong claims about made up server responses should not be made.
|
||
Comment 1•4 years ago
|
||
Bugbug thinks this bug should belong to this component, but please revert this change in case of error.
|
||
Comment 2•4 years ago
|
||
I'm suspecting bug 1420777.
Could you gather some HTTP logs to confirm the cause of the issue?
https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/HTTP_logging
Thanks!
|
Reporter | |
Comment 3•4 years ago
|
||
That HTTP2 thing sounds plausible. And if it's really that dangerous, I'm not interested in keeping it. How would I disable that connecting thing in Apache while keeping HTTP2 enabled? I haven't found any info about that.
I have collected the log as described, it should contain the reproduced bug. The file has 13 MB and looks like it contains all details including confidential auth cookies. Can I remove those before uploading the file or can I just look for something specific in that file myself?
|
|
Reporter | |
Comment 4•4 years ago
|
||
PS: The URL mentioned is hosted on my own web server, among dozens of others. They're spread across two servers, each has only a single IPv4 address for all their domains. Every domain has their own IPv6 address though. But that overlap would be in IPv4. Interestingly, I can reproduce this bug on my IPv6-connected machine, but have been reported it doesn't happen on an IPv4-only network.
Anyway, since Firefox has decided to enable that aggressive optimisation, and Chrome seems to use a less aggressive, yet still unsafe variant, I can only fix this on the server side for all users.
Some of the domains use a proxy backend to serve apps external to Apache (ASP.NET or other local app servers). I guess that reverse proxy cannot tell apart multiple Host: headers because each needs a different connection to their backend. So that connection sharing is just useless and broken in this scenario. It must be disabled.
|
|
||
Comment 5•4 years ago
|
||
HTTP2 connection coalescing happens when there's both a certificate and IP overlap.
If you can use different certificate for each of the domains, it should work.
Or you could return code 421 for a mismatch, and Firefox will retry with a new connection.
Note: we might change the coalescing algorithm soon to be more compatible with the other browsers, but we do not have an ETA for this.
|
|
Reporter | |
Comment 6•4 years ago
|
||
Sorry, but the same certificate does not imply the same site! How could anybody come to that belief? I use a wildcard certificate for easier management, but the domains still serve totally unrelated content. I'm starting to believe that either the http2 standard or Firefox have a critical bug here. I need to think about disabling http2 again for its unreliability. At least for https. But no browser wants to use http2 over http (not encrypted) anyway.
|
|
||
Comment 7•4 years ago
|
||
Since the certificate asserts that the server is authoritative for both domains, and there is an IP overlap, that means that connection reuse is certainly possible.
Description
•