7:10 p.m.
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.
9:36 p.m.
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
9:42 p.m.
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
11:28 p.m.
On Dec 2, 2016 22:42, "Eric Sandeen" <sandeen(a)redhat.com> 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(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
3:39 p.m.
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.
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
8:19 p.m.
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
8:05 a.m.
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
8:31 a.m.
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
8:59 a.m.
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
12:16 p.m.
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-helpe...
Michael
1:55 p.m.
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" <mcatanzaro(a)gnome.org>
> To: "Development discussions related to Fedora"
<devel(a)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-helpe...
>
> Michael
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>
12:55 p.m.
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
10:50 a.m.
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
1:21 p.m.
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
8:37 a.m.
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
11:57 a.m.
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-...
5:05 p.m.
On Fri, 2 Dec 2016 21:42:07 -0600
Eric Sandeen <sandeen(a)redhat.com> 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/stat...
but not in:
https://web.archive.org/web/20160213221103/http://fedoraproject.org/stati...
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
6:44 p.m.
On Sun, 4 Dec 2016, Kevin Fenzi wrote:
On Fri, 2 Dec 2016 21:42:07 -0600
Eric Sandeen <sandeen(a)redhat.com> 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/stat...
but not in:
https://web.archive.org/web/20160213221103/http://fedoraproject.org/stati...
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
10:16 p.m.
On Sun, 4 Dec 2016 19:44:22 -0500 (EST)
Paul Wouters <paul(a)nohats.ca> wrote:
On Sun, 4 Dec 2016, Kevin Fenzi wrote:
> On Fri, 2 Dec 2016 21:42:07 -0600
> Eric Sandeen <sandeen(a)redhat.com> 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/stat...
> but not in:
>
https://web.archive.org/web/20160213221103/http://fedoraproject.org/stati...
>
> 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
2722
days inactive
2727
days old
20 comments
8 participants
participants (8)
-
Christian Schaller -
Dennis Gilmore -
Eric Sandeen -
Florian Weimer -
Kevin Fenzi -
Michael Catanzaro -
Paul Wouters -
White, Langdon