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 ?
When you want to create a public Wi-Fi, you probably want to authorize your users or at least make sure, that they accepted some terms of use. For this you need a webpage called captive portal, where your users can read the terms or at least confirm that they’ve read it. The network device however cannot push that website to the user, because in HTTP you cannot send a response if there wasn’t any request yet. When the user makes one, the access point intercepts it and if the user is not recognized, then they are redirected to the captive portal.
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 ; includeSubDomainsHow 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 are websites like 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.