Wi-Fi - Captive Portal

Man-in-the-middle or captive portal? How each browser and OS knows

When a user comes across a captive portal, how do browsers and operating systems identify it is not a security threat? Here’s how browsers and OSs identify captive portals and report that intermediate state to users.

How Browsers and OSs Identify Captive Portals

Chrome

When chrome finds a problem with a security certificate, it will generate a request in the background to a public HTTP (nonsecure) URL served by Google (usually http://.google.com/generate_204). If this request gets an HTTP 204 response, it assumes the connection is OK, and the only possibility is a man-in-the-middle attack. Otherwise, if it gets any response distinct from 204 (usually a captive portal responds with a 3xx redirect), it assumes a captive portal is in place, avoiding successful connection to the original site. Upon that detection, it will open a new tab with the redirect destination and warn the user that a captive portal exists, and it may require authenticating to allow Internet access.

Correct visualization of a captive computer on Google chrome

Android

The principle is the same as the Chrome browser, but instead it is embedded on the operating system. It tries to reach the URL http://connectivitycheck.android.com/generate_204, and if it fails, it shows the operating system alert to the user, showing that the network may need authentication. If the user touches the alert, it opens the redirect target to a new browser tab, getting the user to the message.

An android device behind a Captive Portal

Internet Explorer / Windows

IE does not have the portal detection capability. Instead, Microsoft goes another route: it is implemented directly on the operating system network tools. Upon connecting to a network, Windows will try to download the file http://www.msftncsi.com/ncsi.txt and will expect an HTTP 200 response, and a specific text content. After that, it will try to resolve URL’s domain via DNS, and it should be 131.107.255.255. If it is not, it interprets that there are problems with the Internet connection. If it is correct, it will show a dialog bubble on the system bar, indicating that “It is possible that more information is required in order to connect to this network”. The user will get to the captive portal page upon clicking the bubble.

Windows PC behind a Captive Portal
(source http://blog.superuser.com/2011/05/16/windows-7-network-awareness/)

Mozilla Firefox

Sadly, Firefox does not implement any kind of captive portal detection. So if the user is trying to reach a secure HTTPS site, it will fail to cite the certificate validation error. Two possibilities arise from this case:

• If the operating system is Windows, the OS captive portal detection will kick in.
• If the OS is not windows, at some point the user will hit a non-secure website and reach the captive portal.

Apple iOS

Similar to the Android detection algorithm, but instead it checks against http://www.apple.com/library/test/success.html, expecting a response with the word “Success” in the body. Upon detection, it will open a browser pointing to the redirection URL, to let the user see the message or login onto a network.

When iOS detects a captive portal on the network, it opens a browser to the redirect URL

Contemporary security needs make transparent implementation of captive portals challenging. Thankfully, web browser and OS developers realize the importance of reporting the existence of this intermediate status between being connected to the Internet or not, this way reducing failure cases to a minimum.

fonte: https://thinkincredible.intraway.com/blog-post/how-browser-identify-captive-portals 


-----

How Automatic Detection of Captive Portal works

The Automatic Detection of Captive Portal mechanism is based on a simple verification, done by the Operational System (OS) of the client device (smartphone, tablet, laptop).

It simply tries to reach a specific URL and verify that such URL returns a well-known result.

• If a Captive Portal is not in place, the result will match the expected one and the OS will know that there is full access to internet.
• If the URL returns a result other than the expected one, then the OS will detect that there is a Captive Portal in place and that it's needed to proceed with authentication in order to get full access to internet: in this case the OS will open the Splash Page automatically.

 

Differences between Client devices

All client devices use the above described strategy to find out if they are behind a captive portal, but the URL might vary depending on the specific model of smartphone, tablet, laptop and depending on the specific OS version.

In the following you can find a list of known domains contacted by each model in order to eventually trigger the captive portal.

Android Captive Portal Detection

• clients3.google.com
• connectivitycheck.gstatic.com
• connectivitycheck.android.com

Apple iPhone, iPad with iOS 6 Captive Portal Detection

• gsp1.apple.com
• *.akamaitechnologies.com
• www.apple.com
• apple.com

Apple iPhone, iPad with iOS 7, 8, 9 and recent versions of OS X

• www.appleiphonecell.com
  
• *.apple.com
  
• www.itools.info
  
• www.ibook.info
  
• www.airport.us
  
• www.thinkdifferent.us
  
• *.apple.com.edgekey.net
  
• *.akamaiedge.net
  
• *.akamaitechnologies.com
  

 

Windows

• ipv6.msftncsi.com
• ipv6.msftncsi.com.edgesuite.net
• www.msftncsi.com
• www.msftncsi.com.edgesuite.net
• teredo.ipv6.microsoft.com
• teredo.ipv6.microsoft.com.nsatc.net

 

NOTE:
Consider that you can disable the Automatic Detection of Captive Portal on specific client devices simply adding all the listed domains for that specific device to the additional Walled garden.

To do so, please check this article:
How to enable/disable the Automatic Detection of Captive Portal and automatic opening of the Splash Page