The worst code I ever had to write was captive portal detection for the PlanGrid app.
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.
You would think captive portal vendors will stop doing this sooner than later as more and more web sites and apps use HTTPS only. When most customers fail to connect because HTTPS is everywhere, maybe they will take the hint.
Android detects wifi with captive portals automatically and pops-up a notification that says "Wifi network requires sign-in". Clicking on that takes you to non-HTTPS page in a browser that is intended to be intercepted.
There is no reason why Apple can't add captive portal detection at OS level like Android does.
As the OP said, that is already in iOS - it is just that more and more captive portals are whitelisting the domains it hits to check for a captive portal.
> ...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.
It doesn't work so well. Sometimes I have to try every single browser on my phone or tablet and different sites. Eventually one of them triggers the captive portal detection. Sometimes I just give up.
Any Android from 4 to 7. I guess it depends on how much the portal is trying to be smart.
Getting it working correctly can be annoying. There is actually a HTTP status code for captive portal redirection (511), but nothing supports it. So if you use it, captive portal detection stops working.
The mini-browser (Captive Network Assistant) is designed to protect the user's privacy, so support for Javascript and cookies is deliberately disabled.
When iOS cannot fetch the fixed content of www.thinkdifferent.*, a UIWebView pops and displays that content, assuming it's a captive portal needing attention.
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.
It's sad, because these are the kinds of things that confuse the hell out of "common folk" and explaining requires explaining HTTPS, HSTS, how captive WiFi portals work, and then ultimately, why there isn't a better solution... which maybe doesn't have a great answer.
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?
My real plan with NeverSSL.com is to use the access logs to publish an up-to-date database of broken networks and what the rough popularity of each broken network is.
I'm hopeful that these kinds of public analytics could lead to solutions, or at least who to start talking to.
Since this involves information capture, you should let people know on the page. Although admittedly the naive user, for whom this is intended, may be confused by that.
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).
IIRC the big problem is that Apple severely restricts the captive portal displaying minibrowser, so the tracking cookies they want to inject don't work.
Honestly? It's 2017. Just throttle bandwidth and give your internet away for free.
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.
Ah, first world problems. Where I am, data connections are out of reach for the vast majority of the population (yet somehow, they all seem to have smartphones - go figger).
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.
Most captive portals I run across are trying to verify that you are in fact a paying customer. Typically by making you enter your hotel room number and name or something.
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.
$20 is one month worth of broadband in some countries. Anybody can do what he wants with his money, but $2 would be a more appropriate price tag for a few hours of Internet. If you're working, $20 could be OK though because you're gaining more.
It also depends on where you are. Getting high-speed, low-latency internet to a shopping centre in the middle of a metropolitan area is probably a bit easier and cheaper than getting it to a plane flying 40000 feet above the Atlantic. And while I probably wouldn't pay $20 for eight hours of internet on a plane (unless I really needed it), I don't find the price tag entirely unjustified.
WPA/WPA2 Enterprise supports a multi user environment. You can require a unique login per user and thus associate payment with that. It also alleviates the problem with mac address whitelisting.
I wonder why this seems so intractable in some countries. In others, such as Indonesia or Vietnam or Taiwan, WiFi really is free in most establishments and nobody seems to have a problem with customers abusing it. Even a $10 hotel has WiFi. Versus say London where a $300 hotel charges $25 for WiFi. In many places nobody would ever expect to pay one cent for WiFi in a place where they are already a paying customer unless it's an Internet cafe.
"Versus say London where a $300 hotel charges $25 for WiFi."
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.
> Do you think hotels and restaurants can deliver reliable internet without charging for it?
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.
Hell, my gym provides free wifi. The captive portal is literally just a button that says "Continue to the Internet" and redirects you to their Facebook page (not even a terms of use).
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.
> Do you think hotels and restaurants can deliver reliable [[tap water]] without charging for it?
> 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.
> Do you think hotels and restaurants can deliver reliable internet without charging for it?
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.
It shouldn't be too expensive for a restaurant to do.
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.
I think the real cost isn't that they use wifi, but that they actually sit around longer but purchase less in their time spent at the establishment. It's really important for restaurants to turn tables over quickly.
Most restaurants in Germany do. You'd have to explicitly and sometimes adamantly request "tap water" to get access to free water, otherwise you'll be served and charged for fancy "mineral water".
Almost none of the captive portals I run into want payment of any kind; they almost always just have a click-through for "don't abuse this network" or similar terms.
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".
put the payment url on a sign, just enforce an ip whitelist until customer has paid. Or in extreme sign-less situations put it in the ssid e.g. "pay at portalpage.com"
> put the payment url on a sign, just enforce an ip whitelist until customer has paid. Or in extreme sign-less situations put it in the ssid e.g. "pay at portalpage.com"
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
See the various comments about work-arounds for work-arounds. Random plain-http intercept-check sites because some captive portals try to make iOS not pop up the mini sandboxed captive portal browser. The endless confusion.
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.
I still think having people connect to something handed out by dhcp would be really great, that's what dhcp is for in the first place. If that's too complicated you could always try connecting to the gateway.
So is there a matching method to neatly introduce MITM in the connection? Our portal would let you log on but you'll still fail to connect to anything as we have to inspect it.
> So is there a matching method to neatly introduce MITM in the connection?
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.
Do you travel? I often have problems and am running out of non-https sites to test against. Best I can figure is that they're whitelisting certain domains so the captive portal detection isn't triggered. I think this is so certain things like iMessage or email work (hence, whitelisting apple.com), but blocking out the rest of the web.
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.
I just make up fake sites to see if I'm stuck behind a captive portal because too many times I've accidentally loaded a cached version instead and not realized that I'm being blocked. fjiodfakliew.com or something.
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.
Really? My point was, I have no specific idea why, but I /constantly/ have problems. My solution is to go to a non-https website in Safari and use the clickthrough. It seems to be on certain networks (not just a % of the time on all networks).
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.
Windows does the same thing, at least in 10. I get a notification that further action is required and clicking it opens a no-SSL Microsoft URL that Will redirect.
The question that I always ask family is, "Can you get to www.purple.com if you're having trouble?" It does what it says, is easy to understand, and is obvious if it's not functional.
My family always rhetorically asks "Why is this so hard?" or "Why does this never seem to work?" - which I never answer, because they are asking rhetorically, but also because there are a lot of deep technical issues you need to know about before you understand the common implementation and then I'm not sure I can explain why we dont have a better implementation.
Usually they let DNS resolve normally (because intercepting at this level will break the website even after you've satisfied the captive portal) and intercept any HTTP connections, responding with a temporary redirect to a controlled domain. Doing this with a mere DNS server will only work if you don't visit the website you initially tried to access for a while after you connect. It's also super easy to bypass; just pick a public DNS server instead of the one the network tries to assign to you.
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.
Can't I use a regular consumer router but hook up a computer on the LAN to do something? Intercept DNS? Intercept HTTP requests like you said? But the problem is what if the user makes https requests?
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.
Think about it this way: if you could do it with a random computer on the network without special cooperation from the router, what would stop someone from connecting to your network with this software you propose and doing the same? As I explained, telling your router to instruct your clients to use a particular DNS server isn't nearly enough.
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.
I know it isn't an unsolved problem. That's my point. I have the software to run on a local area network and now I just want to explore the right ways to actually set up our own captive portals on those networks.
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".
What networks have you seen that have more than one router and use consumer routers? Even medium sized networks often have only one router and multiple switches. You can get a router that can handle a captive portal and push a million packets per second for around $100. How little are you going to charge for your solution that it's going to be cheaper than that?
You could set one up with a regular router but you need something you can customize, be it the router itself, a raspberry pi, or a desktop PC acting as a server. And yeah, you've got it, the router needs to allow DNS to be customized so clients get pointed to a system that (intentionally) MiTMs requests and returns a http 302 redirect to go to the portal page.
I really wish there was a standard way of handling captive wifi portals, macOS and GNOME try to detect these portals and show them but sometimes it is unreliable.
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.
There is; both Router Advertisements and DHCP include options for captive portals[1]. In the case of DHCP for example, the DHCP server can send the URI of the portal, which the OS can display to the user. The mechanism in [1] is what OS X uses, I believe.
It's so annoying that I even wrote a script so I could connect to Starbucks WiFi without having to use a browser. This was back when I was on Linux using a tiling window manager but I still use it on macOS because it's useful.
Hey, thanks mate. With the various meetups I go and corporate networks I'm using, it's always a pain to lose all my saved chrome tabs to portal redirects because I forgot to open Firefox to get through the portal first. I might be able to leverage this to help.
So far I have had quite a few issues with HSTS, not allowing me to access web sites, or authenticate with WiFi networks, to the point that on Android 4.3 I use the outdated system browser for authentication and only afterwards switch to Chrome.
I'm glad that there isn't a standard. Implementing a captive portal should be a painful experience that ultimately results in giving up and not using one.
Leaving this feedback here because there's no contact info on the page: for the purpose of accessing captive portals, it would be a good idea to disable page caching. Since this was posted I've had to use it twice and the second time I had to hard refresh to see the portal.
My iPhone constantly misses captive portals and I have to hunt for a non-ssl website. I can't say if it's 5% or 30% of networks, but enough to be frustrating. Does anyone know if it is common for apple.com to be whitelisted for iMessage or something?
The captive portal browser (pop-up on macOS, slide-over on iOS) doesn't support full JavaScript or cookies (or previously didn't, maybe that has changed), so some captive portals specifically allow the captive portal test domains through.
I've never seen a setting for it. It's just a modal dialog with a webview. Like iOS, you have "Cancel" as an option until it connects and changes to "Done."
Except some portals actively try to avoid intercepting any of Apple's methods for determining whether you're on one. You're much better off with an off the beaten path solution.
Any site that doesn't redirect to the SSL version (if applicable) will work. The benefit of using something like captive.apple.com is that it's specifically designed to NOT use SSL in order to trigger redirects and such, whereas something like example.com just so happens to not redirect to their SSL version, so it's (essentially) guaranteed to work vs example.com who could decide in the future to redirect to their SSL version if they want
If I regularly used that as a known-good site that should be up with no SSL, I'd trust that an apple-maintained site (backed by akamai) would be up before "example.com".
I'm sure there are plenty of others, but someone might remember that URL over another so I thought it would be helpful.
It's reserved for the purpose of documentation/illustrations (especially RFCs themselves) without fear of changes/invalid domains/directing mass traffic. It's also useful for establishing an idiom for those RFC examples.
example.com is maintained by IANA. It's an official example address for documentation purposes. So on one hand, it will survive even if Apple disappears, on the other, they're likely not expecting any significant traffic.
Using the site for captive portal access does not actually generate any traffic for the site, because the middlebox intercepts and rewrites the request. Traffic only occurs if there is no captive portal. Hence the easily parsed "Success" body of the Apple site.
Phones confirm whether you passed the captive portal by requesting the usual check url again. That means they'll still get one request after a successful login.
Well, this was my solution before this shorter way came along. A force of habit, really, since I noticed that it was Android's internal method of detecting captive portals. There's really no reason to use this over neverssl.com, other than the gstatic.com page returning an empty response (or redirecting you if you're actually behind a captive portal). Somewhat useful if you don't want to leave the new tab page.
Some routers and networks try to intercept all requests and replace them with a 'captive portal' page for logging into that network. When you make a request to a webpage using https:// (i.e. SSL) the network has a much harder time injecting the login page, so you end up seeing nothing. The connection isn't going through and the network's login page can't break through SSL battle-warrior-armor.
The scenario is: You want to connect to a public wifi hotspot and use their internet connection. In order to do so you need to trigger the login page in your browser after you connect to the hotspot.
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.
Yep. Most default browser homepages use SSL, as do many popular second locations like Facebook. It can get a bit annoying to remember who won't serve you SSL when you're waiting to get an approval page injected into your browsing, so this site promises to do 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.
I might just be really stupid but I read the "what" and the "how" a couple of times and I still don't understand. I only inferred from the comments that this is to get through captive portals used in coffee shops by exploiting the fact that they have to to permit HTTP unauthenticated in order for the redirect to the login page to work.
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?
With a captive portal, your first HTTP request will be redirected to the network's login page or whatever they have. Many large sites now use HTTPS and HSTS and if you visit them once, they will always (or until the max-age header expires) be loaded over HTTPS by your browser.
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.
I'm sure they'd like to, but you can't do that over HTTPS without installing a certificate on the system. Many companies do that for HTTPS interception.
Not sure about Apple, but isn't this automatically handled by Android these days? Every time it connects to a network it pings http://google.com/generate_204 and if the response code isn't 204 then it should prompt you to open the browser to the redirected URL.
Apple has been using http://captive.apple.com/ for years. Their UI for it has gotten a lot better, too. Previous versions you'd get a popup, but you could dismiss it and it would disconnect from the network (which sucks if you're /trying/ to connect to a network without Internet). Now it has a few more options and ways to get back to the popup--but I still have issues with certain networks.
I've suffered from routers or captive portals poisoning my dns when they do dns redirects, so I usually opt for a nonsense domain like fjlsdfoierldoidflug.com
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.
I often just type in an IP address, 1.2.3.4 often works. Having said that i've had alot of problems where iOS refuses to detect the captive portal, but also decides it has no internet so doens't route any intentional web browser visits to the wi-fi.. driving me crazy. Just restored without a backup.. see if that fixes it :(
for clarity, this was happening when another iOS device worked fine right next to me. So "probably" not the network, but who knows what weird interaction causes the issue.
This is handy. I was at an airport and was helping numerous people with android devices get through the wifi portals, and dealing with the same frustrating failure of the captive-portal redirect. Android is supposed to detect that there's a redirect and give you a notification that takes you to the login page, but it's very inconsistent.
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.
I bought unencryptedwebsite.com last week after running into the same problem without knowing that neverssl.com exists. I still have to set it up, though. Too bad I'm lazy. :/
Most have a favourite non SSL site they use for captive portals. My is http://chairs.com, i've typed that so many times I now have a special relationship with it. With an ad blocker is very conveniently light weight.
There is no (working!) https version of the domain. I own/maintain neverssl.com and I'll be doing my best to make sure that it can never poison the intended experience. I use it myself.
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.
I think the idea is that many wifi networks out there require registration/payment to use. They also do this in really, really weird ways because making stuff is hard.
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"
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.