1707541 - Detectportal does not detect login page when login page is not served as https

Status: UNCONFIRMED

(Firefox :: General, defect)

Description

[djraymond1]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:88.0) Gecko/20100101 Firefox/88.0

Steps to reproduce:

1. Set firefox settings to serve HTTPS as priority, or set HTTPS only mode.
2. Connect to a network that needs to be logged in. The network you connect will only serve a captive portal with HTTP, and for HTTPS connection, you could access to the internet without any problem.
   (example network working like this: Starbucks Korea)
3. Firefox will prompt "You need to log in to use this network", click that.

Actual results:

It connects to https://detectportal.firefox.com/success.txt and shows success
But also, Firefox also still says "You need to log into network."

I have to connect to the site that does not serve HTTPS to actually log in to the network, and use some HTTP-only served websites.

Expected results:

detect portal should be served as HTTP only even on HTTPS only mode.

Comment 1

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

Aha, so the captive portal intercepts HTTP requests, but HTTPS requests are left alone?
So the problem is that the tab we open for the captive portal detection is upgraded to HTTPS, and of course that works.
We need to make sure the tab we open for captive portals doesn't get upgraded to HTTPS.

Comment 2

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

We need to set channel.loadInfo.httpsOnlyStatus |= Ci.nsILoadInfo.HTTPS_ONLY_EXEMPT; for the tab we open for captive portals similar to how we passed the disableTRR flag in bug 1608713.

Comment 3

[djraymond1]

(In reply to Valentin Gosu [:valentin] (he/him) from comment #1)

Aha, so the captive portal intercepts HTTP requests, but HTTPS requests are left alone?
So the problem is that the tab we open for the captive portal detection is upgraded to HTTPS, and of course that works.
We need to make sure the tab we open for captive portals doesn't get upgraded to HTTPS.

Yes, you're right. but because of security reasons, it might be great to check HTTPS first, and then check for HTTP. If HTTPS is possible, HTTPS connection might be great.

Comment 4

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

The captive portal request is meant to be intercepted. Doing it over HTTPS first then HTTP only prevents this scenario here, which is pretty rare.

Comment 5

[djraymond1]

Hmm... I was thinking this senario :
Access Captive Protal with HTTPS => if success without user doing anything => Access Captive Protal with HTTP automatically

Some captive portals have a connection to outside of the local network and asks for sensitive info, for this reason https might be tried first what I was thinking.

Comment 6

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

(In reply to djraymond1 from comment #5)

Hmm... I was thinking this senario :
Access Captive Protal with HTTPS => if success without user doing anything => Access Captive Protal with HTTP automatically

Some captive portals have a connection to outside of the local network and asks for sensitive info, for this reason https might be tried first what I was thinking.

If we still need to use HTTP when HTTPS succeeds then using HTTPS is not really necessary.

Comment 7

[djraymond1]

That also could be right.. hmm.. okay. Then using only HTTP will be enough.

Comment 8

[Andrei Purice]

Setting a component for this issue.
If you feel it's an incorrect one please feel free to change it to a more appropriate one.

Comment 9

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

I set Firefox::General based on the module for https://searchfox.org/mozilla-central/source/browser/base/content/browser-captivePortal.js (where the fix belongs)