Re: Fedora captive portal page changed output :(
On jueves, 8 de diciembre de 2016 12:22:30 PM CST Michael Catanzaro wrote: > On Thu, 2016-12-08 at 10:50 -0600, Dennis Gilmore wrote: > > android gives you a tls error and offers to go to the page ina > > browser where > > you can ignore the error manually. I think we should do the same as > > android > > > > Dennis > > What's the benefit of directing the user to a browser...? you do not have to be directed to a browser. the way android does it is if the certificates are deemed bad, for wheatever reason you get a warning that there is a security issue with the portal, and offered the choice to not connect or to continue anyway via a browser, where you then have to tell the browser to connect anyway and ignore the security issue. its then up to the user to choose to continue or not. you give them a path to do so but make them aware of the issue, ignoring the issue and blindly continuing on it will likely never be reported and fixed. Dennis signature.asc Description: This is a digitally signed message part. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora captive portal page changed output :(
On Thu, 2016-12-08 at 10:50 -0600, Dennis Gilmore wrote: > android gives you a tls error and offers to go to the page ina > browser where > you can ignore the error manually. I think we should do the same as > android > > Dennis What's the benefit of directing the user to a browser...? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora captive portal page changed output :(
On lunes, 5 de diciembre de 2016 8:31:41 AM CST Michael Catanzaro wrote: > On Mon, 2016-12-05 at 09:05 -0500, Paul Wouters wrote: > > That is incorrect in my experience. When I go to coffee shops, my > > iphone > > shows the portal page, but my laptop shows the TLS cert invalid > > thing. > > Oh wow. I didn't know that. Feels like time to give up android gives you a tls error and offers to go to the page ina browser where you can ignore the error manually. I think we should do the same as android Dennis signature.asc Description: This is a digitally signed message part. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora captive portal page changed output :(
On Mon, 2016-12-05 at 08:31 -0600, Michael Catanzaro wrote: > > Yes. That is why I specifically requested that the fedora hotspot > > page > > never chage their output and never send a redirect. Using the main > > page > > of gnome was a bad fit. Note you should also ensure that > > nmcheck.gnome.org > > has a cache lifetime of 0 seconds to it. > > Yeah, I actually filed a bug for this a while back: > > https://bugzilla.gnome.org/show_bug.cgi?id=750941 Fixed for nmcheck.gnome.org :) Michael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora captive portal page changed output :(
On Sun, 4 Dec 2016 19:44:22 -0500 (EST) Paul Wouterswrote: > On Sun, 4 Dec 2016, Kevin Fenzi wrote: > > > On Fri, 2 Dec 2016 21:42:07 -0600 > > Eric Sandeen wrote: > > > >> On 12/2/16 7:10 PM, Paul Wouters wrote: > >>> > >>> Fedora runs a captive portal check page at: > >>> > >>> http://fedoraproject.org/static/hotspot.txt > >>> > >>> It used to return "OK\n". > >>> > >>> Now it returns "OK" without the newline. > >> > >> Seems like the file date is still well in the past > >> (2015-12-15) and does not actually contain a newline; > >> webserver behavior change? > > > > Looking at archive.org, I do see the newline in: > > https://web.archive.org/web/20150616184630/https://fedoraproject.org/static/hotspot.txt > > but not in: > > https://web.archive.org/web/20160213221103/http://fedoraproject.org/static/hotspot.txt > > > > Indeed it seems the changes made on 2015-12-15 removed the > > newline. ;( > > > > Sorry about that. > > > > I can put it back since it seems like NetworkManager's portal > > detection doesn't care, or just leave it off now since it's been > > that way for around a year? > > I guess leave it as is. But it would be good if we can find out what > happened, and fix the process. Well, the longer description of things was: fedoraproject.org was/is created from the fedora-websites git repo. Over the years, much of it's moved to other places, ie, getfedora.org and the like. Last december, the websites team thought they could just stop building/syncing fedoraproject.org website. This was fine until we deployed a new proxy and it could not get any of the files for that site, including and importantly: hotspot.txt. So, we quickly setup a alias to another file for hotspot.txt and created it in ansible with a 'contents=OK' since it was not at all clear that a \n was in there or important. And indeed everyone using the NM detection said it was working fine, so we left it at that. kevin pgp6ObR4br6wY.pgp Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora captive portal page changed output :(
On Mon, 2016-12-05 at 14:55 -0500, Christian Schaller wrote: > Actually, I was told that Debarshi committed a fix for the TLS error > in captive portal just last > week and has pushed a fix for it. It's two different issues unfortunately. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora captive portal page changed output :(
Actually, I was told that Debarshi committed a fix for the TLS error in captive portal just last week and has pushed a fix for it. Christian - Original Message - > From: "Michael Catanzaro" <mcatanz...@gnome.org> > To: "Development discussions related to Fedora" > <devel@lists.fedoraproject.org> > Sent: Monday, December 5, 2016 1:16:08 PM > Subject: Re: Fedora captive portal page changed output :( > > On Mon, 2016-12-05 at 09:59 -0500, Paul Wouters wrote: > > Right now, the situation leads me to having to close the gnome window > > which only displays "TLS certificate invalid" or some text like that, > > and still use my firefox and a new tab/window to get through the > > captive portal. > > Good point. I guess ignoring TLS errors might mean better overall > safety here. :/ At least for the next couple of years. > > Ideally we would fix this bug before making any changes to that: > > https://bugzilla.gnome.org/show_bug.cgi?id=749197 > > It's assigned to me, which means I'll do it eventually for some value > of eventually; help always welcome > > > In which case we are exposing the full firefox with > > all my privacy settings and cookies to the captive portal, instead of > > (what I hope to be) some "private window" gnome web browser that has > > no access to any of my personal data. So I'd rather see the gnome > > window ignoring the TLS error and proceeding. > > Unfortunately you hoped too much, looks like it's using default WebKit > data directories. I think it probably can't read your cookies from > other apps as cookies work a bit differently, but it is getting > everything else from the default WebKit data dirs. It really should use > a private data dir, which is very easy to fix; then that would avoid > any concerns about caching as well. Modified bug report: > > https://bugzilla.gnome.org/show_bug.cgi?id=775639 > > BTW, full portal helper bug list: > > https://bugzilla.gnome.org/buglist.cgi?quicksearch=component:portal-helper%20product:"gnome-shell"%20_id=173288 > > Michael > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora captive portal page changed output :(
On Mon, 2016-12-05 at 09:59 -0500, Paul Wouters wrote: > Right now, the situation leads me to having to close the gnome window > which only displays "TLS certificate invalid" or some text like that, > and still use my firefox and a new tab/window to get through the > captive portal. Good point. I guess ignoring TLS errors might mean better overall safety here. :/ At least for the next couple of years. Ideally we would fix this bug before making any changes to that: https://bugzilla.gnome.org/show_bug.cgi?id=749197 It's assigned to me, which means I'll do it eventually for some value of eventually; help always welcome > In which case we are exposing the full firefox with > all my privacy settings and cookies to the captive portal, instead of > (what I hope to be) some "private window" gnome web browser that has > no access to any of my personal data. So I'd rather see the gnome > window ignoring the TLS error and proceeding. Unfortunately you hoped too much, looks like it's using default WebKit data directories. I think it probably can't read your cookies from other apps as cookies work a bit differently, but it is getting everything else from the default WebKit data dirs. It really should use a private data dir, which is very easy to fix; then that would avoid any concerns about caching as well. Modified bug report: https://bugzilla.gnome.org/show_bug.cgi?id=775639 BTW, full portal helper bug list: https://bugzilla.gnome.org/buglist.cgi?quicksearch=component:portal-helper%20product:"gnome-shell"%20_id=173288 Michael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora captive portal page changed output :(
On Mon, 2016-12-05 at 15:37 +0100, Florian Weimer wrote: > If I remember correctly, the browser accessing a captive portal does > not > use the regular user Firefox profile, so we either have to preload > its > profiles with intermediate CAs, or copy them over from the user's > Firefox profile. The browser uses WebKit, which will probably never support caching intermediate certificates because I think deterministic certificate validation behavior is highly desirable [1]. So copying intermediate certificates is not an option. Michael [1] https://blogs.gnome.org/mcatanzaro/2015/01/30/mozilla-is-responsible-for-the-redhat-corpmerchandise-com-fiasco/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora captive portal page changed output :(
On Mon, 5 Dec 2016, Michael Catanzaro wrote: On Mon, 2016-12-05 at 09:05 -0500, Paul Wouters wrote: That is incorrect in my experience. When I go to coffee shops, my iphone shows the portal page, but my laptop shows the TLS cert invalid thing. Oh wow. I didn't know that. Feels like time to give up Anything captive portal does feel that way, although there is some hope on the horizon with the IETF captive portal working group that is trying to make this a little easier and more standarized. https://datatracker.ietf.org/wg/capport/charter/ So what's your recommendation, just ignore all TLS errors and accept that anybody can intercept your credentials for the portal? It could be a problem because AFAIK some portals are using Google credentials for authentication nowadays. I don't know much about that With certificate transparency becoming mandatory, the number of bogus self signed certs and certs signed for bogus made up domains should decrease as browsers will just refuse to load these. So I do think we will see a move where if they use certificates, it will actually have to be a valid one chained to a valid public root CA, which means the DNS name has to be a real valid FQDN and not some made up goo. But we are not there yet. So I think a warning might be appropriate. Credential passing is hard. If done right, the user would only use something OAUTH like where it is a challenge/response that the portal will have to relay via the real authentication servers. But if they will just put up a "sign in with XXX" and a user/password box, likely many users will just give them their full credentials anyway. I doubt any green URL bar, padlock or us giving warnings will do anything about that :( Right now, the situation leads me to having to close the gnome window which only displays "TLS certificate invalid" or some text like that, and still use my firefox and a new tab/window to get through the captive portal. In which case we are exposing the full firefox with all my privacy settings and cookies to the captive portal, instead of (what I hope to be) some "private window" gnome web browser that has no access to any of my personal data. So I'd rather see the gnome window ignoring the TLS error and proceeding. Yeah, I actually filed a bug for this a while back: https://bugzilla.gnome.org/show_bug.cgi?id=750941 Or a cached page? It's been happening to me on f24 for a few weeks now. Paul Um... yeah maybe, I don't see any code in the portal helper to disable caching at all. Bug: https://bugzilla.gnome.org/show_bug.cgi?id=775639 Thanks for filing those! Paul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora captive portal page changed output :(
On 12/05/2016 03:05 PM, Paul Wouters wrote: On Sun, 4 Dec 2016, Michael Catanzaro wrote: 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. That is incorrect in my experience. When I go to coffee shops, my iphone shows the portal page, but my laptop shows the TLS cert invalid thing. Is it due to a missing intermediate certificate? If I remember correctly, the browser accessing a captive portal does not use the regular user Firefox profile, so we either have to preload its profiles with intermediate CAs, or copy them over from the user's Firefox profile. Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora captive portal page changed output :(
On Mon, 2016-12-05 at 09:05 -0500, Paul Wouters wrote: > That is incorrect in my experience. When I go to coffee shops, my > iphone > shows the portal page, but my laptop shows the TLS cert invalid > thing. Oh wow. I didn't know that. Feels like time to give up So what's your recommendation, just ignore all TLS errors and accept that anybody can intercept your credentials for the portal? It could be a problem because AFAIK some portals are using Google credentials for authentication nowadays. I don't know much about that > Yes. That is why I specifically requested that the fedora hotspot > page > never chage their output and never send a redirect. Using the main > page > of gnome was a bad fit. Note you should also ensure that > nmcheck.gnome.org > has a cache lifetime of 0 seconds to it. Yeah, I actually filed a bug for this a while back: https://bugzilla.gnome.org/show_bug.cgi?id=750941 > Or a cached page? It's been happening to me on f24 for a few weeks > now. > > Paul Um... yeah maybe, I don't see any code in the portal helper to disable caching at all. Bug: https://bugzilla.gnome.org/show_bug.cgi?id=775639 Michael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora captive portal page changed output :(
On Sun, 4 Dec 2016, Michael Catanzaro wrote: 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. That is incorrect in my experience. When I go to coffee shops, my iphone shows the portal page, but my laptop shows the TLS cert invalid thing. 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. Yes. That is why I specifically requested that the fedora hotspot page never chage their output and never send a redirect. Using the main page of gnome was a bad fit. Note you should also ensure that nmcheck.gnome.org has a cache lifetime of 0 seconds to it. 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. Or a cached page? It's been happening to me on f24 for a few weeks now. Paul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora captive portal page changed output :(
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@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora captive portal page changed output :(
On Sun, 4 Dec 2016, Kevin Fenzi wrote: On Fri, 2 Dec 2016 21:42:07 -0600 Eric Sandeenwrote: On 12/2/16 7:10 PM, Paul Wouters wrote: Fedora runs a captive portal check page at: http://fedoraproject.org/static/hotspot.txt It used to return "OK\n". Now it returns "OK" without the newline. Seems like the file date is still well in the past (2015-12-15) and does not actually contain a newline; webserver behavior change? Looking at archive.org, I do see the newline in: https://web.archive.org/web/20150616184630/https://fedoraproject.org/static/hotspot.txt but not in: https://web.archive.org/web/20160213221103/http://fedoraproject.org/static/hotspot.txt Indeed it seems the changes made on 2015-12-15 removed the newline. ;( Sorry about that. I can put it back since it seems like NetworkManager's portal detection doesn't care, or just leave it off now since it's been that way for around a year? I guess leave it as is. But it would be good if we can find out what happened, and fix the process. Paul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora captive portal page changed output :(
On Fri, 2 Dec 2016 21:42:07 -0600 Eric Sandeenwrote: > On 12/2/16 7:10 PM, Paul Wouters wrote: > > > > Fedora runs a captive portal check page at: > > > > http://fedoraproject.org/static/hotspot.txt > > > > It used to return "OK\n". > > > > Now it returns "OK" without the newline. > > Seems like the file date is still well in the past > (2015-12-15) and does not actually contain a newline; > webserver behavior change? Looking at archive.org, I do see the newline in: https://web.archive.org/web/20150616184630/https://fedoraproject.org/static/hotspot.txt but not in: https://web.archive.org/web/20160213221103/http://fedoraproject.org/static/hotspot.txt Indeed it seems the changes made on 2015-12-15 removed the newline. ;( Sorry about that. I can put it back since it seems like NetworkManager's portal detection doesn't care, or just leave it off now since it's been that way for around a year? kevin pgp6WdaDzCPex.pgp Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora captive portal page changed output :(
On Sat, 3 Dec 2016, Langdon White wrote: Wouldn't it make more sense to be checking for status 200? Checking for content on the page seems fragile in general. Who says a stolen page wouldn't return status 200? Also, and perhaps related, I filed a bug[1] about captive portals that seems to have some attention. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1362449 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. I have that on top of the bug where it just shows me the gnome page instead of the actual captive portal page. Seems like the file date is still well in the past (2015-12-15) and does not actually contain a newline; webserver behavior change? That is my guess. I've pushed an update for geome (a tool to tell you your location based on IP address) which does a captive portal check to give a more meaningful error if a captive portal prevents it from working. Paul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora captive portal page changed output :(
On Dec 2, 2016 22:42, "Eric Sandeen"wrote: On 12/2/16 7:10 PM, Paul Wouters wrote: > > Fedora runs a captive portal check page at: > > http://fedoraproject.org/static/hotspot.txt > > It used to return "OK\n". > > Now it returns "OK" without the newline. Wouldn't it make more sense to be checking for status 200? Checking for content on the page seems fragile in general. Also, and perhaps related, I filed a bug[1] about captive portals that seems to have some attention. Langdon [1] https://bugzilla.redhat.com/show_bug.cgi?id=1362449 Seems like the file date is still well in the past (2015-12-15) and does not actually contain a newline; webserver behavior change? -Eric ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora captive portal page changed output :(
On 12/2/16 7:10 PM, Paul Wouters wrote: > > Fedora runs a captive portal check page at: > > http://fedoraproject.org/static/hotspot.txt > > It used to return "OK\n". > > Now it returns "OK" without the newline. Seems like the file date is still well in the past (2015-12-15) and does not actually contain a newline; webserver behavior change? -Eric ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora captive portal page changed output :(
On Fri, 2016-12-02 at 20:10 -0500, Paul Wouters wrote: > ps. Not sure if related or not, my gnome portal detection is no > longer > showing real captive portal pages, but instead just shows me a gnome > window. That should never happen. It *might* be related to [1][2] as that's the only thing that changed recently in GNOME [1] https://bugzilla.redhat.com/show_bug.cgi?id=1362449 [2] https://bugzilla.gnome.org/show_bug.cgi?id=769940 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora captive portal page changed output :(
Fedora runs a captive portal check page at: http://fedoraproject.org/static/hotspot.txt It used to return "OK\n". Now it returns "OK" without the newline. This caused at least the geome tool (from the geome package) to return a false positive and abort, telling the user to first authenticate to the hotspot. I'm pushing a fix now for geome to allow either one of these outputs. Other packages using the hotspot detection page might have been similarly broken. Paul ps. Not sure if related or not, my gnome portal detection is no longer showing real captive portal pages, but instead just shows me a gnome window. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org