Due the nature of the captive portal detection mechanism, http://detectportal.firefox.com/ has to be accessible over plain HTTP.
This is bad, since firefox.com is a critical domain that should fully support HSTS. There might be further issues when it comes to implementing HPKP, DNSSEC, TLSA or any future security feature for firefox.com.

I assume Google has the same issue with their https://clients3.google.com/generate_204, but at least their mechanism is also accessible over HTTPS.

A hardcoded HSTS blacklist for detectportal.firefox.com would be a bad option.
Could the mechanism be changed completely or could this be moved to another domain?

Accessing https://detectportal.firefox.com/success.txt from a captive portal would be not successful (as expected), but are there any false positives or breakage when using HTTPS?

Nihanth, this is more of a back-end captive portal issue (i.e. move the CP test site to another domain) and probably more of a backlog item. Can we move it out of Firefox::Security to the place where captive portal detection bugs are stored?

Thanks!

I feel like this is already tracked somewhere so we might be able to dupe it. I could be wrong though - in any case, punting to Core :: Networking for further triage.

I am putting this as P3. If the project that needs this to be fixed continues we should change priority and work on this. There is no reason o work on this at this point.