CNA (Captive Network Assistant): how phones find the login page

In short. The CNA (Captive Network Assistant) is the mechanism iPhone, Android and Windows use to tell whether you’re behind a captive portal and to open the login page in a dedicated mini-browser. It was born out of necessity: with the mass move to HTTPS, the old hotspots that hijacked the browser had stopped working.

What is the CNA?

It’s a small agent in the phone’s (or PC’s) operating system that, as soon as you join a Wi-Fi network, checks whether there really is internet or whether you’re “captive” behind a login page. It does so by requesting a known page over HTTP; if the answer isn’t the expected one, it concludes there’s a captive portal and opens the login page in a limited browser. Apple calls it the Captive Network Assistant, but Android, Windows and the other platforms have the same mechanism under different names.

Why did a “normal” hotspot stop working?

This is why the CNA exists. Once, 99% of websites — Google included — were HTTP. The hotspot could intercept any page the browser requested and reply with a redirect to the login page: it always worked, because HTTP is not protected and can be hijacked.

With the massive arrival of HTTPS that broke. An HTTPS request cannot be hijacked: the TLS protocol is designed precisely to notice if someone gets in the middle. If the hotspot tries to answer in place of the site, the browser receives a certificate that doesn’t match and reads it for what it is — a man-in-the-middle attack — and blocks everything with a certificate error, instead of showing the login page. In practice: if the first site you open is HTTPS (and today almost all of them are), the old redirect produces an error, not the portal.

⚠️ Warning: the certificate error is not a bug: it’s exactly the behavior HTTPS is meant to have. It exists to stop anyone — the hotspot included — from slipping between you and the site. That’s why a captive portal can hijack only HTTP, never HTTPS.

How does the CNA tell whether you’re behind a captive portal?

By making an HTTP probe to one of its vendor’s addresses and checking the answer:

Apple     -> http://captive.apple.com/hotspot-detect.html   (expects a "Success" page)
Android   -> http://connectivitycheck.gstatic.com/generate_204  (expects a 204 No Content)
Windows   -> http://www.msftconnecttest.com/connecttest.txt  (expects a precise text)

If the probe returns the expected answer, the phone concludes “there’s internet” and shows nothing. If instead the hotspot intercepts it and replies with a redirect (an HTTP 302 to the login page), the phone knows it’s “captive” and fires the CNA. This is why the probe is deliberately HTTP: it must be hijackable.

What is the “limited browser”?

It’s a system mini-browser (a restricted WebView) that the phone opens only for the captive portal page. It’s “limited” on purpose: no full session, no extensions, it closes as soon as you’ve authenticated. It lets you log in safely without opening your real browser on a network you don’t yet trust.

What does it mean for whoever configures a hotspot?

Two practical — and important — consequences:

• The captive works because the CNA probes over HTTP and gets the redirect. Never whitelist the probe addresses (e.g. captive.apple.com) before login: if the probe reaches the real server, the phone thinks it’s online and won’t show the portal.
• The login page can be served over HTTPS (recommended), but it needs a valid certificate: with a self-signed/wrong certificate the CNA’s mini-browser refuses it and the portal doesn’t appear. It’s the number-one cause of portals that “don’t start” on iPhone.

How RouterOS handles all of this — the interception, DHCP option 114, the certificate — is in the howto Captive portal and iPhone: the DHCP option 114.