A Captive Portal Is a Man-in-the-Middle You Run on Purpose

Everyone has met the captive portal: you join the coffee shop or airport wifi, try to load a page, and instead get a “sign in / accept the terms” screen. It feels like a small, slightly janky feature. Under the hood it’s something more interesting and more precarious — a deliberate man-in-the-middle. The network intercepts your traffic, pretends to be the site you asked for, and hands you its own page instead. Understanding that it’s interception, and interception that depends on things being insecure, explains both how it works and why it’s so reliably flaky.

How the interception actually works

Before you’ve authenticated, the network doesn’t let your packets out. But it can’t just drop them, or you’d see nothing and assume the wifi is broken. So it hijacks the first thing you try to do:

• You type a URL; your device asks for its address and opens a connection.
• The gateway intercepts that connection — often by answering DNS with its own address, or by transparently redirecting your web request — and responds as if it were the site you wanted.
• It sends back a redirect to the portal page. Your browser, believing it’s talking to the real site, follows it and shows you the login screen.
• You accept the terms or log in, the gateway flips your device from “blocked” to “allowed,” and now your real traffic flows.

That’s a textbook man-in-the-middle: a third party sits between you and your destination, impersonates the destination, and alters the response. The only difference from the malicious version is consent and intent — the network owns the path and is doing it to gate access, not to steal from you. It’s the same technique, pointed at a benign goal.

A captive portal is the one man-in-the-middle you’re supposed to trust. It works by doing exactly what you’d never want a hostile network to do.

It depends on your traffic being interceptable

Here’s the crux, and the reason for all the jank: this trick only works when the thing it intercepts is interceptable. The classic portal relies on you making an unencrypted request it can transparently rewrite, or on being able to spoof a DNS answer your device will accept. Both of those are assumptions about an insecure web — and the modern web is systematically removing them:

• HTTPS everywhere. If your browser tries a secure site first, the gateway can’t impersonate it — that’s the entire point of TLS. Instead of a tidy redirect, you get a certificate error, because the portal is, correctly, detected as an imposter. The security working as designed is what breaks the portal.
• HSTS. Sites that tell your browser “only ever talk to me securely” can’t be downgraded to an interceptable request at all, so the portal never gets its chance.
• Encrypted DNS. If your device resolves names over an encrypted channel the gateway can’t see or spoof, the DNS-hijack path stops working too.

Every one of those is a security win, and every one of them chips away at the captive portal’s foundation. That’s why portals feel worse over time, not better: they’re standing on ground the rest of the web is deliberately pulling out from under them.

Why the login page is so weird

This is also why the experience is so consistently awkward — the “open your browser to any non-secure page,” the special detection URLs, the sign-in screen that won’t pop up until you manually visit some plain-HTTP address. Those aren’t bugs; they’re workarounds for the shrinking set of traffic the portal is still allowed to intercept. Operating systems even ship dedicated, intentionally-insecure probe URLs specifically to give the captive portal something safe to hijack, because your real browsing is increasingly off-limits to it. The whole dance is a system fighting to keep interception working in a world designed to prevent it.

The transferable lesson: interception built on weakness is fragile

Step back from wifi and the pattern generalizes: any mechanism that works by exploiting a weakness — an unencrypted channel, a spoofable lookup, an unauthenticated assumption — is living on borrowed time, because those weaknesses are exactly what everyone else is working to close. It doesn’t matter that your use is benign. You’ve coupled your feature to the insecurity of the layer beneath you, and when that layer hardens, your feature degrades, whether you’re ready or not.

If you’re building something that depends on being able to see, redirect, or modify traffic that isn’t yours, that dependency is a liability with a clock on it. The durable designs work with encryption and authentication (explicit configuration, real credentials, cooperative protocols) rather than against them. The captive portal is a great teacher here precisely because it’s so familiar and so visibly fraying: a clever hack on an insecure assumption, watching that assumption disappear. If you’ve wrangled captive portals — building them or just cursing them in a hotel — I’d love to compare notes.