1747535 - Captive portal redirect not working due to forced https in detection site url

Status: UNCONFIRMED

(Core :: Networking, defect, P2)

Description

[business]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:95.0) Gecko/20100101 Firefox/95.0

Steps to reproduce:

Click on the log in required for network notification in Windows

Actual results:

Firefox opened, but instead of using http it tried to access msftconnecttest using https -> https://www.msftconnecttest.com/redirect

Expected results:

Access http://www.msftconnecttest.com/redirect

This also happens with FIrefox's own portal detection site.

Ideally Firefox should contain a list of those captive portal detection URLs and ensure they NEVER use https and force them to use http instead.

Comment 1

[Kershaw Chang [:kershaw]]

I'd like to know why captive portal request got upgraded. Could you try to get a http log? Thanks.
Note that captive portal request happens at startup, so you might want to get the log by setting environment variables.

Comment 2

[business]

Attachment: log.txt-main.12124.moz_log.zip

Here is the log.

I reproduced it as follows:

• closed Firefox
• opened Firedfox
• went to about:networking
• activated logging
• connecting the Wifi network with captive portal
• waited
• did a DuckDuckGo search in new tab in force network login bar to display
• when firefox offered the information bar with link to log in to network I clicked on it

Result:

• new tab open with https://www.msftconnecttest.com/redirect
• other new tab open with https://detectportal.firefox.com/canonical.html

Comment 3

[business]

The only way I could connect to the network in the end, was by using Edge where the captive portal detection worked flawlessly.

Comment 4

[Kershaw Chang [:kershaw]]

Thanks for the log. I can see that the request to http://detectportal.firefox.com/canonical.html is upgraded, but the reason is not clear.
Are you able to reproduce this with a clean profile?

Comment 5

[business]

Unfortunately not in the near future. I also managed to do this yesterday as I was on a train with a captive portal wifi. It will probably be a while before I am in such an environment again.

Comment 6

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

I think all the canonical.html requests in the log fail with 804b001f (REDIRECT_LOOP). Which triggers the captive portal. I don't see any upgrades to HTTPS.
The upgrade for www.msftconnecttest.com/redirect seems unrelated, and seems to be caused by HTTPS-first/only mode.

I'm not sure this is a real bug. Opening the CP URLs directly doesn't make them excluded from HTTPS first mode. But the background request that happens is excluded
Please reopen if you disagree. Thanks!

Comment 7

[business]

Please read what I wrote:

Firefox opened, but instead of using http it tried to access msftconnecttest using https

The request that was triggered by the Windows UI clearly didn't get excluded!

Comment 8

[b paulson]

I just had a bug appear, and I think it is this bug. Our workplace has a captive portal (served by http) which unregistered users are redirected to when they visit an unsecured ("http") page. After registration, the MAC address of the device is stored for 6 months. In the unregistered state, rather than showing a captive portal, Firefox 97.0.1 (on Linux) shows the "captive portal bar" ("You must log in to this network before you access the internet") with a single button. Clicking that button brings the browser to "https://detectportal.firefox.com/..." which cannot be captured by the portal because it is loading as https!

I thought the issue might be caused by my extensions, but Https Everywhere was turned off on Sunday, and I've restarted Firefox twice since then.

Comment 9

[b paulson]

It seems this is a bug is caused by an interaction with url autofill. Disabling browser.urlbar.autoFill in about:config allows detectportal.firefox.com to load as http when the button is pressed, and the portal login page loads as expected. I will remain logged out of the portal for 24 hours so that I can provide any debugging information you request (but this requires me to use mobile data, so I can't wait forever).

Could you tag the owners of the captive portal and url autofill features?

Should I file this again as a bug for Firefox 97?

Comment 11

[b paulson]

This bug appears to have been resolved.

Version:
Mozilla Firefox for Linux Mint
mint-001 - 1.0
101.0 (64 bit)

After refreshing the (timed-out) wifi connection,
the captive portal was accessed automatically in a new profile with browser.url.autofill set to "true," as well as plugins.http_https_only set to "true" and dom.security.https_only_mode set to "false".

Having done more searching, this may be a duplicate of [Bug 1746069] or [Bug 1730920] or [Bug 1743405].

Comment 12

[goatwildernesscollective]

i have the same bug in Firefox FSR mobile Linix PureOS 10, Debian base on mobile arm64. Captive portal detection and redirect fails.

Comment 13

[Dragana Damjanovic [:dragana]]

(In reply to b paulson from comment #9)

It seems this is a bug is caused by an interaction with url autofill. Disabling browser.urlbar.autoFill in about:config allows detectportal.firefox.com to load as http when the button is pressed, and the portal login page loads as expected. I will remain logged out of the portal for 24 hours so that I can provide any debugging information you request (but this requires me to use mobile data, so I can't wait forever).

Could you tag the owners of the captive portal and url autofill features?

Should I file this again as a bug for Firefox 97?

The bug is already marked blocking the captive portal and other relevant features, the owners are aware.

Comment 14

[haseeb]

(In reply to business from comment #0)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:95.0) Gecko/20100101 Firefox/95.0

Steps to reproduce:

Click on the log in required for network notification in Windows

Actual results:

Firefox opened, but instead of using http it tried to access msftconnecttest using https -> https://www.msftconnecttest.com/redirect

Expected results:

Access http://www.msftconnecttest.com/redirect

This also happens with FIrefox's own portal detection site.

Ideally Firefox should contain a list of those captive portal detection URLs and ensure they NEVER use https and force them to use http instead.

Browsers use captive portal detection mechanisms to determine if the network they are connected to requires authentication through a captive portal before allowing full internet access. This is often seen in public Wi-Fi networks, where you need to log in before you can access the internet.
Captive portal detection URLs are typically designed to be accessed over HTTP. However, in some cases, browsers might attempt to access these URLs over HTTPS due to various reasons, such as security concerns or browser behavior. You can Use browser developer tools to inspect network requests and redirects or use this tool https://redirectchecker.com This can help you identify detail report of your URL redirection.

Comment 15

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee is inactive on Bugzilla, so the assignee is being reset.