GNOME Bugzilla – Bug 769940
Portal helper should load a URI that doesn't redirect to a secure page
Last modified: 2016-12-03 03:50:13 UTC
I suspect our http://www.gnome.org/ -> https://www.gnome.org/ redirection is causing problems with our portal helper. We should load some other page that doesn't redirect to a secure URI. It should be some page set up for this purpose, bug #750941.
I seem to have come across a portal that redirects to a HTTPS portal with a "bad" certificate, even though the connectivity check starts with Fedora's http URL: https://bugzilla.redhat.com/show_bug.cgi?id=1362449
FYI, a few people were having problems with the portal-helper at Flock and GUADEC. The WebKitWebView would fail to offer the portal authentication page with: (a) "Peer failed to perform TLS handshake", or (b) "unacceptable TLS certificate" Michael and I hacked up gnome-shell-3.20.3 to add some extra debug information to find out what is happening. I will shortly attach the patch and the logs, so that they don't sit all alone on my laptop.
Created attachment 336527 [details] [review] Patch to debug load-changed and load-failed-with-tls-errors from WebKitWebView
Created attachment 336528 [details] Debug logs from debug load-changed and load-failed-with-tls-errors I got these via e-mail. I am surprised that there is no load-failed-with-tls-errors, so it makes me think that they are probably incomplete.
(In reply to Debarshi Ray from comment #2) > FYI, a few people were having problems with the portal-helper at Flock and > GUADEC. The WebKitWebView would fail to offer the portal authentication page > with: > (a) "Peer failed to perform TLS handshake", or > (b) "unacceptable TLS certificate" I am sitting at an airport with a captive portal and getting this error. When the portal-helper shows the WebKitWebView with one of the above error messages, if I run a simple program that just calls webkit_web_view_load_uri with http://www.gnome.org/ then it does loads the portal successfully. I wonder if it is only the first attempt that fails, but that will need some more digging because I am not fast enough to invoke a.out before the portal-helper kicks in.
(In reply to Debarshi Ray from comment #5) > I wonder if it is only the first attempt that fails, but that will need some > more digging because I am not fast enough to invoke a.out before the > portal-helper kicks in. If I nuke gnome-shell-portal helper by chmoding it to 644 (somehow pointing the D-Bus service file to invoke a different binary didn't work), and manually run a.out after it connects to the network, I can reproduce the failure. Merely running it a second time doesn't make it go away either, which makes me curious why it was working earlier when run after the portal helper kicked in. Strange. If I point webkit_web_view_load_uri to http://nmcheck.gnome.org/, then it does load the portal, but trying to load http://www.gnome.org/ after that fails again. I'll have to board my flight in another 10 minutes, so I don't have much time to debug this right now. Maybe we should just point it to http://nmcheck.gnome.org/? It was created for similar purposes (for NM's connectivity check), after all.
Created attachment 338342 [details] [review] portalHelper: Address intermittent TLS failures Completely untested.
Really should use a constant instead of open-coding it in three different places, though
Created attachment 338357 [details] [review] portalHelper: Use a constant for the host name and URI Again, untested.
Comment on attachment 338342 [details] [review] portalHelper: Address intermittent TLS failures Pushed to master, gnome-3-22 and gnome-3-20.
Comment on attachment 338357 [details] [review] portalHelper: Use a constant for the host name and URI Pushed to master.
I tested these out at a Starbacks outlet. Sadly, I failed to reproduce the original error this time, so I can't tell whether this actually fixed anything or not. It was failing all the time at the airport, but it wasn't failing at Flock before that. Anyway, these patches don't seem to have caused a regression. At least not on this network.
(In reply to dimitris from comment #1) > I seem to have come across a portal that redirects to a HTTPS portal with a > "bad" certificate, even though the connectivity check starts with Fedora's > http URL: > > https://bugzilla.redhat.com/show_bug.cgi?id=1362449 By the way, this won't fix that portal. I don't think we need to support portals that use invalid certificates on their capture pages, since such portals are surely broken with all browsers and operating systems.