Firefox spins when detectportal is redirected to https
Categories
(Core :: Networking, defect, P1)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox69 | --- | fixed |
People
(Reporter: phy1729, Assigned: valentin)
References
Details
(Whiteboard: [necko-triaged])
Attachments
(1 file)
User Agent: Mozilla/5.0 (X11; OpenBSD amd64; rv:68.0) Gecko/20100101 Firefox/68.0
Steps to reproduce:
Configure the gateway to intercept all tcp/80 connections and issue a 307 redirect to the corresponding https URL.
Wait until Firefox fetches detectportal.firefox.com/success.txt .
Actual results:
Firefox will consume a CPU core while it continuously retries to fetch the detectportal endpoint.
Expected results:
The success file could be served over https as well or Firefox could interpret a 307 redirect to the same URL as a lack of a captive portal (or as a captive portal). In the case of treating the redirect as a captive portal, the network operator can spoof the success page (which also serves as a workaround for now).
|
||
Updated•5 years ago
|
|
Assignee | |
Comment 2•5 years ago
|
||
Thank you for the report. This seems rather serious.
I initially thought it would be related to bug 1553927, since it is HTTPS related.
However, here the problem was with the CaptivePortal checker. XHR requests don't get the status for the redirect, and they always try to follow redirects. So it took the cert error as a regular failure, so it kept retrying forever, never seeing the redirect.
|
|
Assignee | |
Comment 3•5 years ago
|
||
The problem with CaptiveDetect was that it uses an XMLHttpRequest, and
apparently xhr.status is 0 for failed requests, which here includes cert
errors, redirect loops, etc.
Getting the XHR to not follow redirects was tricky, so a hacky fix was to
set nsIHttpChannel.redirectionLimit = 0;
For any redirect the XHR would now fail with NS_ERROR_REDIRECT_LOOP, which
we need to handle separately.
I also included tests for:
- redirect to https with invalid cert
- redirect to same URL causing redirect loop
- redirect to different URL with different content
- redirect to different URL with canonical content
All of these cases should be detected as locked captive portals.
Pushed by valentin.gosu@gmail.com: https://hg.mozilla.org/integration/autoland/rev/82c47ed9b5b8 Make sure CaptiveDetect.jsm interprets any redirect as a locked captive portal r=mayhemer
|
||
Comment 5•5 years ago
|
||
| bugherder | ||
Description
•