CoffeeShopWifi.com – An HTTP website for connecting to guest WiFi

The way a captive portal works is that the router at the coffee shop sees your browser's DNS request for `google.com` and instead of responding with the real IP address for Google it lies to your browser and returns an IP address which it controls.

If google.com were a non-HTTPS website then the router could simply then serve up any arbitrary content it wanted. i.e., it's own login/access form.

However, since google is an HTTPS website, the browser asks for an HTTPS certificate from this fake google.com and the router is unable to deliver a "real" certificate—this then breaks the "login flow" since instead of seeing a login form you see a "danger, do not continue, bad certificate" page.

I also use example.com, and unfortunately https://example.com/ also works, so if you just type "example.com" in to your browser, you are likely to hit the https:// URL first and get an error. And you have to type the entire "http://example.com" out, or your browser's auto-complete will go for "https://example" first. And even when it's http://, a captive portal may redirect you to an internal https:// site without a valid cert. And sometimes it caches so you need to remember to Shift+Reload.

The most infuriating thing about technology is how it reminds me how incompetent we are as a species. Here we are, the global collective of Information Technology workers, captains of industry, cutting-edge entrepreneurs, and white beard pros, and we cannot make a god damn computer just connect to a coffee shop's network without jumping through a bunch of annoying hoops, like the whole system was constructed by an intern on summer break. (No offense to interns)

Wifi with captive portals work by redirecting all of your outgoing traffic to a specific host - send a packet to 12.34.56.78 and it gets natted to 10.0.0.1 (or wherever the captive portal is).

When you connect to wifi, many (most?) OSes and/or browsers issue requests to http servers run by apple/firefox/microsoft. If the response is a portal, a popup is shown to allow the user to login (typically logging in would authorise the IP and/or mac address in a database and allow traffic to pass).

However some (poorly implemented) hotspots have specific holes to allow these pages to load without the portal (whitelisting the domains), then when you try to visit http://othersite.com, you will be redirected. Other portals may timeout after X minutes or X MB of use and require reauthentication, which the OS/browser may not detect.

As more and more sites use https, while the connection can be stopped (by stopping traffic going to port 443), a correctly behaving browser should ignore any traffic coming from a redirected https connection, as it wouldn't have a valid certificate - it's the whole point.

Many sites also implement headers which tell a browser "you will always connect to me on http", and the browser will refuse to downgrade to http://othersite.com, even if port 443 (https) is blocked but port 80 is open.

By visiting neverssl.com or similar sites, you can in those situations trigger the captive portal login page.

Seems like the DHCPACK message and/or router advertisement could/should have a reference to the URI that has policy/billing form that's required to utilize a gateway. That way we don't need a special magical service that expects to be redirected to the policy form. AFAICT each OS/distro seems to solve this their own way currently, with their own service.

Does any such standard feature already exist?

http://captive.apple.com/ is pretty much always up because it has some pretty strong infrastructure behind it since billions of Apple devices connect to it automatically. It's always my goto for captive portals.