Sometimes you connect to the Wi-Fi, but no website wants to load. You try to enter different website addresses, but all you get in the result is a blank page. It seems like it’s stuck in some void … and then for some website it miraculously did work and you were redirected to a page with some terms to accept, one click and the Internet is ours.
But why … ? What just happened ?
The problem appears when the user’s request was made via HTTPS. There is not really any way to intercept such request and respond to the user with a redirect, because the request was encrypted and the client expects the encrypted response.
But even if we are aware of this and we try to explicitly define the scheme to HTTP, we will still see a blank page. This is a result of the HTTP Strict Transport Security. It is a mechanism, which makes sure, that the website we intended to run over HTTPS is always run in that way. When the user enters a site for the first time, the server adds a
Strict-Transport-Security header to the response. It tells the browser to remember, that the content served under this domain should be accessed only via a secured connection, even if the user makes an explicit http request. Its value contains a
max-age directive with time in seconds for which that information should be kept by a browser and an optional directive
includeSubDomains which informs the browser, that it should apply this mechanism also to subdomains. The example header with its values looks like this:
Strict-Transport-Security: max-age=15768000 ; includeSubDomains
How it is mitigated when properly configured ? The solution is to let operating system make the first request to some previously defined endpoint, before the user makes one. If the received response has status code 200, that means that we are connected to the internet. If it has some unexpected status code, like a redirect, then the operating system should open a separate window (like CNA in Apple’s operating systems) and authorize the user there.
But what if it is not the case ? Sometimes due to configuration quirks or errors, those requests are passed through and the operating system and the browser can’t detect, that the captive portal should be displayed. Well, there is a website http://neverssl.com, which surely won’t be served over HTTPS. This way the request will be always made in a way the network device can handle.