Captive Portal Detection via HTTP Ping and HTTPS Mutual Authentication
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current captive portal detection methods are unreliable, resource-intensive, and unable to distinguish between HTTP and HTTPS portals, leading to potential security risks and unnecessary hotspot disconnections.
Innovation Solution
A two-phase captive portal detection system using an Internet accessible web server and an endpoint captive portal detection application that sends HTTP ping requests and subsequent HTTPS queries with mutual authentication, minimizing unnecessary HTTPS requests and detecting both HTTP and HTTPS portals efficiently.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Ease of operation
If a single HTTP/HTTPS request method is used for captive portal detection, then the detection process is simple, but the reliability and accuracy of detection deteriorates
Solution Approach 1:
The detection process is segmented into multiple phases: an initial HTTP ping request phase to check basic connectivity and obtain a response token, followed by an HTTPS query request phase with mutual authentication to verify the actual portal status. This segmentation allows each phase to serve a specific detection purpose, improving overall reliability while maintaining operational simplicity through structured steps.
2Object-affected harmful factors
If HTTPS component is always included in detection requests, then security is improved, but processor cycles and hardware usage increase
Solution Approach 1:
The system performs preliminary action by first sending an HTTP ping request to check basic connectivity and obtain a response token before proceeding to the more resource-intensive HTTPS query request with mutual authentication. This preliminary step filters out cases where HTTPS is not needed, reducing unnecessary processor cycles and hardware usage while maintaining security where required.
Solution Approach 2:
The system applies partial action by using lightweight HTTP requests for initial detection and only employing full HTTPS requests with mutual authentication when necessary. This selective approach avoids excessive use of resource-intensive HTTPS mechanisms while maintaining adequate security protection for actual captive portal detection scenarios.
3Ease of manufacture
If currently available single HTTP/HTTPS request systems are used, then implementation is straightforward, but the system cannot detect both HTTP and HTTPS captive portals
Solution Approach 1:
The detection system achieves universality by implementing both HTTP ping requests and HTTPS query requests with mutual authentication within the same system. This multi-functional approach enables the system to detect both HTTP and HTTPS captive portals, as well as distinguish between them, while maintaining implementation simplicity through a unified detection framework that handles both protocols.
Data Source
AI summary
A method and system for detecting captive portals includes a two phase captive portal detection process whereby an initial HTTP ping request is sent from the endpoint captive portal detection application on an end user computing system to an Internet accessible web server. The Internet accessible web server is expected to return an initial response token to the endpoint captive portal detection application in response to the initial HTTP ping request and if the expected initial response token is received, an initial HTTPS query request is then sent together with the returned initial response token that requires server/client mutual authentication. If mutual authentication is accomplished, then it is determined that the user is not in a captive portal. Follow up HTTP ping requests are then periodically generated by the endpoint captive portal detection application and if the responses to the follow up HTTP ping requests do not change, i.e., the token does not change, no new HTTPS query request is sent.