I like the straightforward explanation this site provides. That said, I tend to use http://example.com to trigger captive portals because it's an IANA reserved domain [1] that other people can't register.
This gives me confidence to browse to it without fear that the domain could lapse in the future and get taken over (e.g. in a watering hole attack).
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)
Simple answer: We can make it connect just fine, but we either need to give up on value extraction (i.e. "pay a fee to connect"), or on security.
Captive WiFi fundamentally relies on intercepting all Internet traffic to send you to the captive page. That's only possible with fake certificates, because you want to provide a response on behalf of the website the user wanted to go to. This wasn't originally part of "how the Internet works", because "pay as you go" just wasn't considered during the design.
But... we've solved that problem. rfc8910 does specify how you can use DHCP to work around that. Except, it doesn't work for legacy clients. So those will still be supported in existing setups anyways.
And since everybody's supporting legacy setups, the incentive for any single provider to even implement the new method is about zero.
The whole mess is a result of replacing the engine while flying the airplane, in an environment optimized for rent seeking behaviors. We can do the right thing, but we choose (collectively) not to spend the money.
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.
It's a lot easier to simply register a domain like coffeeshopwifi.com if/when the owner abandons it and wait for the requests to pour in, than it would be to find the specific coffeeshop that your target frequents and then compromise their DNS servers.
My personal website (the top level index) is effectively a brochure with nothing that could be used for authenticating (there's a very broken javascript crypto app on it but that's just a toy and is clearly marked as such.) I always just use that.
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.
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.
I don't understand how this (and other similar sites mentioned) work. What is going on with the network that makes visiting a non-SSL site make it work? Anyone care to offer an explanation or have a link to one?
Basically, because the captive portal tries to redirect the browser to a page for authentication, but the browser won't let this through on a https connection for security reasons.
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.
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.
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.
On the other hand, it's possible to reach https://coffeeshopwifi.com and (with a cloudfront certificate error) https://neverssl.com which makes me wonder if something in whatever I'm using is trying to upgrade to HTTPS when I fail to reach them.
I think you're misunderstanding the GP. The HTTPS connection will not be redirected when you are behind a captive portal, you'll receive an invalid certificate error (when the captive portal tries to serve itself at that address) or the website will simply not respond. Only if the HTTPS response is cached in your browser would the redirection work behind a captive portal.
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.
I used to use purple.com for this. Anyone who used it back in the golden age of the internet knows it was ideal for such purposes. It even had that squirrel game. Anyway after many many years of serving that masterpiece over plain http the guy sold the domain to some fucking matress company who insists on SSL.
It seems that HTTPS is available which made my browser (in HTTPS-only mode) connect to the HTTPS site. I suppose that if HTTPS was blocked it would allow me to fall back to HTTP but it gives a much less clear error than something like http://neverssl.com/ does.
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.
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.
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.
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.
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.
84 comments
[ 825 ms ] story [ 1479 ms ] threadThis gives me confidence to browse to it without fear that the domain could lapse in the future and get taken over (e.g. in a watering hole attack).
[1]: https://www.iana.org/domains/reserved
Also worth noting that example.net, while not listed on the IANA page, is also reserved.
https://datatracker.ietf.org/doc/html/rfc6761#section-6.5
> The domains "example.", "example.com.", "example.net.", "example.org." [...]
Great for low bandwidth tests Just displays clean “success”
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)
Captive WiFi fundamentally relies on intercepting all Internet traffic to send you to the captive page. That's only possible with fake certificates, because you want to provide a response on behalf of the website the user wanted to go to. This wasn't originally part of "how the Internet works", because "pay as you go" just wasn't considered during the design.
But... we've solved that problem. rfc8910 does specify how you can use DHCP to work around that. Except, it doesn't work for legacy clients. So those will still be supported in existing setups anyways.
And since everybody's supporting legacy setups, the incentive for any single provider to even implement the new method is about zero.
The whole mess is a result of replacing the engine while flying the airplane, in an environment optimized for rent seeking behaviors. We can do the right thing, but we choose (collectively) not to spend the money.
If I go to a coffee shop, do any packets even have to go to coffeeshopwifi.com or example.com at all?
1. DHCP happens.
2. I type http://example.com, but I get 'Please click AGREE etc. for WiFi'. So far, this should all be internal to the local network.
3. I click on AGREE, but my browser actually goes to philzcoffee.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.
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.
https://en.wikipedia.org/wiki/Captive_portal#Require_Web_Bro...
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.
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 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.
On the other hand, it's possible to reach https://coffeeshopwifi.com and (with a cloudfront certificate error) https://neverssl.com which makes me wonder if something in whatever I'm using is trying to upgrade to HTTPS when I fail to reach them.
Most sites will send a redirect to HTTPS, which CoffeeShopWifi does not.
So I decided it's safe to make a cert and support HTTPS.
They could stop serving port 443. That would prevent any extensions from automatically upgrading.
I always go to http://paulgraham.com when I need to connect to guest WiFi for the exact same reason..
Does any such standard feature already exist?
https://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Pro...
Ironically, if CoffeeShopWifi.com works successfully, the users won't see it.
Great work!