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<mailto: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<mailto: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<mailto: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<http://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<mailto:r...@unc.edu> +1 919 445 0113 Office +1 919 274 7926 Mobile ********** 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.
