Upcoming Changes for Meraki Captive Portal Networks/Splash customers using Google Authentication

[JoeTansey]

October 17, 2023

Users of google authentication behind splash captive portals need to be aware of a change in service due to a new policy from Google.

Until now, captive portals have redirected users (302 redirect) to a captive portal where authentication is optionally performed including Google Authentication, especially for .edu customers. In the near future, Google will be turning on enforcement of their new security posture which disallows the use of this method to redirect users to Google authentication.

Google authentication may still be used, but users will have to open a full/regular browser rather than the embedded browser/websheet to satisfy Google's security requirements. For this reason we have created a new pre-splash informational page that gives the user instructions for how to perform this. This only applies to mobile users, desktop users can bypass this step as they authenticate in a full browser already.

The new steps that a mobile user must do are now:

1.) Copy the URL provided with a 'tap here to copy the link' (URL is http://escapessl.com)

2.) Open a full browser, and copy this URL into the address field

3.) Login when prompted to Google

If the customer is using a walled garden that includes captive.apple.net and *.gstatic.com/*.google.com (or whatever captive portal OS the user has points to), they don't need to do anything. Otherwise, users may also have to select the equivalent of 'Use this network when not connected to the internet' or equivalent.

It is expected that Google will begin enforcement of this change starting towards the end of 2023.

Please let us know if you have any questions or concerns,

~Joe Tansey

Meraki Cloud Platform

joetanse@cisco.com

New instruction page

[PhilipDAth]

What would be cool is to have full SAML integration, so it works with more platforms and bypasses this issue ... 🙂

[BlakeRichardson]

YES!!!! This would make my life much easier. 

[JoeTansey]

Updated Graphic

[reems]

The pre-splash page shows even on regular desktop browsers. Is there a way to fix it?

[JoeTansey]

This pre-splash page is being sent to both mobile AND desktop. As it turns out from testing, Mac desktop needs the pre-splash page just like mobile devices as do Chromebooks. Only windows users seem to default to a "full browser" , and this is surprisingly difficult to effect (isolate user agents for the desktops that work/dont work)

[MrVench]

Has anyone seen that on Macs you have to use Safari? I tried visiting escapessl.com using Brave (a Chrome variant) and it just shows the "Success" page, but when I used Safari I was able to get to our network login page.

Relatedly, on a Chromebook I was able to join our employee network and use it without needing to authenticate at all. If I visited escapessl.com, it showed the "Success" page. This means our students could technically join the employee network and bypass all restrictions on the student network. So cool!

[lalgaze]

We are a Google Shop (including Chrome) and are getting the Success message vs. a Google login page.  At this point it seems like the only way around this is to use a different browser (Firefox on my phone) to be able to login, way too complicated for most users.  Can this be changed so Chrome works at that URL?  Is there a reason why it's not working on Chrome browser?

[JoeTansey]

Based on our testing, chrome browsers do work. Basically the accepted solution by the google auth API is to permit/allow any full browser that is invoking the google auth process--which definitely includes chrome.

please open a support ticket on this so we may track/address

thank you

[ceide]

See my response to MrVench above.  The "Success" message is a 200 response, which means that the browser successfully completed the http request.  Ensure that the request is actually being made over http and not https and check that your captive portal is set to disallow https traffic.

Usually, captive portal detection works because https traffic is blocked.  The https protocol does not allow redirects in the same way http does.  So the browser attempts an https connection, which is blocked by the network.  The browser then does a captive portal check over http to whichever captive portal detection url that the browser/system uses (http://captive.apple.com/, http://gstatic.com/generate_204, http://www.msftconnecttest.com/connecttest.txt are common examples).  If the redirect happens, then the system knows there's a captive portal in use.  If you get any "success" page, that means that the user is successfully completing a request to whatever endpoint they were trying to reach (i.e. - that user has internet access; assuming you're not viewing a cached page).

You might want to consider using the curl command from the terminal to take the browser out of the equation. curl http://escapessl.com/ should work just as well; plus, if you use verbose (curl -v http://escapessl.com/), you can view the headers and response code.

[JoeTansey]

Thank you for this response, this agrees with my understanding. Thanks again for taking the time to share/post this!

[ceide]

You might want to check your Access control configuration.  It sounds like you might have "allow non_HTTP access prior to sign in" enabled.  Did you fully qualify the escapessl.com URL?  If you type "escapessl.com" without specifying http, you may be connecting via https, which would be allowed by this option.  Try navigating to "http://escapessl.com".  The browser definitely shouldn't affect what you're seeing (an http request is an http request; you can verify this using curl in your terminal).

See https://documentation.meraki.com/MR/MR_Splash_Page/Splash_Page_Traffic_Flow_and_Troubleshooting under "Unauthenticated Client Has Full Network Access".

[lalgaze]

Our current settings are:

• Captive portal strength: Allow non-HTTP traffic prior to sign-on so we can get to the http://escapessl.com and the splash page 
• Walled garden : Disabled

Trying different variations on that doesn't seem to help.

Going to http://escapessl.com in Chrome returns "Success", in Firefox it brings me to my splash page so it doesn't seem to be the network but a Chrome setting that is different in Firefox maybe?

[Gateway-SF]

Meraki doesn't recommend your supported setup, and it's a bad idea for security as someone can pass a ton of non-HTTP traffic through your network without the user being authenticated. The recommended config is to not allow non-http traffic and enable a walled garden with a list of specified Google URLs to allow for the purposes of opening the captive portal prompt and, previously, to get the google login screen to load. 

[lalgaze]

Thank you for the recommendation.  Once this issue is resolved I will change our settings to that.  I want to ensure that does not get in the way of troubleshooting this issue.

[ceide]

I would change those settings now, as it is probably the reason you are having the issue to begin with.  See MrVench's reply below; Brave automatically redirects to https (Brave is Chromium based; it's not a stretch to think Chrome may be doing the same thing).  Your settings are currently allowing all non-HTTP traffic to pass through.  What's probably happening is this:

FIREFOX: You make a request for http://escapessl.com/ and Firefox executes the request as you entered it.  Since your access control is set to block HTTP traffic, you get the redirect to the captive portal.

CHROME: You make a request for http://escapessl.com/ and Chrome automatically attempts to retrieve https://escapessl.com/ instead.  Since your access control allows non-HTTP traffic (like this HTTPS request), the request goes through and you get a 200 response (Success).

I can verify on my own system that when I attempt to go to http://escapessl.com/ on Chrome, it is bringing me to https://escapessl.com/.

[ceide]

Allow non-HTTP traffic prior to sign-on so we can get to the http://escapessl.com and the splash page

 the splash page is http traffic. When it says to allow non http traffic, that’s going to include https. My guess is that your captive portal request is happening over https and your settings are allowing that traffic, so you’re getting that 200 response (success). Http should redirect properly, but it has to be over http (try going to https://captive.apple.com/ and then http://captive.apple.com/ my bet is that you see “success” on the first and get a redirect to the splash page on the second). You definitely do not need (nor want) to allow non http traffic to bring up the splash page.

[MrVench]

Thanks for taking the time to write, @ceide. Luckily, I had captured a screen recording of the behavior in Brave. What I didn't notice at first was that while I copied the http://escapessl.com address from the pre-splash page and pasted it in, it did redirect to https (same with neverssl.com), thus showing the Success page. Could be that Brave is redirecting http to https (that setting is set to "standard") and Safari is not. Thanks for pointing that out.

Has anyone else seen an issue where you can retain an internet connection without authenticating? We have this issue now -- students can connect to our employee network, ignore the authentication and retain an internet connection. Seems to have started when this splash change happened.

[ceide]

"Allow non-HTTP traffic prior to sign-on "

I can almost guarantee this setting is what's causing that behavior.  If you're allowing non-http traffic, then you're allowing the vast majority of traffic that goes over the internet today (the fact that websites like neverssl.com and escapessl.com even exist is because most pages redirect to https, making these captive portal situations difficult). Turn it off and the issue should go away.  Keep in mind that if you do have outside authentication requirements, you might have to use a walled garden, which allows users to access certain specified domains prior to authenticating in order to allow them to get to the authentication pages (accounts.google.com, for example).

As for Brave, it could be a setting or an extension.  A common extension, HTTPS-Everywhere from the Electronic Frontier Foundation (HTTPS Everywhere | Electronic Frontier Foundation (eff.org)) automatically forces https connections.  There are also browser settings that do the same thing (and since Brave tends to emphasize security/privacy, it wouldn't surprise me if that was enabled by default).  This is why I like to use the command line utility curl; it does exactly what you ask it to do.  (curl - Documentation Overview).

[MrVench]

Our network admin will look into this setting; thanks!

For Brave, I do not have any https-based extensions installed, but as I alluded to previously, there is built-in support for this in the Shields section of Brave's settings. Thanks again for your assistance.

[lalgaze]

Thank you for your responses.  Unfortunately I have changed the setting to allow no traffic before login and still no luck.  Even after enabling a walled garden and adding the Google suggested URLs plus *.escapessl.com, still no consistent solution.  Although it's a big thorn in my side fortunately it's not affecting our students so getting bumped down on my priority list in trying to work this out.  I would be appreciative if anyone else finds a solution. 

[roOl]

Hello,

today all of our users are impacted, even on laptops or workstations. If they need to have a 3d party auth, they are sent to this page.

[JoeTansey]

roOI, just wanted to double check: your users on a given SSID that is configured for ANY 3rd party auth (not just Google oAuth) is being redirected to the new pre-splash page we built specifically for this Google Auth change?

Thank you, also if possible could you open a support ticket on this if true I would like to track/solve this. 

[mrhammer]

same here.

[roOl]

Hey Joe,

in our org, we only use google auth, but every user is affected, not only mobile users.

"This only applies to mobile users, desktop users can bypass this step as they authenticate in a full browser already."

But I will open a case and let you know the case number.

[JoeTansey]

Apologies for the erroneous statement above ("this only affects mobile users"), as it turns out during our testing this affects BOTH mobile and desktop and we are pushing the pre-splash page to ALL users now.
Our official documentation on this topic is over here:->https://documentation.meraki.com/MR/MR_Splash_Page/Google_Sign-In

I apologize for not being able to edit the original post in this thread!

[Gateway-SF]

Since you've confirmed this, please update the new splash page to include instructions for desktop clients as well. It currently only shows instructions for Android and iOS. The current page causes user confusion, loss of productivity, panicked teachers and help desk tickets. There's also missing info in step 2 for Android.

[JoeTansey]

Hi, that step 2 for Android is actually a vertical ellipses which is the droid UI for opening the 'settings' page on the captive portal page in question.

We are adding in a line regarding "This also affects desktop users" quickly as well, thank you for the suggestion. Also since I'm here we're also going to be enabling our product support teams to disable this new pre-splash page on google auth SSIDs. We were trying to analyze the cost vs benefit of having the pre-splash page vs not, but after it has been enabled for a certain period of time the cons may begin to outweigh the benefits so we are enabling our support teams to be able to turn this feature off. But I agree with you that step may not be necessary if the instructions clearly explain the desktop user experience is highly similar.

[Gateway-SF]

I had a seasoned teacher with an android phone who could not comprehend step 2. It took me a few days to get to her to help. She was going Step 1, 4, 5. She didn't understand what step 2 was asking her to do, until I said - "wait, you need to click on the 3 vertical dots!" OH! She said, "they should include those directions (words) in Step 2 as a written prompt." I agree. Please send it up Joe!

Overall, I'd say a few steps need more directive info, like where does the user find "Cancel" in Step 2 for iOS? I know, but you really have to come at these instructions like you are explaining it to an elderly relative (nothing against the elderly!).

[Knowledge_gainr]

Hi ro0I,

Can you help me to create a custom splash page?

[loganhawker]

This change just hit our network, we just started rollout of a new SSID for staff & student personal devices with the Google splash. Now the process is changing.. our teachers & students *will not* understand to copy the address, cancel the splash, stay connected without internet, open a browser, paste the address, and go through the splash flow from there..

Is there some way to make this process smoother again? Can we do Google/Azure SAML SSO auth into the SSID instead? Would setting up our own splash page work to avoid this new splash flow?

https://github.com/AdamSpera/meraki-excap-cloudflare

[JoeTansey]

Yes, any auth method you choose OTHER THAN Google auth will permit the prior /smooth / splash flow. You can pick any of our supported auth methods (Meraki Auth, Radius, various 3rd party, etc)
Of course, you are free to deploy your own captive portal as you linked above, just be aware it isn't Meraki that is enforcing this auth requirement from a full browser, it is Google so make sure that you don't use the Google oauth API with your own token as you will end up in precisely the same place we and everyone else are.

[Knowledge_gainr]

Hi Loganhawker,

Can you help me to create a custom splash page?

[MNF123]

Is there a way to disable this "http://escapessl.com" feature? other than not using the Google OAuth authentication method?

[clehman-webfx]

Is there a way that we can customize the Pre-Splash page contents?  

As simple as copy and pasting "http://escapessl.com" into a browser window is, this is going to be a big change in the normal process for our end users and it is going to cause a lot of confusion and questions.  We have been thinking through some alternative workarounds, but since there does not appear to be anyway of avoiding this pre-splash screen we were hoping to at least add some customized content to it.  

[Gateway-SF]

Problem is that it does require some clients, like Macs, to actually click the "Cancel" button on the captive network splash, then open a browser and paste in the escapessl.com URL. If you skip the step and just open that URL in a browser, it doesn't invoke the "Sign In with Google" button - you just get a you're not connected message.

[ceide]

Bigger problem is on Chromebooks.  They need the internet to log in to the Chromebook, but can't get to the internet if the captive portal is in place.  So user opens Chromebook and is prompted to connect to the internet.  User chooses the network with the captive portal and the pop up comes up telling them to open http://escapessl.com/ in a full browser.  But they don't have access to the full browser until they log in.  Which they can't do unless they have internet.

[Gateway-SF]

Please allow Admins to set longer durations of time for the Splash Frequency. It currently maxes out at 90-days. Extending this would avoid clients from having to re-login and get stumped about the new instructions. This will reduce internal help desk tickets and client stress from delayed access to WiFi. 

As a school institution, I'd prefer to set the Splash Frequency to something like 10 months (300+ days). If someone leaves, I turn off their Google Account anyway and revoke their Meraki sign-in, so they also lose access to the network.

[JoeTansey]

I hear you and am forwarding this request to our product teams, thank you for sharing it here.

While we can do this, some elements of client tracking such as vendor/OS MAC randomization + persistence strategy can confound our efforts here.

[MrVench]

We would also love to extend this to at least a full school year.