The protocol gap of Captive Portals

In this blog series we want to show the problems end user devices like smartphones have with Captive Portals as the detection and the communication with them is not standardized. A layman may think that manufacturers of network hardware and operation systems have solved this task a long time ago by defining a network protocol, but that’s not the case. There’s a big gap in the protocol landscape and the current available solutions are workarounds and sometimes better called dirty hacks.

The protocol gap

Currently there exists no network protocol that allows a standardized communication between a Captive Portal and the end user devices. It should be possible for the device to do simple things, like that the user has to authenticate before the network can be accessed. In enterprises this part can be fulfilled by 802.1x, but this technology can only be used in corporate networks, because it allows only certificates or a username plus password authentication, but none of the many others needed by Captive Portals. Many end users like guests in a hotel are completely unable to cope with a WPA2-Enterprise login asking for too many details. Also there’s no help possible in such a login form.

The redirect problem

To access a network, a WiFi user has to authenticate with username and password, buy a ticket or just accept the terms of service. There are plenty of different variations of login types, but in the end the problem is always the same. The user wants to get redirected to the login page without the need of taking action manually. Because there is no standard protocol, Capitve Portals use partly questionable manipulations of network traffic to achieve this functionality.

A long time ago users needed to open their web-browser manually and open an unencrypted (HTTP) website, so that the Capitve Portal could redirect them with an HTTP 302 response to the login page.

The number of encrypted websites via TLS is increasing since a long time and the last 2 years dramatically, because of the Let’s Encrypt certificate authority. This is great news for Internet users, but it avoids redirecting a browser to the login page. If a browser calls an encrypted website over HTTPS it can’t get redirected without a certificate warning. In the wild days we did such redirects hoping the guest would ignore the SSL/TLS certificate warning. This was always a bad idea and nobody should learn ordinary people such a behaviour, what would have dramatic consequenses on real websites.

Over the last years TLS got optional extensions which makes it more secure like

• HSTS (HTTP Strict Transport Security)
• and HPKP (HTTP Persistent Key Pinning).

HSTS is a trust-on-first-use extension, which tells the browser that it should access this website only via TLS to avoid TLS-striping (which is sadly still possible when sending emails with SMTP and STARTTLS).
HPKP, also a trust-on-first-use extension, tells the browser to check the hash checksum of the certificate, so no other certificate is allowed even if it would be valid (like issued by an enterprise firewall, having the CA installed on the client.)

This two extensions have the practical effect, that a guest can’t ignore a certificate warning. Doubtless this is a good thing for the trust in encrypted connections. Because of all that our IACBOX does not redirect TLS connections to the login page since many years.

The workarounds

For many years now the majority of devices in a guest WiFi are mobile devices so a solution was needed for this problem. Both big players – Google and Apple – came up with a similar workaround. They do an unencrypted HTTP call to a vendor specific server and if they get anything else than an expected response (like a redirect) a minimalistic browser – the so called Captive Browser – is opened. So the issue with encrypted webpages is bypassed and even better no browser has to be opened manually. This feature also brings a huge privacy issue with it, but that’s another story.

Not only mobile devices, but also operating systems like Windows starting with version 8 or current browser like Firefox and Google Chrome do this kind of connectivity-check.

This connectivity-check came to rescue the difficult relationship of end user and Captive Portals, but the different solutions and undocumentated internal states of client devices make this process fragile.

WISPr

Another protocol in this area is WISPr which was designed to allow roaming between 3/4G and WiFi networks. This protocol also defines a XML interface over HTTPS by which the end user device learns that it’s behind a Captive Portal and the URL of the login page. This response is needed for Apple devices to open their Capitve Browser. Android and Windows 8 and higher would support that too, but the connectivity check is enough to open their Captive Browser. But WISPr does not solve the main problem as the end user device has to call the Captive Portal.

We need a real solution

A glimmer of hope is the IETF working group capport, which is working on new protocols, extensions of present protocols and APIs to allow a standardized way of communication and captive portal detection. In this blog series we want to have a closer look on the current developments of this working group.

A small but important step was already taken – RFC-7710, which defines a DHCP-Option for IPv4 and IPv6 that sends the URL of the login page to the end user device and so tells it that it’s behind a Captive Portal. The IACBOX supports this option since 2016, but we haven’t seen a device out there, that actually uses it.

This shows the main problem here – without the support of major mobile OSes – nothing will change the current situation.

Here’s the second blog post Current state of capport RFC.