Difference between revisions of "Captive portal"
m |
m |
||
| Line 38: | Line 38: | ||
Since HTTPS connections cannot be seamlessly redirected , a web browser that only attempts to access secure websites before being authorized by the captive portal will see those attempts fail without explanation. This is a good example of why HTTPS only web browsers are problematic. | Since HTTPS connections cannot be seamlessly redirected , a web browser that only attempts to access secure websites before being authorized by the captive portal will see those attempts fail without explanation. This is a good example of why HTTPS only web browsers are problematic. | ||
| + | |||
| + | SQUID PROXY: | ||
| + | |||
| + | Older network engineers might refer to a Captive Portal (a contemporary term) as something else, such as a Squid Proxy. This is because earlier examples were often created using Squid and Apache. Squid is a caching and forwarding HTTP web proxy. Squid Access Control Lists are one way to access to a network or Internet from a network. | ||
| + | |||
| + | Components of a typical Captive Portal | ||
| + | # access controller | ||
| + | # radius server (only for user authentication installations) | ||
| + | # radius client and framework (depending on radius) | ||
| + | # backend database (only for user authentication, and/or possibly logging facility) | ||
| + | # web server and possibly web application server or proxy server | ||
| + | |||
| + | When a client connects to an open WIFI network, an IP address is assigned and the web browser request is intercepted then redirected to the captive portal page. On linux iptable rules might be used to restrict access so that only a web client can access only the captive portal page no matter what host or IP it is attempting to contact. | ||
| + | |||
| + | From there other components get involved, such as password authentication via radius or by a user simply agreeing to terms and conditions thus eliminating the need for radius and a user database. | ||
Revision as of 21:36, 11 January 2024
A captive portal describes the webpage that asks for authentication, payment, and/or acceptance of terms of the agreement in order to access the Internet via a public provided WiFi hotspot you might find at coffee shops, airports, business centers, or hotel lobbies. You may simply be asked to accept their terms or you might be prompted for payment.
The use of Captive Portals relates to WiFi aka Wireless Internet primarily and at publicly provided hotspots.
EXPANDED:
A captive portal is a web page or set of web pages that are presented to users when they first connect to a network. It is a common method used by public Wi-Fi hotspots, hotels, airports, and other venues to control access to the internet and provide additional services or information to users.
The typical workflow of a captive portal involves the following steps:
User Connects to the Network:
When a user connects to a Wi-Fi network or any other network with a captive portal, they are initially granted limited access. Redirect to Captive Portal Page:
When the user opens a web browser and tries to access any website, the traffic is intercepted, and they are automatically redirected to a captive portal page. Authentication and Authorization:
The captive portal page often requires users to log in or accept terms and conditions. Some captive portals may use authentication methods such as entering a username and password or accepting terms of use. Full Access Granted:
Once the user completes the required actions or authentication, the captive portal grants full internet access, and the user can browse the web as usual. Captive portals serve several purposes, including:
Access Control: They allow administrators to control who can access the network by requiring authentication or acceptance of terms.
Usage Monitoring: Captive portals can be used to monitor and track user activity on the network.
Advertisement and Information: Organizations often use captive portals to display information, advertisements, or promotions to users during the authentication process.
Security Measures: By requiring authentication, captive portals add an additional layer of security to public networks.
It's worth noting that while captive portals are commonly used in public Wi-Fi settings, they can also be implemented in wired networks or any network where access control and user authentication are desired.
WEB BROWSER LIMITATION:
Captive portals often require the use of a web browser; users who first use an email client or other application that relies on the Internet may find the connection not working without explanation, and will then need to open a web browser to validate. This may be problematic for users who do not have any web browser installed on their operating system. It is however sometimes possible to use email and other facilities that do not rely on DNS.
Since HTTPS connections cannot be seamlessly redirected , a web browser that only attempts to access secure websites before being authorized by the captive portal will see those attempts fail without explanation. This is a good example of why HTTPS only web browsers are problematic.
SQUID PROXY:
Older network engineers might refer to a Captive Portal (a contemporary term) as something else, such as a Squid Proxy. This is because earlier examples were often created using Squid and Apache. Squid is a caching and forwarding HTTP web proxy. Squid Access Control Lists are one way to access to a network or Internet from a network.
Components of a typical Captive Portal
- access controller
- radius server (only for user authentication installations)
- radius client and framework (depending on radius)
- backend database (only for user authentication, and/or possibly logging facility)
- web server and possibly web application server or proxy server
When a client connects to an open WIFI network, an IP address is assigned and the web browser request is intercepted then redirected to the captive portal page. On linux iptable rules might be used to restrict access so that only a web client can access only the captive portal page no matter what host or IP it is attempting to contact.
From there other components get involved, such as password authentication via radius or by a user simply agreeing to terms and conditions thus eliminating the need for radius and a user database.
