The Protocol Gap in Captive Portals
In this series, we would like to highlight the issues that arise in communication between hotspots/captive portals and end devices. A layperson might assume that manufacturers of network hardware and operating systems addressed this problem long ago and solved it cleanly with a network protocol, but unfortunately that is a misconception. There is a major gap in the protocol landscape, and the solutions currently in use are better described as workarounds—and not infrequently even as dirty hacks.
The Protocol Gap
At present, there is no network protocol that a captive portal can use to communicate with the client. The goal is to convey simple information to the end device, such as that a login is required before this network can be used. In the enterprise environment, 802.1x can take on this role, but this technology is generally limited to corporate use because, for one thing, it only covers login via username and password and none of the many other scenarios. In addition, many end users—such as hotel guests—are overwhelmed by a WPA2 Enterprise login, and at that point, online assistance is not possible either.
The Redirect Problem
Typically, a WiFi user must authenticate, buy a ticket, or simply agree to the terms of use in order to use the network. There are many variants, but that is beside the point—the problem is always the same. The user wants to reach the login page conveniently, without having to perform any special actions on their device. Because there is no standard for this process, captive portals have to perform various, sometimes questionable manipulations of network traffic to provide this functionality.
A long time ago, users still had to manually open the web browser and visit any unencrypted website (via HTTP); then the captive portal could conveniently redirect the browser to the login page via HTTP response code 302.
The number of encrypted websites using TLS is increasing and has been for a long time—recently, even sharply. While this is a good thing for the internet and end users, it prevents redirection to the login page. If a guest’s browser opens an encrypted page via HTTPS, it cannot be redirected without warnings. In the early days, this redirection was still done anyway, hoping that the guest would simply click away the SSL/TLS certificate warning. By now, most people—rightly—consider it grossly negligent to train laypeople to behave in a way that could become a serious problem for online banking and online shops.
In recent years, additional standards have been implemented to complement TLS and make it even more secure (or, in fact, truly secure), including
- HSTS (HTTP Strict Transport Security)
- and HPKP (HTTP Persistent Key Pinning).
HSTS is a trust-on-first-use extension that tells the browser that this website should only be accessed via TLS, so TLS stripping cannot be performed (as is unfortunately still the case with STARTTLS for email). HPKP, also trust-on-first-use, provides the browser with a hash value of the certificate, so that no other certificate is permitted—even if it would be valid (e.g., issued by an enterprise firewall including an installed CA on the client).
These two extensions have the practical effect that the guest can no longer bypass a certificate warning. Without a doubt, this is a good thing for trust in encrypted connections. For these reasons, IACBOX has not redirected TLS connections to the landing page for quite some time.
The Workarounds
For several years now, most devices in a guest WiFi network have been mobile devices—so a solution was needed. The two major vendors, Google and Apple, developed a similar workaround. An unencrypted HTTP request is made to a vendor-specific page and, if a redirect (HTTP 302) occurs, a hotspot system is detected and a minimalist browser is opened. This bypasses the problem with encrypted browser start pages and also has the advantage that the user does not have to open the browser manually to see the login page. However, this feature also introduces a privacy issue—but that is another story.
Not only mobile devices, but also operating systems such as Windows from version 8 onwards, or browsers such as current versions of Firefox and Google Chrome, perform this so-called connectivity check.
On the one hand, the connectivity check was a lifesaver for the difficult relationship between users and captive portals, but the different approaches and, in some cases, undocumented internal states still make the process fragile.
WISPr
Then there is WISPr, which is actually intended to facilitate roaming between 3/4G and WiFi networks. Among other things, this protocol defines an XML interface over HTTPS through which the end device receives the information that it is behind a captive portal and what the URL for the landing page is. For Apple devices, this response is required for the captive browser to open. Android and Windows from version 8 onwards also support WISPr, but their connectivity check works without it as well. However, WISPr does not solve the underlying problem either, because the end device must already make this request to the captive portal (its gateway).
A real solution is needed
A glimmer of hope on the horizon is the new IETF working group capport [https://datatracker.ietf.org/wg/capport/about/], which is working on new protocols, extensions to existing protocols, and interfaces that allow end devices to communicate with a captive portal in a standardized way. In this blog series, we will take a closer look at the current developments of this working group.
A small but important step has already been taken—the RFC 7710 standard [https://tools.ietf.orf/html/rfc7710], which defines a DHCP option for IPv4 and IPv6 that sends a URL for a landing page to the client. IACBOX has supported this option since early 2016, but unfortunately we have not yet found any devices that actually honor it.
This also reveals the real problem—without implementation of the standards by operating system vendors, nothing will change in the current situation.
Read the second part of the series here: Current status of the capport RFC.