I discovered there is a whole host of sysadmins out there attempting to actively subvert the iOS capitve portal detection. They try to figure out the domains used and whitelist them so iOS will think it is connected to a good network, but they redirect everything else which horribly breaks SSL connections. The whole thing is an arms race where Apple adds new domains to iOS but doesn't start using them until a certain date to evade the whitelist.
The stated reason for this stupidity? The mini-browser that pops up doesn't work with their stupid captive portal login or payment page. Fix the page? Nahhh, let's just fuck everyone's network connections instead. It caused an endless barrage of battery-draining network errors, eating the retry count and eventually causing POST requests to error out. The complete lack of respect for the users, internet protocol standards, etc was extremely evident.
We ultimately stuck a file with a specific phrase in a text file on the site, then when the app was having network trouble the code tries to fetch that file. If it gets an HTML response it marks it as in captive portal mode. IIRC it offered to take the user to safari and would open some non-HTTPS URL so the captive portal redirect could fire and let the user know.
I hope anyone trying to circumvent captive portal detection dies a very painful death, then gets revived, recovers through the miracle of modern medical technology, then dies another painful death.
There is no reason why Apple can't add captive portal detection at OS level like Android does.
> ...so iOS will think it is connected to a good network... The stated reason for this stupidity? The mini-browser that pops up doesn't work with their stupid captive portal login or payment page.
Any Android from 4 to 7. I guess it depends on how much the portal is trying to be smart.
Instead, there should be some non-routable, local-only special IPv4/IPv6 address that all captive portals are required to present.
No more DNS spoofing, no more page rewriting which breaks the web.
I feel like this "workaround" site is designed to draw attention to the problem at hand more than it is meant to be useful for the task at hand?
There is a better solution: No captive portals.
I'm hopeful that these kinds of public analytics could lead to solutions, or at least who to start talking to.
Good idea by the way!
The problem isn't even so much with captive portals, but only with those actively trying to circumvent captive portal detection provided e.g. by iOS (as pointed out above). "Regular" captive portals will be captured by iOS and you can log-in via the mini browser before any requests to Facebook etc. go through - problem solved (albeit in a very hacky way).
The problem only (re-)materialises when some smartass developers actively try (and succeed) to break portal detection (my guess is that they do it because iOS will close the portal once the Internet connection works, so all the nice ads they want to display just disappear).
Like it or not, a lot of places do that.
There are some obvious cases in which this is unacceptable, but they are few and far between. The overwhelming majority of captive portals I see are just trying to get your contact info... so now you have two reasons why they should disappear.
Everyone goes to the mall, not to shop, it would seem, but to use the free wifi and bask in the comfort of free aircon.
Captive portals are here to stay in places around the world, and like it or not, they are a widely used solution that is not going away any time soon. I for one applaud the author of this website's attempts to shine light on the problem of authenticating to this network type.
IIRC in some countries they're required (by law) to do so, because, y'know, terrorists.
Normally you would think it would just be easier to set a wifi password and skip the captive portal nonsense, but so many vendors harbor the fantasy that other people will pay for the wifi so they have to leave it open and put a "buy 24 hours of internet for only $30!" link in there.
I hate captive portals. They are such a nuisance, especially when you have your machine configured to always connect via VPN.
> but $2 would be a more appropriate price tag for a few hours of Internet
Correct. That's (one of the reasons) why Starbucks coffee is pricier.
I think we should move towards considering Internet access as a general service that people make available for their guests/customers.
Do you think hotels and restaurants can deliver reliable internet without charging for it?
Is it reasonable to assume that companies that don't charge for wifi can afford the staff to make sure that users don't abuse it?
I am considering your proposal & I don't see it working at all.
It's almost an inverse relationship, in my experience. The economy to medium-priced "business travel" hotels (the sort found near most U.S. airports) usually have free wifi, while the fancy "luxury" hotels often charge for it.
I simply choose better hotels.
Absolutely. 100% of the hotels that I've stayed at in the last five years have had free wifi. Almost half of those have still had captive portals.
Every Starbucks I've been in recently has free wifi. Every library I've visited has had captive portal-free wifi.
I don't understand what sort of "scaling" you're referring to.
Yes. Because most already do.
> Is it reasonable to assume that companies that don't charge for [[tap water]] can afford the staff to make sure that users don't abuse it?
Sorry to post the snarky response, but with internet access, as with all shared goods like access to water or noise in a semi-shared space such as a hotel, yes, I do expect they can handle it and not have it be a big deal.
Internet WIFI should be treated as a condiment. A business that can't afford condiments probably shouldn't be in business.
Many do. I've never seen a restaurant charging for Wifi, and I've seen plenty offering it for free. Quality varies, some are good, some suck. Hotels are all over them map, but I just stayed at the hotel that advertises free high quality Wifi (and it indeed was fine) as one of the amenities.
US-centric, of course, in some places I guess it many be too expensive for restaurants to do this.
Although a restaurant can get by without wifi, most modern restaurants have it for managing OpenTable, monitoring yelp reviews, ordering supplies online, etc.
I guess the signal might get a bit worse the farther away you get from the wifi router, but in general, providing wifi to customers shouldn't cost any additional money.
Heck, most McDonalds restaurants have free wifi these days, and that's about as cheap as it comes.
If you really want payment, then post a URL wherever you post a sign about the SSID, and/or make the SSID "Go To example.com after connecting".
This is a captive portal. But worse, because even HTTP sites don't send you to the portal.
* no MITM attack
* no TLS cert errors
* no "do I need to hard-refresh? what's the key for that?"
* no question if network access is working or not
* one reliable clear action to get access
This stuff would be a lot simpler if people weren't always trying to make it needlessly "easy" and fucking it up even more every time.
No, for fairly obvious reasons. If you MITM traffic, clients will correctly flag security errors. No method exists or ever should exist for a network to cause clients to not flag such security errors. Any such method would defeat one of the primary purposes of TLS: to protect against hostile networks.
> Our portal would let you log on but you'll still fail to connect to anything as we have to inspect it.
For what purpose? I have not seen any legal jurisdiction sufficiently draconian to impose such a requirement. (I've seen a few terrible ones that might require logging IP addresses.)
I know MITM should never be silent of course but some kind of interaction flow would be good. When you try to add a school account to your android it won't let you if you don't install the MDM client. A similar thing for the network would be great (of course, the MDM will install the cert).
I'd love if I could also pin our MITM cert to only be valid when the client is on our IP address' which if using ipv6 could work very nicely.
I don't travel often (Christmas and maybe once or twice a year outside of that), but it's when I encounter this. It's very frustrating because I'll be walking, pass a store I've previously connected to Wifi, and suddenly lose Internet, then hunt for a website to get the portal to pop up.
I'm annoyed that captive portals have been commonly using DNS hacking since 802.11b and I'm surprised a better solution hasn't been standardized. I have no idea where in the stack it should go (DHCP, wireless standards, or whatever) but DNS hacking drives me nuts.
The most sensible option would be a DHCP extension that indicates you are behind a portal and gives the IP to load, but this requires updates to every DHCP server and client, so it would take many years before it works reliably. Also, it fails for IPv6, but a modification to the Router Advertisement message could maybe do the same thing. It's a little scarier in this regard because it would be even easier to abuse.
The experience has gotten a lot better. I see Apple's pop up covering a lot more corner cases, but after years I see have problems almost every time I travel.
Can I set one up on a home network with a regular router without WifiDog or some other OpenWRT firmware?
Maybe somehow use one of the computers on the network to run a DNS server that all requests go through??
To do this properly either your router or switch/AP need to be configured to do the necessary rewriting as well as maintain a list of authenticated clients. Your best bet to do this with something in the consumer(ish) price range without a custom firmware like OpenWRT is something like a Uni-Fi access point which can handle the captive portal interception itself.
All I want to do is make a system which "takes attendance" via the phones automatically trying to join the local network, and I use the session is to look up the user. People would have accounts where they log in once via the captive portal and then the attendance would happen automatically.
Basically I want to make a captive portal with regular routers so I can sell the solution to regular venues.
How do these guys do it:
There are a lot of social wifi solutions now
The closest you could get would be to use another computer with 2 network cards as the actual router (running something like PFSense), and set up a consumer WiFi router as an access point instead of a router. This would only work as long as you don't mind the clients being able to connect to the rest of you local network; if that's an issue you really need something like a captive portal aware AP/switch or a VLAN.
However this solution doesn't make much sense in the end, as it would be much cheaper to buy one of the cheaper commercial-grade APs (UniFi's are around $80) and use your "regular router" with WiFi disabled than it is to buy a computer for that purpose. Those APs are also better quality than any consumer router you could find, and scale up much better for larger venues.
Also TBH if you're not aware of how captive portals work and why it can't be done by a random computer on your network, this is probably not a good business venture for you. This isn't an unsolved (or expensive to solve) problem to begin with.
Consider a building or cruise ship with an existing network. It's a much harder sell to say "replace all your routers" or "flush all your routers and install our firmware" than to say "use your existing router and just set up our DNS server on a computer".
If you can MitM connections on your network just by connecting a client to it, with no particular participation from the router, your network sucks.
Your linked site notes that they provide the router hardware.
It'd be really nice if there was a reserved DNS entry (like captive.portal or something) that operating systems could try to resolve and if it points to anything other than an expected value (loopback address, maybe?) it will bring up a window to sign into the network instead of relying on these nasty hacks that leave users confused when they can't visit a site over HTTPS because they aren't authenticated / paid / whatever.
Update: I've added Cache-Control and Expire HTTP headers to the HTTP responses for neverssl.com
There's actually a huge list of domains that macOS/iOS try: http://stackoverflow.com/questions/18891706/ios7-and-captive...
I have never seen a captive portal interceptor on MacOS (much to my disappointment), only iOS. Is there some setting I previously screwed up?
Here's a screen shot I found: https://www.wireless.bris.ac.uk/gfx/eduroam-osx/captive_port...
Because of this thread I simulated it on my network and couldn't cause it to show up.
I'm sure there are plenty of others, but someone might remember that URL over another so I thought it would be helpful.
"Click the confirmation link in the email we sent you to get online"
"Enter the code we sent you via SMS to confirm your number"
"Login via Facebook - provide permission to post on your behalf"
"Share on FaceBook for internet access"
"Confirm acceptance of our 6000 word terms and conditions"
However if you open common urls like google.com or facebook.com you'll automatically get redirected to secure connections (https) and they can't intercept this to present the login page. This is because TLS (the protocol behind HTTPS connections) uses end-to-end encryption.
Thus the author proposes to open this simple unprotected website. However most hotspots manage to automatically trigger the vendor specific mechanism as soon as you connect to their Wifi.
Don't use public wifi unless you really need to!
Well if you always turn on VPN I don't think it would be such a huge issue would it
It's especially relevant now that Chrome is threatening a big unsecure site warning for HTTP pages, so many sites which don't strictly need security are going to switch.
But can someone walk me through how never SSL allows me to connect to FB once my browser loads their default page? I feel like I am missing something which is maybe obvious?
As a result, many people will be unable to see the network's login page. If you are in this situation, you can load neverssl.com once, log in to the network, then browse normally.
according to https://github.com/android/platform_frameworks_base/blob/5b2...
But I know that some appliances do content injection or 302 redirects which only work over http.
I like knowing about this neverssl. I like that all the page assets are inlined to limit the page load to one request. Makes it easy to see what is being injected by your browser and the network.
SSL is not used any more and it shouldn't get into people minds. Its either https (as a common word) or tls.
I usually use Xkcd for that purpose, one of the few lightweight non-ssl sites I can think of offhand.
Only problem with neverssl is that it's a big jargon-laden for laymen, I mean the name.
Useful to see the weather updates as well!
Basically, it's designed to be easy to remember, and over time I'll deploy whatever "Nope, really use HTTP" workarounds are available as TLS-by-default, and maybe even DANE, gain traction.
The difference between neverssl.com and others is just that "guarantee" and the slightly tongue-in-cheek text that tries to make it clear to users what's going on.
Actually right now I'm on a plane, between Newark and Seattle, and just typed it in to log in ... only to see it featured on HackerNews. Mind Blown. I'm coming back from 7 days spent with other implementors of TLS, and it's something I stay up to date on. That's it.
It's pretty weird that example.com does not use https:// , I expect it will in the near-future. Part of its job is to set a good ... example.
AHA! That's it. Now it makes sense.
Easier to type and they never plan to add HSTS because of that reason.
I'd love to be in the meeting where they discuss adding security features lowers their traffic volumes...
Some of these only work by capturing http requests and rewriting them to take you to their portal. Funnily enough, that and other methods often work very badly and so you might be left trying to visit a site getting timeouts. Maybe your browser visited it previously and saw HSTS for example and so only tries https?
The point of this site is that when you realise this has happened, you type in 'http://neverssl.com' into your browser to force an http connection which hopefully the network will grab, mangle and take you to the login page.
It's a solution to a problem that really shouldn't exist.
Annoyingly, different client venders require different things. Here's an example of someone working on this: http://www.revk.uk/2016/08/captive-portals-apple.html (and a money quote from the comments: "OS X only does it if you're on Wifi though - for some reason they assume you'll never see a captive portal when wired"