Captive Portal Detection, (Tue, Jul 21st)
This article details how operating systems and browsers detect captive portals – the splash screens that appear when connecting to public Wi-Fi networks. Instead of intercepting old non-TLS homepages, these systems now use specific URLs to trigger a redirect to the captive portal login page. The URLs vary by OS (Windows, macOS, Android, and Firefox) and are used to verify the presence of a captive portal and direct users to the appropriate login page.
This article discusses the evolving methods used by operating systems and browsers to detect captive portals, a common occurrence when connecting to public Wi-Fi networks. Traditionally, users with non-TLS homepages were vulnerable to captive portals intercepting their connections and redirecting them to login pages. However, modern operating systems and browsers have implemented sophisticated detection mechanisms.
Instead of relying on old non-TLS configurations, these systems now utilize specific HTTP URLs to trigger a redirect. These URLs are designed to test whether a captive portal is present and to direct users to the appropriate login page.
Windows uses `http://www.msftconnecttest.com/connecttest.txt`, macOS and iOS use `http://captive.apple.com/hotspot-detect.html`, Android uses `http://connectivitycheck.android.com/generate_204`, and Chrome and Chromium use `http://www.gstatic.com/generate_204` and `http://clients3.google.com/generate_204`. Firefox utilizes `http://detectportal.firefox.com/canonical.html`.
Each of these URLs returns a specific HTTP response code (typically 204 No Content) to confirm the presence of a captive portal. The system then redirects the user to the login page. The article highlights that these techniques are crucial for a safer experience when using public Wi-Fi networks, as they prevent malicious actors from intercepting user credentials.