Operating Systems and Browsers Use Specific URLs to Detect Public WiFi Captive Portals
Honeypots have detected traffic to Firefox's captive portal detection URL, highlighting the methods operating systems and browsers use to identify public WiFi login pages.
Honeypots have recently detected traffic directed towards http://detectportal.firefox.com/success.txt, a URL used by Firefox to identify captive portals on public Wi-Fi networks. This detection is part of a broader mechanism employed by various operating systems and browsers to ascertain if a network requires user authentication before granting full internet access.
Captive portals, commonly found in public Wi-Fi hotspots like those in hotels, airports, and cafes, present a login or terms-of-service agreement page to users. Historically, these portals could easily intercept non-encrypted HTTP connections. However, the widespread adoption of TLS (Transport Layer Security) and browser defaults to secure connections have made this interception more challenging, as browsers are reluctant to downgrade to non-secure HTTP.
To overcome this, operating systems and browsers have implemented specific HTTP URLs that they attempt to access. When a device connects to a new network, it probes these URLs. If the network's captive portal is active, it will typically redirect the request to the portal's login page. The system then detects this redirection and opens the portal page in the user's default browser, facilitating the login process.
Different platforms utilize distinct URLs for this detection. Microsoft Windows employs http://www.msftconnecttest.com/connecttest.txt as part of its Network Connectivity Status Indicator (NCSI), expecting the response "Microsoft Connect Test." Apple devices, including recent macOS and iOS versions, use http://captive.apple.com/hotspot-detect.html, which should return "Success."
Android devices check http://connectivitycheck.android.com/generate_204, expecting an empty page with a 204 (No Content) status code. Google Chrome and Chromium browsers use http://www.gstatic.com/generate_204 or http://clients3.google.com/generate_204, also aiming for a 204 response.
Firefox's detection URL, http://detectportal.firefox.com/canonical.html, returns a 200 status code and includes a META tag for redirection. This page helpfully provides information about how Firefox handles captive portals, offering a degree of transparency for users and analysts.
The common thread among all these detection URLs is their use of HTTP. This is a deliberate choice, as it allows the captive portal to intercept the request and redirect the user to the appropriate login or splash page. Without this HTTP redirection capability, the system would not be able to discover the captive portal.
For users experiencing difficulties accessing a captive portal, manually navigating to one of these detection URLs in a browser can sometimes trigger the redirection, helping them connect to the network. The detection of these URLs by honeypots, as observed by the SANS Internet Storm Center, indicates normal client behavior when encountering public Wi-Fi networks.