A New Future for Icanhazip

I got a lot of mileage out of neverssl.com before somebody fixed the process to log into various "guest wifi" setups...ones that would intercept/redirect any http request.

I'm somewhat curious what fixed things, as I've not had to use neverssl.com for some time.

From what I can tell, most operating systems will now ping their own version of neverssl as you connect to a network to find out whether they need to show you a login prompt. It looks like they basically just check to see if they get the content they expect from a domain they own, and if not they serve you that page so you can see whatever it is your network injected. (You can usually see the OS domain in the address bar.)

captive.apple.com is what Apple uses

Thanks. I was reaching for an example but don't have a guest WiFi nearby to test.

Ah, that's interesting. I remember it being very broken for a long time...especially for "normal" users that wouldn't understand why navigating to an https site wouldn't work in that captive wifi situation.

Apple has at least ten or more of these I’ve seen - on badly configured networks you sometimes see it in the address bar - because cached responses could destroy the utility.

Yes, google, apple and Microsoft all maintain their own httpd with tiny stub content on it which specifically is not tls.

I set up my own version of both neverssl and icanhazip, with nothing but Nginx on a cheap VPS. I already had the server up for other purposes, and I feel better knowing that I'm not mooching off of other people's effort (and money).

can you name one or two? I've never seen anything else besides captive.apple.com

Neverssl has done some pretty nifty work to avoid caching. It redirects you to a random subdomain over plain HTTP just to make sure the browser has a cold cache. Maintaining a domain, the redirects, and making sure to _not_ accidentally obtain a certificate is a burden I wouldn't want to do, although it is not that difficult to do.

I was reading from neverssl maintainer that they get a _lot_ of traffic, questionable ones more than it is not. Its DNS runs on AWS IIRC, and we all know Route53 isn't the cheapest.

Ha, I could've used this ~a year ago when I moved into my current rental apartment. Fiber optic internet is included in the rent (in the form of an RJ45 jack in my wall), but there's a captive portal requiring you to enter your contract ID, which resulted in having to scour my memory and bookmarks for a non-HTTPS site.

Google's is http://connectivitycheck.gstatic.com/, and Microsoft's is http://www.msftncsi.com/ncsi.txt

Having lived through the debut of Firesheep, which prompted the industry to get serious about using TLS, its an amusing triumph of cybersecurity that today a site has to be careful to not accidentally get issued a certificate. Back in 2010, when certificates cost substantial sums and needed some expertise to apply for and install, I wouldn't have guessed we'd ever get to this point.

So interesting! Thanks for sharing.

Interesting, I haven't encountered either of these issues, but I serve about 1 request a month (to myself) and have Certbot running automatically.

My go-to for this is example.com

Leave it to Microsoft to use cryptic abbreviations and character limits even in URLs…

Alternatively there's http://www.msftconnecttest.com/ncsi.txt

IIRC the neverssl maintainer _works_ at AWS.

I found https://community.ui.com/questions/Apple-iPhone-iOS-portals-... which lists some of these domains (www.itools.info, www.thinkdifferent.us, etc.), and this answer on StackOverflow -- https://stackoverflow.com/a/22277933/ -- which reverses a list of domains that all point to the same IP

I’ve seen some of these but I swear I’ve seen others like portalcheck or something - but always to an Apple-like domain.

Firefox uses http://detectportal.firefox.com/success.txt

Annoyingly, I've seen some networks that try to "fix" problems by letting that go through even when not logged in. I'm pretty sure it had been fixed last time I flew, but Qantas in-flight WiFi used to be one example I'd seen. You'd connect, and then nothing would happen and no SSL connections would work. You'd either need a non-HTTPs site to get the redirect, or go to 'wifi.qantas.com' to accept the terms and conditions before you could browse. I was trying to work out why my iPhone and Mac weren't popping up that page as soon as I connected, and bizarrely captive.apple.com came up with 'Success' instead of redirecting, which means they must have misguidedly put in an explicit rule to let that through, completely breaking the feature!

I was always wondering given that firefox has that detectportal.firefox.com why they also put requests into example.com/example.org?

Now I realize that the "subdomain" can change - it's been like portal.icloud.us or similar.

This exact thing happened to me on an American Airlines flight one time. It seemed to get fixed later.

The Qantas system runs on ViaSat's platform and satellite network, I don't know what American uses but perhaps it's based on the same system.