1556259 - Firefox spins when detectportal is redirected to https

Status: RESOLVED FIXED

(Core :: Networking, defect, P1)

Description

[phy1729]

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

Comment 1

[Kershaw Chang [:kershaw]]

Valentin, could you take a look at this?

Comment 2

[Valentin Gosu [:valentin] (he/him)]

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.

Comment 3

[Valentin Gosu [:valentin] (he/him)]

Attachment: Bug 1556259 - Make sure CaptiveDetect.jsm interprets any redirect as a locked captive portal r=mayhemer

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.

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/82c47ed9b5b8
Make sure CaptiveDetect.jsm interprets any redirect as a locked captive portal r=mayhemer

Comment 5

[Daniel Varga [:dvarga]]

https://hg.mozilla.org/mozilla-central/rev/82c47ed9b5b8