RE: [WIRELESS-LAN] Defeating Android 8.X Captive Portal detection

[Thomas Carter]

Yes, we have had some who have had trouble in the past say they also sometimes 
had issues at Starbucks, et al. So the assumption that EDU is the only place 
they have issues may not be correct. I do think there should be better 
communication between wireless vendors, wireless device makers (esp Microsoft, 
Apple, and Google), and customers about these kind of changes. Why do we have 
to figure this out at all? It shouldn't be this hard.

Thomas Carter
Network & Operations Manager / IT
Austin College
900 North Grand Avenue 
Sherman, TX 75090
Phone: 903-813-2564
www.austincollege.edu


-Original Message-
From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Curtis K. Larsen
Sent: Wednesday, September 6, 2017 1:51 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Defeating Android 8.X Captive Portal detection

My comment had more to do with standardized captive browser behavior across 
operating systems than ease of use.  Unless you are inferring that all of EDU 
go without a captive portal.  Most of the public places I visit have a captive 
portal so I'd say the same questions apply there too.

-Curtis


From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
 on behalf of Jeffrey D. Sessler 

Sent: Wednesday, September 6, 2017 11:53 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Defeating Android 8.X Captive Portal detection

On 9/6/17, 8:46 AM, "The EDUCAUSE Wireless Issues Constituent Group Listserv on 
behalf of Curtis K. Larsen"  wrote:



It would be really nice if Google would join the club and allow their 
captive browser to switch to a full browser after the internet is reachable, 
but until then I think it's the best we can do.





I'd argue, that again, why are we in EDU making it so hard for users with these 
devices to get access to WIFi? It those devices work in every other setting, be 
it at Starbucks, Panara, Hospitals, HomeDepot, and so on... Then EDU is doing 
something wrong.



The vendors will continue to support/do what's most compatible with "the rest 
of the world" so it's up to EDU to come to terms with why we are so different, 
and so device hostile.



Jeff

** Participation and subscription information for this EDUCAUSE 
Constituent Group discussion list can be found at 
http://www.educause.edu/discuss.

**
Participation and subscription information for this EDUCAUSE Constituent Group 
discussion list can be found at http://www.educause.edu/discuss.

**
Participation and subscription information for this EDUCAUSE Constituent Group 
discussion list can be found at http://www.educause.edu/discuss.

Re: [WIRELESS-LAN] Defeating Android 8.X Captive Portal detection

[Curtis K. Larsen]

My comment had more to do with standardized captive browser behavior across 
operating systems than ease of use.  Unless you are inferring that all of EDU 
go without a captive portal.  Most of the public places I visit have a captive 
portal so I'd say the same questions apply there too.

-Curtis


From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
 on behalf of Jeffrey D. Sessler 

Sent: Wednesday, September 6, 2017 11:53 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Defeating Android 8.X Captive Portal detection

On 9/6/17, 8:46 AM, "The EDUCAUSE Wireless Issues Constituent Group Listserv on 
behalf of Curtis K. Larsen"  wrote:



It would be really nice if Google would join the club and allow their 
captive browser to switch to a full browser after the internet is reachable, 
but until then I think it's the best we can do.





I’d argue, that again, why are we in EDU making it so hard for users with these 
devices to get access to WIFi? It those devices work in every other setting, be 
it at Starbucks, Panara, Hospitals, HomeDepot, and so on… Then EDU is doing 
something wrong.



The vendors will continue to support/do what’s most compatible with “the rest 
of the world” so it’s up to EDU to come to terms with why we are so different, 
and so device hostile.



Jeff

** Participation and subscription information for this EDUCAUSE 
Constituent Group discussion list can be found at 
http://www.educause.edu/discuss.

**
Participation and subscription information for this EDUCAUSE Constituent Group 
discussion list can be found at http://www.educause.edu/discuss.

Re: [WIRELESS-LAN] Defeating Android 8.X Captive Portal detection

[Jeffrey D. Sessler]

On 9/6/17, 8:46 AM, "The EDUCAUSE Wireless Issues Constituent Group Listserv on 
behalf of Curtis K. Larsen"  wrote:



It would be really nice if Google would join the club and allow their 
captive browser to switch to a full browser after the internet is reachable, 
but until then I think it's the best we can do.





I’d argue, that again, why are we in EDU making it so hard for users with these 
devices to get access to WIFi? It those devices work in every other setting, be 
it at Starbucks, Panara, Hospitals, HomeDepot, and so on… Then EDU is doing 
something wrong.



The vendors will continue to support/do what’s most compatible with “the rest 
of the world” so it’s up to EDU to come to terms with why we are so different, 
and so device hostile.



Jeff

**
Participation and subscription information for this EDUCAUSE Constituent Group 
discussion list can be found at http://www.educause.edu/discuss.

ITDRC disaster relief donations

[Richard Nedwich]

Folks,

With so many people impacted by Hurricane Harvey, and potentially soon by 
Hurricane Irma,  I hope this group would welcome notice of an opportunity for 
your IT organizations to help provide relief. ITDR is a 501 (c) non-profit 
organization made up of professionals from the IT community who donate their 
time to assisting with telecom needs for disaster recovery. You can learn more 
about them here: https://itdrc.org/about.  If any EDUCAUSE Listserv community 
members (or your reseller partners) would like to donate old WLAN gear they can 
send it here: 

NRG/ITDRC
Attn: Tom Jewell
12307 Kurland Dr.
Houston, TX 77034

Doesn’t matter how old it is, ITDRC will take anything. If they drop us a note, 
we’ll make sure anything they send is fully licensed and upgraded and can help 
with setup.

Last time I checked, we’re up to about 140 APs that Ruckus will be shipping in 
addition to hosting them on a virtual SmartZone (vSZ).  
Thanks in advance to everyone who chooses to contribute relief one way or 
another!

Best,
Rich
P.S. all vendor models are accepted, not just Ruckus, so a good chance to clean 
out the closets and hallways!
P.P.S. equipment will be collected and re-used after Harvey relief, and could 
be used again where needed!!

**
Participation and subscription information for this EDUCAUSE Constituent Group 
discussion list can be found at http://www.educause.edu/discuss.

Re: Defeating Android 8.X Captive Portal detection

[Curtis K. Larsen]

We had the same problem.   We even discovered Android phones that were set to 
proxy (web-caching feature) requests to google.com so they would never even 
see/accept the captive portal AUP at all.  We switched to WiSPr (all blocked) 
and then the problem was that as soon as the internet became reachable the 
captive browser shuts down.  It occurs on both Android 6.0+ and ChromeOS.We 
had three developers trying to code around it with javascript but with no 
success.  

Eventually, we settled on the best guest user experience being that a user gets 
prompted with WiSPr authentication (everything blocked) so they know they have 
to accept an agreement.  After that we re-direct the operating systems that 
allow redirecting while removing the blocks so they switch to a full/real 
browser to complete onboarding steps if they choose.  

It would be really nice if Google would join the club and allow their captive 
browser to switch to a full browser after the internet is reachable, but until 
then I think it's the best we can do.


--
Curtis K. Larsen
Senior Wi-Fi Network Engineer
University of Utah IT/CIS



From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
 on behalf of Turner, Ryan H 

Sent: Wednesday, September 6, 2017 7:51 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Defeating Android 8.X Captive Portal detection

We haven’t had the problem with OSX.  I worked hard to get rid of captive 
portal detection on all browsers.  Everything has been great, until now.

We have a setup like this:

We use a pfSense firewall on an onboarding SSID.  Users have 2 states:  
unauthenticated and authenticated.  Prior to be authorized (which requires 
logging in on a web portal), their connection is extremely limited except with 
whatever holes I have poked through to defeat captive portal detection and make 
things smoother.  One they are authenticated, there is NO ACL on the back-end, 
but I do blackhole a bunch of popular sites (through DNS redirection) so people 
will not use the onboarding SSID for browsing.  For the new Android, with our 
setup, the pseudo browser remains open, even post authentication (which 
probably means one of those black holes sites I have is being checked and still 
doesn’t indicate connectivity).

My ‘workaround’ for the moment is to allow google.com to go through…  which is 
not a good one.  Since google.com is most people’s default page, it means they 
will NOT get a wireless redirect to login and authenticate until they browse 
somewhere else.  So I don’t think I am going to keep this.  I may just have to 
add some verbage to the login page that educate android users, but it will 
probably only be read 1 out of 10 times.

I really hate how it feels like we are having to constantly work against google 
with this stuff…


Ryan Turner
Manager of Network Operations
ITS Communication Technologies
The University of North Carolina at Chapel Hill

r...@unc.edu
+1 919 445 0113 Office
+1 919 274 7926 Mobile



From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Wyatt Schill
Sent: Tuesday, September 5, 2017 4:53 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Defeating Android 8.X Captive Portal detection

This is the same problem we have with Mac laptops, the ‘pseudo’ browser will 
allow the user to run through the whole onboarding process until the final 
download step where it refuses to allow the user to download a config file.

Our only fixes are to continually educate users to close the ‘pseudo’ browser 
and open a full version of safari, or to add pre-auth acls to allow the device 
to fully access the apple urls it is checking so that the ‘pseudo’ browser 
never pops up and the user manually opens a standard browser to get the initial 
captive portal.

Looks like android will need something similar.  (although we already have some 
of google open to allow guests to use google credentials to authenticate, so it 
probably won’t be much extra to add)

Wyatt Schill
Senior Network Engineer
CCNA-Security, CCNP-R&S
Green River College
12401 SE 320th St. Auburn, WA 98092
wsch...@greenriver.edu
[Green River new official mascot logoEmail]

From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Turner, Ryan H
Sent: Tuesday, September 5, 2017 1:34 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: [WIRELESS-LAN] Defeating Android 8.X Captive Portal detection

Even though Android is only 7% of our install base, it amounts to 75% of my 
problems…

It ‘appears’ on first glance that google has changed the captive portal 
detection on version 8.  It ‘appears’ (very early into this, so this may 
change) that google now checks for both a generate_204 on both 
connectivitycheck.gstatic.com a

RE: Defeating Android 8.X Captive Portal detection

[Turner, Ryan H]

So, for the time being, I am adding some very simple javascript to the landing 
page.  If it detects Android 8, it will display a message telling the user that 
after login, they must close the browser and open a new one and goto 
wifi.unc.edu.  I am going to play around with the browser environment variables 
and see if it is possible to discover if they are in the pseudo browser (look 
at the difference in environment variables between the full browser and the 
pseudo browser).  If so, I can just take away the login option until they open 
a browser with full power...

From: Turner, Ryan H
Sent: Wednesday, September 6, 2017 9:54 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: RE: Defeating Android 8.X Captive Portal detection

We haven't had the problem with OSX.  I worked hard to get rid of captive 
portal detection on all browsers.  Everything has been great, until now.

We have a setup like this:

We use a pfSense firewall on an onboarding SSID.  Users have 2 states:  
unauthenticated and authenticated.  Prior to be authorized (which requires 
logging in on a web portal), their connection is extremely limited except with 
whatever holes I have poked through to defeat captive portal detection and make 
things smoother.  One they are authenticated, there is NO ACL on the back-end, 
but I do blackhole a bunch of popular sites (through DNS redirection) so people 
will not use the onboarding SSID for browsing.  For the new Android, with our 
setup, the pseudo browser remains open, even post authentication (which 
probably means one of those black holes sites I have is being checked and still 
doesn't indicate connectivity).

My 'workaround' for the moment is to allow google.com to go through...  which 
is not a good one.  Since google.com is most people's default page, it means 
they will NOT get a wireless redirect to login and authenticate until they 
browse somewhere else.  So I don't think I am going to keep this.  I may just 
have to add some verbage to the login page that educate android users, but it 
will probably only be read 1 out of 10 times.

I really hate how it feels like we are having to constantly work against google 
with this stuff...


Ryan Turner
Manager of Network Operations
ITS Communication Technologies
The University of North Carolina at Chapel Hill

r...@unc.edu
+1 919 445 0113 Office
+1 919 274 7926 Mobile



From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Wyatt Schill
Sent: Tuesday, September 5, 2017 4:53 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Defeating Android 8.X Captive Portal detection

This is the same problem we have with Mac laptops, the 'pseudo' browser will 
allow the user to run through the whole onboarding process until the final 
download step where it refuses to allow the user to download a config file.

Our only fixes are to continually educate users to close the 'pseudo' browser 
and open a full version of safari, or to add pre-auth acls to allow the device 
to fully access the apple urls it is checking so that the 'pseudo' browser 
never pops up and the user manually opens a standard browser to get the initial 
captive portal.

Looks like android will need something similar.  (although we already have some 
of google open to allow guests to use google credentials to authenticate, so it 
probably won't be much extra to add)

Wyatt Schill
Senior Network Engineer
CCNA-Security, CCNP-R&S
Green River College
12401 SE 320th St. Auburn, WA 98092
wsch...@greenriver.edu
[Green River new official mascot logoEmail]

From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Turner, Ryan H
Sent: Tuesday, September 5, 2017 1:34 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: [WIRELESS-LAN] Defeating Android 8.X Captive Portal detection

Even though Android is only 7% of our install base, it amounts to 75% of my 
problems...

It 'appears' on first glance that google has changed the captive portal 
detection on version 8.  It 'appears' (very early into this, so this may 
change) that google now checks for both a generate_204 on both 
connectivitycheck.gstatic.com and a gen_204 on 
www.google.com.  Why is this a problem?

We, as many people do, have a onboarding SSID.  TLS requires proper onboarding. 
  That means that we need to process people through the portal in an orderly 
manner to get them where they need to go.   When Android 8.X detects a captive 
portal, it will prompt the user to 'sign in'.  This process opens a pseudo 
browser (a browser that is limited in what it can do) to the captive portal 
login.  After the user logs in, the user stays inside of the 'pseudo' browser.  
The browser has limited powers, and apparently will not allow the user to 
download or install an agent or confi

RE: Defeating Android 8.X Captive Portal detection

[Turner, Ryan H]

We haven't had the problem with OSX.  I worked hard to get rid of captive 
portal detection on all browsers.  Everything has been great, until now.

We have a setup like this:

We use a pfSense firewall on an onboarding SSID.  Users have 2 states:  
unauthenticated and authenticated.  Prior to be authorized (which requires 
logging in on a web portal), their connection is extremely limited except with 
whatever holes I have poked through to defeat captive portal detection and make 
things smoother.  One they are authenticated, there is NO ACL on the back-end, 
but I do blackhole a bunch of popular sites (through DNS redirection) so people 
will not use the onboarding SSID for browsing.  For the new Android, with our 
setup, the pseudo browser remains open, even post authentication (which 
probably means one of those black holes sites I have is being checked and still 
doesn't indicate connectivity).

My 'workaround' for the moment is to allow google.com to go through...  which 
is not a good one.  Since google.com is most people's default page, it means 
they will NOT get a wireless redirect to login and authenticate until they 
browse somewhere else.  So I don't think I am going to keep this.  I may just 
have to add some verbage to the login page that educate android users, but it 
will probably only be read 1 out of 10 times.

I really hate how it feels like we are having to constantly work against google 
with this stuff...


Ryan Turner
Manager of Network Operations
ITS Communication Technologies
The University of North Carolina at Chapel Hill

r...@unc.edu
+1 919 445 0113 Office
+1 919 274 7926 Mobile



From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Wyatt Schill
Sent: Tuesday, September 5, 2017 4:53 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Defeating Android 8.X Captive Portal detection

This is the same problem we have with Mac laptops, the 'pseudo' browser will 
allow the user to run through the whole onboarding process until the final 
download step where it refuses to allow the user to download a config file.

Our only fixes are to continually educate users to close the 'pseudo' browser 
and open a full version of safari, or to add pre-auth acls to allow the device 
to fully access the apple urls it is checking so that the 'pseudo' browser 
never pops up and the user manually opens a standard browser to get the initial 
captive portal.

Looks like android will need something similar.  (although we already have some 
of google open to allow guests to use google credentials to authenticate, so it 
probably won't be much extra to add)

Wyatt Schill
Senior Network Engineer
CCNA-Security, CCNP-R&S
Green River College
12401 SE 320th St. Auburn, WA 98092
wsch...@greenriver.edu
[Green River new official mascot logoEmail]

From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Turner, Ryan H
Sent: Tuesday, September 5, 2017 1:34 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: [WIRELESS-LAN] Defeating Android 8.X Captive Portal detection

Even though Android is only 7% of our install base, it amounts to 75% of my 
problems...

It 'appears' on first glance that google has changed the captive portal 
detection on version 8.  It 'appears' (very early into this, so this may 
change) that google now checks for both a generate_204 on both 
connectivitycheck.gstatic.com and a gen_204 on 
www.google.com.  Why is this a problem?

We, as many people do, have a onboarding SSID.  TLS requires proper onboarding. 
  That means that we need to process people through the portal in an orderly 
manner to get them where they need to go.   When Android 8.X detects a captive 
portal, it will prompt the user to 'sign in'.  This process opens a pseudo 
browser (a browser that is limited in what it can do) to the captive portal 
login.  After the user logs in, the user stays inside of the 'pseudo' browser.  
The browser has limited powers, and apparently will not allow the user to 
download or install an agent or configuration files.  You can see the 
problem...  They will get to the onboarding page, and nothing will work.

I've managed to 'by pass' the problem, but it isn't ideal.  Has anyone else 
seen this with commercial portals and figured out ways around it?

It is possible all of this is in error, but I just got done with a bunch of 
packet captures that seems to validate this.  I only have one Oreo user in my 
vicinity, so I will need to get my hands on a few more to see if this really is 
an issue, or just bad luck.

Ryan Turner
Manager of Network Operations
ITS Communication Technologies
The University of North Carolina at Chapel Hill

r...@unc.edu
+1 919 445 0113 Office
+1 919 274 7926 Mobile

** Participat