Bug 2443627

Summary:	Network check site should use HTTP rather than HTTPS.
Product:	[Fedora] Fedora	Reporter:	realkpavel
Component:	NetworkManager	Assignee:	Lubomir Rintel <lkundrak>
Status:	NEW ---	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	43	CC:	bgalvani, ffmancera, ihuguet, jvaclav, lkundrak, mclasen, opensource, rstrode, vbenes
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	---
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:		Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description realkpavel 2026-03-01 09:17:29 UTC

Description of problem:
The Fedora network check page (http://fedoraproject.org/static/hotspot.txt) defaults to HTTPS in a browser (tested on Firefox and Vivaldi). This prevents captive portals from working properly.

Steps to Reproduce:
1. On a Fedora KDE system, connect to a wifi network with a configured captive portal (for example on a bus, train or fast food restaurant).
2. A popup shows up, saying that the network needs you to log in. Clicking a button opens the fedora network check page in the browser.

Actual results:
The network check page tries and fails to load. The browser displays a connection error.

Expected results:
The captive portal should intercept the connection and show the login screen instead of the Fedora network check site.

3. Open a new tab and navigate to http://httpforever.com
4. The captive portal login screen shows up as expected.

Additional info:
From my testing with various captive portals, the interception logic assumes a HTTP (not HTTPS) connection. I have only encountered one captive portal that worked with the current HTTPS implementation. In a way this is by design for HTTPS - the captive portal is in essence performing a man in the middle attack on your website. However, the site does not transfer any security sensitive info (it just shows an "OK" message), so I think letting the site intercept as designed would be preferrable.