How Captive Wi-Fi Networks Authentication Screen Display Works

Wi-Fi spots that require this kind of login are configured to intercept requests and force them to redirect to the login screen if they are not logged in and visit the appropriate website (for example, apple.com.

Using this behavior, iOS automatically determines whether a Wi-Fi spot requires login by sending a test HTTP request to Apple's server when it connects to an access point.

In other words, if Apple's server data returns as expected, it will not need authentication and will do anything, but if it returns different data due to redirect, it will be considered a login screen and pop up the page.

Note: http://arubanetworks.com/wp-content/uploads/Amigopod-CNA-bypass-AppNote.pdf

How does this work?

Web authentication is not standardized, so each manufacturer has a different implementation, but Cisco equipment, for example, has description as follows:

• The user opens a web browser and enters a URL such as http://www.cisco.com. The client sends a DNS request for this URL to obtain the destination IP. The WLC bypasses the DNS request to the DNS server and the DNS server returns a DNS response with the IP address of the destination http://www.cisco.com. This response is forwarded to the wireless client.

• The client then attempts to initiate a TCP connection using the destination IP address. TCP SYN packets destined for the IP address of www.google.com are sent.

• The WLC has rules configured for the client, so it can act as a proxy for www.google.com. The WLC sends a TCP SYN-ACK packet to the client sourced from the IP address of www.google.com. The client returns a TCP ACK packet to complete the 3-way TCP handshake, and the TCP connection is fully established.

• The client sends an HTTP GET packet with a destination of www.google.com. The WLC intercepts the packet and sends it for the redirect process. The HTTP application gateway prepares the HTML body and returns it in response to the HTTP GET requested by the client. This HTML directs the client to the default web page URL of the WLC (for example, http://login.html).

• The client closes the TCP connection to an IP address, for example, www.example.com

• Now the client is directed to http://1.1.1.1/login.html. In other words, the client attempts to open a TCP connection to the virtual IP address of the WLC. Sends TCP SYN packets for 1.1.1.1 to the WLC.

• The WLC responds with a TCP SYN-ACK, and the client returns the TCP ACK to the WLC to complete the handshake.

• The client sends an HTTP GET of /login.html to 1.1.1.1 to request a login page

• This request arrives at the web server of the WLC and is authorized, which responds with the default login page. The client receives the login page in the browser window, and the user can log in with the browser.

The user opens a web browser and enters a URL such as http://www.cisco.com. The client sends a DNS request for this URL to obtain the destination IP. The WLC bypasses the DNS request to the DNS server and the DNS server returns a DNS response with the IP address of the destination http://www.cisco.com. This response is forwarded to the wireless client.

The client then attempts to initiate a TCP connection using the destination IP address. TCP SYN packets destined for the IP address of www.google.com are sent.

The WLC can act as a proxy for www.google.com because it has rules configured for the client. The WLC sends a TCP SYN-ACK packet to the client sourced from the IP address of www.google.com. The client returns a TCP ACK packet to complete the three-way TCP handshake.

The client sends an HTTP GET packet with the destination www.google.com The WLC intercepts the packet and sends it for the redirect process. The HTTP application gateway prepares the HTML body and returns it in response to the HTTP GET requested by the client. This HTML directs the client to the default web page URL of the WLC (for example, http://login.html).

The client closes the TCP connection to an IP address, for example, www.example.com.

The client is now directed to http://1.1.1.1/login.html. In other words, the client attempts to open a TCP connection to the virtual IP address of the WLC. Sends TCP SYN packets for 1.1.1.1 to the WLC.

The WLC responds with a TCP SYN-ACK, and the client returns the TCP ACK to the WLC to complete the handshake.

The client sends an HTTP GET of /login.html to 1.1.1.1 to request a login page.

This request arrives at the WLC web server and is authorized, which responds with the default login page. The client receives the login page in the browser window, and the user can log in with the browser.

The client needs IP, so DHCP should be through.
A similar feature is available on wired network switches.