Endpoint Captive Portal Detection - Why?

This blog assumes that you have a general understanding of ISE Central Web Authentication. Endpoint Captive Portal Detection plays a critical role in improving the end-user experience when connecting to a captive portal protected WiFi network, such as an ISE CWA protected WiFi network. The captive portal detection brings to the attention of the user that they are required to complete additional steps to receive their network access, and depending on the endpoint, will automatically launch a browser to facilitate completing the additional login steps.

Without this captive portal detection, the user experience can suffer, as they may not understand that they need to open a web browser to complete the login process (particularly users who are not using web-based applications regularly). In addition to this, most websites that a user would manually browse to these days will be HTTPS (TCP/443), which will (at best) result in the user being presented a certificate warning they can accept or (at worst, with HSTS) present them with a dead end. This is because captive portal web-redirection is a Man-in-the-Middle attack in the sense that we intercept the web request from the client and impersonate the server response, so the HTTPS browser is doing the job it was (thankfully!) designed to do. Endpoint Captive Portal Detection avoids this well-intentioned Man-in-the-Middle attack detection by ensuring the captive portal is discovered only over non-secure, plain HTTP (TCP/80) which just so happens to be vulnerable to Man-in-the-Middle attacks!

Now that we have a basic understanding of why we need Endpoint Captive Portal Detection, let’s look at how a few popular endpoint operating systems accomplish this check.

Endpoint Captive Portal Detection – How?

The how is the easiest part! Each OS bakes in an HTTP request behind the scenes that expects some pre-defined, basic result. If that HTTP request does not return the expected result, the OS determines it is being held captive and pops open a browser for the user and runs the same baked in HTTP request (this time in front of the user’s eyeballs). This request will then follow the redirect instructions (sent by your Man-in-the-Middle, AKA the wireless controller/AP, who in turn received the redirect instruction from ISE). The table below lists the baked in HTTP destinations for a few popular endpoint operating systems.

For updated information, bookmark this page! Now that we know the why and how behind captive portal detection, let’s wrap up by looking into what happens after the captive portal is detected.

Endpoint Captive Portal Detection – What Happens?

Now that the endpoint has detected the network is holding them captive, what action does it take? This also differs depending upon the OS. See the table below.

A Closing Note on “Captive Portal Mini Browsers”

CPMB’s are not full featured web browsers. They are designed specifically to handle the needs of logging into a captive portal/hotspot. As such, care must be taken when implementing certain HTML features on your captive portal splash page. In most instances, javascript support is limited in some way and in the case of MacOS (12.4, 12.5, and 12.6 at least) CPMB, you cannot open ANY hyperlinks. You’ve been warned!

What’s Next?

Let me know in the comments if there is any topic of particular interest to you, and we’ll see about making that happen in the next installment! Thanks for reading!

As always if you have any questions on getting Cisco's ISE set up for you and your business and would like to schedule a free consultation with us, please reach out to us at sales@lookingpoint.com and we’ll be happy to help!

Want the answers to the most asked questions about ISE? Check out our video below!