Bug 1252839 - NetworkManager captive portal detection uses https, which breaks the authentication popup
Summary: NetworkManager captive portal detection uses https, which breaks the authenti...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: NetworkManager
Version: 22
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Lubomir Rintel
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-08-12 10:30 UTC by Elad Alfassa
Modified: 2016-08-19 16:00 UTC (History)
7 users (show)

Fixed In Version: NetworkManager-1.0.6-0.2.20150813git7e2caa2.fc22
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-10-29 13:56:47 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Elad Alfassa 2015-08-12 10:30:23 UTC
/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.

Comment 1 Elad Alfassa 2015-08-14 13:48:12 UTC
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.

Comment 2 Fedora Admin XMLRPC Client 2015-08-18 15:00:31 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 3 Michael Catanzaro 2015-10-28 23:06:14 UTC
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.

Comment 4 Fedora Blocker Bugs Application 2015-10-28 23:06:47 UTC
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.

Comment 5 Michael Catanzaro 2015-10-28 23:07:57 UTC
(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. ;)

Comment 6 Lubomir Rintel 2015-10-29 10:45:42 UTC
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.

Comment 7 Elad Alfassa 2015-10-29 11:16:11 UTC
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.

Comment 8 Lubomir Rintel 2015-10-29 13:17:25 UTC
(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.

Comment 9 Elad Alfassa 2015-10-29 13:24:26 UTC
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.

Comment 10 Thomas Haller 2015-10-29 13:56:47 UTC
I think this is already fixed by 1:1.0.6-0.2.20150813git7e2caa2 or newer.


Just forgot to close the BZ.

Comment 11 Dimitris 2016-08-18 01:22:50 UTC
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.

Comment 12 Thomas Haller 2016-08-18 15:48:02 UTC
(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.

Comment 13 Dimitris 2016-08-18 15:54:40 UTC
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?

Comment 14 Thomas Haller 2016-08-18 21:04:15 UTC
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.

Comment 15 Michael Catanzaro 2016-08-19 15:55:58 UTC
(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

Comment 16 Dimitris 2016-08-19 16:00:07 UTC
See bug 1362449 on gnome-shell, with more details.


Note You need to log in before you can comment on or make changes to this bug.