Captive portal

from Wikipedia, the free encyclopedia

A captive portal , dt. About inevitable portal of English captive trapped ' , is a device commonly used in public, wireless is used networks to access by devices such as laptop computers or smart phone to the network behind it, or the Internet to the consent of the user to attach certain rules of use. In addition, the network provider can link access to a specific user account in order to bill connection costs.

Captive portals are used primarily in areas with frequently changing participants. These can be guest WiFi networks in hotels, public WiFi hotspots in cities or WiFi networks in means of transport such as trains, buses or planes.

Example page of a captive portal

function

With a captive portal, an end device can first connect to the mostly unencrypted WLAN network that can be accessed without access data. In this state, however, the captive portal still blocks any further access to the underlying network or Internet, the device is more or less trapped in this area, from which the name is derived.

In this state, requests are usually redirected from the web browser via HTTP to a web page on the captive portal, where the user must give his consent to certain rules and enter further information such as user ID and password for billing. Only after approval and, if necessary, positive authentication, is the release for network or internet access for this terminal via the captive portal. Depending on the configuration of the network, access is then not limited to HTTP, but also includes, for example, various other protocols such as IMAP for querying emails or VPN connections.

Since the activation is based on the IP level and different protocols are often permitted, activated end devices are assigned to the respective MAC address . Depending on the configuration of the network, the releases can be limited in time or certain MAC addresses can also have fixed free access.

implementation

Although captive portals have existed in the function since the early 2000s, there was no standard for them until mid-2015. The solutions are therefore mostly proprietary procedures which are based in principle on diversions and a man-in-the-middle attack and often have the level of a workaround . Due to the increasing use of procedures which make man-in-the-middle attacks more difficult, these solutions are fraught with various practical problems.

Since the end of 2015, an RFC standard has been available with RFC 7710 , which describes the implementation and basis of captive portals for all manufacturers. The DHCP protocol used for network configuration of the end device is expanded by two entries, one of which indicates the existence of a captive portal to the end device and still denies Internet access. The second gives him the URL of the captive portal, which can then be accessed via IPv4 or IPv6 . This eliminates the previously problematic redirection of network access.

In the years before this RFC 7710 , various procedures were used to first redirect the network traffic of a new client to the captive portal without the end device being notified of this or being aware of it. These intervened at various points described below.

Redirection via HTTP

If an unauthorized device requests any website, the DNS is queried and the IP address resolved as usual. The browser then sends an HTTP - request to this IP address. This request is intercepted by a firewall and sent to its own redirection server. This answers the request with an HTTP response , which contains the status code 302: Found , in order to redirect to the captive portal page. This process is transparent for the end device; it must assume that the originally requested website sent this redirect, which is not the case here. A modified method is to use the status code 511: Network Authentication Required , which is not understood by all web browsers.

This type of redirection only works with unencrypted HTTP. In addition, there is the fact that the use of HTTP is steadily decreasing in favor of HTTPS .

Problems with HTTPS

In the case of HTTPS encrypted using Transport Layer Security (TLS), this redirection results in an error message because the certificate used by the captive portal is not valid for the HTTPS address originally called by the end device. In principle, the redirection method used by captive portals corresponds to a man-in-the-middle attack. By signing the TLS certificates used by a trustworthy body, the end device can recognize this manipulation of the redirection and display a corresponding warning to the user or prevent access to the portal page entirely.

But even if the user enters an HTTP URL manually, additional protection methods such as HTTP Strict Transport Security (HSTS) can lead to problems: With HSTS, a web server declares no access with unencrypted HTTP for a certain period of time, for example one year to allow this domain. If the corresponding domain which uses HSTS has already been called up by the end device before, the use of HTTP for this address on the end device is prevented and the captive portal cannot be displayed. Another hurdle for captive portals with redirection arises when using HTTP Public Key Pinning (HPKP).

Redirection via DNS

If an unauthorized terminal requests a website, the DNS is queried. The firewall ensures that only one DNS server can be reached that is specified by the hotspot operator via DHCP or, alternatively, redirects all DNS requests to such a DNS server. The DNS server will report back the IP address of the portal page as a result of every request. However, this method is prevented by the Domain Name System Security Extensions (DNSSEC), as the certificate is not valid and this diversion is recognized as a man-in-the-middle attack.

IP redirection

The data stream can also be implemented through IP redirection on OSI layer 3 , using a redirect message according to RFC 792 . Since the displayed content no longer corresponds to the URL, this method is recognized by TLS and DNSSEC as a man-in-the-middle attack.

recognition

Without using the standardized procedure in RFC 7710, there is no way for the end device to detect the presence of a captive portal. Operating system manufacturers therefore established their own servers under their control, which they allow end devices to access as soon as they have newly registered in a network. The success of this access confirms that the operating system has no captive portal in the network of the terminal device. These routine accesses represent a data protection problem, the manufacturer can save the IP addresses of the users and evaluate them if necessary.

Some of these external server addresses used for portal recognition are listed below:

Windows

In Microsoft Windows there is the Network Connectivity Status Indicator ( NCSI ), which checks the Internet connection and detects captive portals. The corresponding settings are stored in the Windows registry under HKLM:\SYSTEM\CurrentControlSet\Services\NlaSvc\Parameters\Internet.

In Windows 10, the DNS domain is dns.msftncsi.comqueried and the IPv4 address 131.107.255.255and IPv6 address are fd3e:4f5a:5b81::1expected. Then a DNS query is www.msftncsi.comcarried out and the resource http://www.microsoftconnecttest.com:80/connecttest.txt(to test the IPv4 connection) and http://ipv6.microsoftconnecttest.com:80/connecttest.txt(to test the IPv6 connection) are queried. These resources must consist of the character string Microsoft NCSI.

In older Windows versions, the resource is http://www.msftncsi.com:80/ncsi.txtqueried.

Android

In the case of Android, there is the captive portal check .

Web browser and mail clients

Web browsers such as Mozilla Firefox , Mozilla Thunderbird and SeaMonkey use the URL http://detectportal.firefox.com:80/success.txt. The detection of captive portals can be switched off about:configby setting the key network.captive-portal-service.enabledto false.

macOS and iOS

In the same scheme, Apple operates a server under the URL http://captive.apple.comthat end devices attempt to access when entering networks; if this call a simple HTML -Dokument with the word "Success" ( English for Success contains) as a single text, then closes the terminal from the fact that it has internet access, otherwise a browser window is opened to allow the user the website from the captive portal. A way to deactivate this function is not known and is not provided for under iOS .

restrictions

Implementations based on filtering by IP or MAC address can be bypassed relatively easily on the WLAN side by eavesdropping on the network with a packet sniffer and subsequently using the computer to identify the already unlocked IP and / or MAC addresses of other participants imitated by the attacker.

Since captive portals are usually accessed via unencrypted WLAN, these WLAN connections in the vicinity can easily be eavesdropped. Connections in an unencrypted WLAN should therefore only be made via secure, encrypted connections such as HTTPS or using VPN to an external VPN server.

Individual evidence

  1. ↑ a b Hanno Böck: Captive Portals: A workaround that will soon no longer work. In: Golem.de. February 8, 2016, accessed May 26, 2017 .
  2. ↑ Ross Butler: Solving the Captive Portal Problem on iOS ( en ) medium.com. November 16, 2018. Retrieved July 18, 2019.