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