Skip to content

Captive Portals

Jump to bottom
wififreak edited this page Feb 8, 2016 · 16 revisions

We held a Bar BoF at IETF92, a BoF at IETF93, and have a mailing list -- please join!

Captive Portals are a perennial source of annoyance on the Internet.

Current practice around them is fairly ad hoc; therefore, a first step at improving the situation would be to document current practice, with an eye towards encouraging alignment in behaviour.

Beyond that, there are a few interesting problems to solve, including:

  • False Positives - some networks don't use a Web browser interface to log in; e.g., they require a VPN to access the network.
  • False Negatives - because so many different heuristics are used, it's common for an OS or browser to think it's on an open network, when in fact there is a captive portal. Captive portals may also purposefully attempt to fool OS or users into thinking an open network is present.
  • Longevity - often, it's necessary to repeatedly log into a captive portal. This could be because of limitations in the portal itself, or in the OS-side detection (some implementations don't send Cookies, for example).
  • Non-Internet Networks - some applications and/or networks don't assume Internet access, but captive portal detection often conflates "network access" with "Internet access". This causes people to do strange workarounds.
  • Confusion - badly deployed captive portals can confuse users as well as user agents (e.g., caches) about the identity of the site being accessed vs. the identity of the portal, e.g., when the portal cert doesn't match the requested site, or the wrong site icon gets cached.
  • DNS/DNSSEC - most portals respond with forged DNS answers, this confuses DNS resolvers and interoperates poorly with host-validating DNSSEC resolver/application.
  • TLS - portals that attempt to intercept TLS sessions (HTTPS, IMAPS, or other) can cause certificate error messages on clients, encouraging bad practice to click through such errors.
  • Notifications - some networks use the same mechanisms as captive portals to notify users of account status, network downtime, emergency alerts, etc.
  • Unexpected Configuration - some captive portals rely upon DNS interception to direct users to the portal; however, not only does this cause authority and caching problems, it also doesn't work when the user has configured their own DNS server in preference to DHCP (e.g., 8.8.8.8).

Stakeholders in this discussion include:

  • Operating System vendors (desktop and mobile) - captive portal detection / handling is most often done here
  • Browser vendors - sometimes it happens here too
  • Captive Portal vendors
  • Network operators

Observed Behaviors

  • forcing user to maintain an open browser window. This is a simple way to prevent stealing a user's connection (by an attacker sending a disassociate frame to the victim and duplicating the victim's MAC address). This has negative side effect for non-split tunnel VPNs, or of course if the user accidentally shuts down their browser. Note: this same technique was previously also used by EDUROAM, but EDUROAM has since switched to using 802.1x.
  • expiring authorization, where the user needs to interact again with the portal after NNN minutes.

Reasons for Captive Portals

There are four high-level reasons for captive portals:

  1. Lawyers (e.g., T&C's)
  2. Credentials (e.g., credit card, room number)
  3. Advertising (e.g., especially wanting a full-fledged web browser with cookies for Facebook 'like', display Flash video)
  4. Assistance (e.g., intercepting HTTP to display "your Internet connection is down" or "your host has malware")
  5. Placing users in specific VLANs (802.1x is not a solution at all cause not all of the equipment speaks that)

References

NOTE: All contributions are made under these terms.

Clone this wiki locally