/etc/NetworkManager/conf.d/20-connectivity-fedora.conf has an https url. Having it as https breaks the captive portal authentication dialog popup somehow, I guess whatever components which try to detect the captive portal won't connect anywhere (because the certificate is wrong), so the dialog never pops up. Changing the URL back to http:// fixes this issue.
This is the change that broke it: http://pkgs.fedoraproject.org/cgit/NetworkManager.git/commit/?id=8890459ab6419144c42bd1d8ca302eae0f88e026 (bug #1135777). HTTPS might make sense to hide the fact that it is hotspot checking that is being done, but without actually loading a page to detect a redirect, it would just seem to be "no connectivity" and not "captive portal". Skipping the certificate validation would nullify the benefit we get from using HTTPS.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
For F23, we should get a freeze exception to quickly revert this change. For F24, the captive portal helper can connect to WebKitWebView::load-failed-with-tls-errors and there call webkit_web_context_allow_tls_certificate_for_host() to allow the load. This should be easy, but it should be coupled with added UI to show that the page is insecure. I will try to get to this in the F24-timeframe. It's GNOME #749197.
Proposed as a Freeze Exception for 23-final by Fedora user catanzaro using the blocker tracking app because: We'd like to fix captive portal detection, obviously.
(In reply to Michael Catanzaro from comment #3) > For F24, the captive portal helper can connect to > WebKitWebView::load-failed-with-tls-errors and there call > webkit_web_context_allow_tls_certificate_for_host() to allow the load. This > should be easy, but it should be coupled with added UI to show that the page > is insecure. I will try to get to this in the F24-timeframe. It's GNOME > #749197. Sorry, please completely ignore this comment; I was thinking wrong component. ;)
I'm not sure how is the URL NetworkManager uses related to this. I believe it's not exposed on the bus at all. Also a quick peek at org.gnome.Shell.PortalHelper and the way js/ui/status/network.js uses it suggests that it always uses http://www.gnome.org unless I'm reading it wrong.
The fix is simple. Just revert that commit. Using HTTPS here has no benefit at all if we have to ignore the certificate anyway. What Michael said about Webkit is not related at all, as he said, you need to ignore that comment, he was thinking about the shell portal helper and not the NetworkManager captive portal detection.
(In reply to Elad Alfassa from comment #7) > The fix is simple. Just revert that commit. Using HTTPS here has no benefit > at all if we have to ignore the certificate anyway. > > What Michael said about Webkit is not related at all, as he said, you need > to ignore that comment, he was thinking about the shell portal helper and > not the NetworkManager captive portal detection. Would you mind explaining how is that going to fix the issue? It seems totally unrelated. Otherwise please restore the needinfo flag you've cancelled. Thanks.
Please read my original comment again. This commit I referred to broke the captive portal detection functionality. The reason is simple: NetworkManager fetches the webpage in this address, and if it gets a redirect instead of the expected response, it decides it's a captive portal. When the URL is https and not http, NetworkManager will not follow the redirect because the underlying library it uses to fetch the webpage verifies the certificate, and sees that it's invalid (in a captive portal case it will *always* be invalid) and thus refuses to connect. NetworkManager parses this as a connection error, and marks the connection as having no internet connectivity. Reverting this commit fixes the issue. I've tested this multiple times with multiple captive portal networks.
I think this is already fixed by 1:1.0.6-0.2.20150813git7e2caa2 or newer. Just forgot to close the BZ.
Just got bit by this under F24 (hotel in San Diego, CA, US FWIW). It doesn't happen consistently, but it *is* sticky, i.e. once it starts happening it continues for a while. I don't have a clear pattern on what "triggers" it yet, sorry.
(In reply to Dimitris from comment #11) > Just got bit by this under F24 (hotel in San Diego, CA, US FWIW). It > doesn't happen consistently, but it *is* sticky, i.e. once it starts > happening it continues for a while. > > I don't have a clear pattern on what "triggers" it yet, sorry. NM (NetworkManager-config-connectivity-fedora) does not use HTTPS for a long time. Especially not on F24. Whatever you are seeing or doing, it is not the issue discussed in this BZ.
The captive portal window (not my browser) comes up after I connect to the hotel wifi. It's all white, with just the unstyled text "Unacceptable TLS certificate" showing. I've also noticed that at that point, if I use my browser to go to an https page, I am *sometimes* - not always - shown the firefox "bad TLS certificate" warning. For example I may be pointing to https://duckduckgo.com and I get the warning that the certificate is for wayport.net (IIRC that's the captive portal provider). So it looks like a crappy captive portal issue at its root, essentially trying to do a MITM. I assume it may be doing the same for the Fedora HTTP, with a redirect to a page that has a bad certificate. It's not readily reproducible but happens a few times a day. I expect it to happen again today, I'll try to curl the fedora captive test URL and see if/where I'm redirected. Assuming this is what's going on, does the browser library used by the captive portal window support the option to ignore bad TLS certs?
Hi. NetworkManager is not the component that shows a "captive portal window". That is done (on Gnome3) by some gnome component (I think it's gnome-shell's "portal" component, not sure there). Also, when you open a HTTPS website in firefox, it would be expected that a captive portal either blocks the connection entirely or tries to MITM your https connection. That depends on your captive portal, but both behaviors are not helpful for you to login in the portal. You must try to open a HTTP site to login to a captive portal, HTTPS just doesn't fly. Similarly, the "captive portal window" should try to access a HTTP page. Anyway, this BZ really the wrong place to discuss this, sorry. Please open a BZ against the "captive portal window" component (gnome-shell?? I dunno). Good luck.
(In reply to Dimitris from comment #13) > The captive portal window (not my browser) comes up after I connect to the > hotel wifi. It's all white, with just the unstyled text "Unacceptable TLS > certificate" showing. This is indeed a gnome-shell bug and not a NetworkManager issue. I've already reported it, as a bunch of people were hitting it at GUADEC: https://bugzilla.gnome.org/show_bug.cgi?id=769940
See bug 1362449 on gnome-shell, with more details.