Captive Portal
A captive portal initiates a HTTP client to a network to a specific web page before it can normally connect to the Internet. So usually an authentication or acceptance of the Terms is enforced, or allows charging of usage.
Background
The technique is implemented by intercepting all transmitted packets, regardless of IP address or port until the user opens a web browser and invokes any web page. Then the portal page is displayed in the authentication specification of payment methods or the Terms of Use are displayed. Captive portals are mostly used in Wi- Fi hot spots to control and account access.
The portal page itself must be either stored in the gateway or access to the Web server from which the site is based, must be activated ( Walled Garden ) in order to bypass the diversion. It is also possible to disable the deflections of the portal for defined MAC addresses in order to particular sites grant free access.
Implementation
In order to implement a captive portal, there are several possibilities. These can be implemented both in software and in hardware.
Redirection via HTTP
If a non- authorized client requests a Web page, the DNA is extracted and the IP resolved as usual. The browser then sends an HTTP request to that IP address. This request is intercepted by a firewall and sent to the redirection server. This answers the request with a normal HTTP response which contains the HTTP status code 302 to redirect to the client on the captive portal page. For the client, this process is transparent, it must be assumed that the originally requested web page has sent this redirect.
IP redirection
The data stream can also be realized by IP forwarding on OSI layer 3. But this is not recommended because the content presented no longer corresponds to the URL.
Redirection via DNS
If a non- authorized client requests a Web page, the DNS is queried. The firewall ensures that only one DNS server is available, which is specified via DHCP from the hot-spot operators ( or, alternatively, all DNS requests on such a redirect ). The DNS server will report back to every request the IP address of the portal page as a result.
Limitations
On the filtering by IP or MAC address -based implementations can be easily bypassed by the network overheard the packet sniffer and found this, already activated IP and / or MAC addresses of other participants are subsequently imitated by the computer of the attacker. The necessary technical skills are not too high. However, captive portals of this style may have an entitlement to suggest a non-technical audience the payment of a small use fee. That may be the portal of a very small proportion of potential users overcome is accepted.
If the login page is encrypted by SSL, the password can not be intercepted. If it is - how often - is for one-time passwords, however, this protection is unnecessary, because the password after a single transmission is invalid anyway. In addition, no serious attacker will try the password system to compromise, but if he can just read along IP and MAC addresses, and these suffice him as the actual ticket. Furthermore, SSL causes problems with platforms that do not support this, eg some game consoles.
Secure Captive portals, however, must sign or encrypt, to be able to ensure that the computer or browser that has been entered from which the password, and the computer or browser, with which all other network traffic is directed to all network traffic digitally. Solutions based on a targeted SSL proxy server limit the usable services on the one who understand both the proxy server and the programs used by the user - specifically, this usually means the restriction on HTTP and HTTPS. The easy alternative to the effect of using an encrypted wireless network and every user to provide their own key available requires a more complex configuration using RADIUS and access points that support this as well. Much harder but weighs that setting up an encrypted wireless network on your computer too much for many casual users.