On Sun, 2016-12-04 at 16:39 -0500, Paul Wouters wrote: > That is a different issue. And indeed I see it as well, and was quite > surprised at them checking the TLS validity of a captive portal page. We have no plans to stop doing this, because that's how all other browsers and operating systems work. It shouldn't be any problem because such portals would not work for anyone on any system. In particular, note that some portals require a username/password that would be unsafe to submit unless there is TLS certificate verification, so we really need to either (a) display the login page as affirmatively insecure (we don't currently) if it redirects to http:// or just replaces the contents of an http:// page without any redirect, or (b) block it like any other browser if it redirects to https:// and doesn't have a valid TLS certificate for its URI (such a portal would be hopelessly broken for everyone else too). But in this specific case with the gnome-shell portal helper, there seems to have been a problem because we tried to load an https:// URI rather than an http:// one, which isn't going to work under a captive portal as the portal can't replace the page. I really do not completely understand what the actual bug here was, and nobody seems to have figured it out, but it seems that for whatever unknown reason some captive portals decide not to intercept our load of http://www.gnome.or g. That URI recently became a redirect to https://www.gnome.org, so the portal helper performs the redirect and then the portal does intercept the load of https://www.gnome.org, and that's why you get a TLS error. It's really weird; I don't know why the portal would do that. Moreover the issue affected some users, but not others, with the exact same captive portal, using the exact same version of Fedora; we had this issue at GUADEC. Maybe the redirect is cached by WebKit on certain systems so it only works if you haven't visited http://www.gnome.org before in the portal helper...? Anyway, we have "fixed" this by changing it to load http://nmcheck.gnome.org which never redirects to HTTPS. I haven't heard any complaints about this since then, so I think it's good, but the change is in gnome-shell-3.22.2-2.fc25 which is very recent so let's wait and see. > I have that on top of the bug where it just shows me the gnome page > instead of the actual captive portal page. This really requires a separate bug report against gnome-shell. Probably a race condition somewhere, maybe the last redirect and NetworkManager connectivity check occurs just before we get connectivity back. Unfortunately this is an undermaintained component that is not very likely to be fixed without a volunteer. Michael _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
