iOS (and macOS?) use http://captive.apple.com/

Agreed - I always use example.com as well.

Also worth noting that example.net, while not listed on the IANA page, is also reserved.

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)

I have always used http://http.rip

I'm not sure how example.com is better than any other domain in a coffee shop setting. Any DNS lookup can be made to resolve to any arbitrary IP address, so it would not matter if a domain is lapsed or even real.

I have "HTTPS-Only Mode" on in FF, and it connects HTTPS to CoffeeShopWifi.com but not to http://neverssl.com

Most people won't have HTTPS-Only Mode on, and those that do probably understand the issue, but if FF changes settings in the future this could be a problem.

I believe http://wifi.yt (you there?) predates most of these.

Yeah, and neither seems to work for me on iOS for some reason.

Like right now, with a connection, it works as expected (loads page, shows security warning in address bar)

But if I don't have a connection, it seems like either the browser or lower level OS security features (ATS?) force the device to try https first, which of course hangs/fails.

A huge pain in general.

awfully similar :)

Huh, I don't even get a certificate error on https://coffeeshopwifi.com/ - and I got automatically upgraded (I guess due to https everywhere) haha

It's actually a moderate pain to set up something that doesn't answer on port 443 unless you want to host it yourself. I tried with http://wifi.help, but it's at Cloudflare and I don't know of a way to block port 443 without paying for their WAF.

httpforever.com is the one I use. https connection gets redirected to http to ensure that it gets captured.

DHCP Options would probably work. They're most often used to provide clients with a default gateway and DNS servers, but they're also sometimes used to autoconfigure APs and thin clients as well.

https://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Pro...

I think the proper solution for this is to just stop doing captive portals. They suck, they break easily, no one ever reads what they say, and while I'm not a lawyer I question their value from a litigation perspective.

There are some RFC7710 and 8910 come to mind.

And http://nevertls.com works too, so it's really dead simple to remember.

I use http://motherfuckingwebsite.com, because I'm usually in a swearing mood if I need to use it. I've also always wondered what non-technical folks do.

From reading the comments, this is for use in scenarios where you connect to a guest wifi network, but aren't automatically taken to their authentication page to get access to the internet.

By trying to connect to a http:// website instead of https://, the redirect will work, allowing you to authenticate your device and access the internet.

Sounds like someone needs to build neverssl-nevercached.com with a "Cache-Control: no-store" header

You now also end up in the situation where your browser has the google.com certificate pinned so even if the portal tries to serve up a self-signed certificate for google.com, the browser will still complain about something fishy going on. The most complete solution is for the browser to try to detect captive portals and load up a plain HTTP website for the portal to hijack.

I remember in public school, IT had a website blocker that was effectively was a captive portal that would just route you to a "BLOCKED" web page and only could handle blocking non-HTTPS domains. Many sites were already going HTTPS by senior year so it was trivial to go to https://facebook.com and have full access. Another possibility was using a cgi-proxy. The site blocker was a blacklist so I hosted my own cgi-proxy when the one commonly used got blacklisted.

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.