Those tiered captive portals have unique requirements that conflict with OS behavior:
A) By default, they want to offer some limited Internet access, such as accessing a sponsored site (often a shopping site like Amazon) or streaming videos (from some server on the airplane LAN).
B) For premium, paying users, they want to offer (mostly) full Internet access
For this to work, they have to fool devices in Tier A into believing that they have Internet access, by spoofing responses from standard captive portal detection URLs like captive.apple.com. Otherwise, if the network fails the captive portal test, many devices won’t stay connected to the Wi-Fi network, preventing access to the sponsored sites or LAN streaming apps.
At the same time, they want users to be able to upgrade from Tier A (limited access) to Tier B (full access) at any time. So they enable these upgrades by serving a captive portal page... to every HTTP site _except_ the standard OS captive portal detection pages that would affect OS behavior.
That’s when the user needs to visit an HTTP site other than the standard captive portal pages. One like neverssl.com
It’s obviously a fragile solution and is becoming an increasingly poor experience as sites adopt HTTPS, HSTS, and other standards. At the same time, I don’t know of any upcoming solutions to the tiered captive portal problem. Does anyone know what should replace this?
I'm guessing that the way it works today if you're pointing to a non-standard DNS server like Cloudflare's, is that the portal still just intercepts and modifies those requests anyway.
Although actually I would like all those portal pages to disappear.
Considering how brittle this solution is, I wonder what airlines are going to do next?
The URL is usually written on the same material that tells you that wifi is available, that you can buy full access and that some sites are free, but it would be even better if your main site also showed a link for upgrading the network (I have never seen this one on practice).
but I think it lacks the features necessary to do tiered auth
> I also want to keep neverssl.com ad free, but as it's now costing me about $2,000 a year to host it, […]
Wait, how could hosting a static website cost $2k/year?!
Simple, probably a 386 computer plugged in somewhere. Never changed.
It is just a joke, the domain means "lost" in French and says "Lost on the internet? Don't panic! We are here to help you: * <- you are here"
I have HTTPS Everywhere (Extension from EFF) configured to try to automatically upgrade to HTTPS. Works for a lot of websites that have TLS without defaulting to it.
NeverSSL actually does not have anything on port 443, so will work even if browsers start trying to upgrade people to HTTPS.
> it's just a simple website hosted on AWS
lots of ways of spending a lot of money on hosting a website on AWS. Hard to judge precisely without traffic numbers.
I'm continually stupefied by how willing so many HN commenters are to publically advertise their ignorance by giving useless advice to actual experts.
There is an assumption that if there's nothing really visible made by one person it means they don't know what they are talking about. So, background: I'm a linux sysadmin at a very large internet company, and has been running hobby and small business sites for 20 years parallel to this. About a decade ago I wrote cache plugins for WordPress and run a lot of tests of 128MB VPS machines to see when they break. The traffic from neverssl.com really should be fine on a Raspberry Pi 4, because the whole app, including the temporary redirect db needed would easily fit in memory. The OS can be read-only, so the SD card wouldn't wear out either, and the Pi 4 has a Gbit link. But as it's been pointed out, the internet uplink could indeed be a problem, so instead of that, there's Hetzner: 33€/m gets you unlimited traffic, 2GB RAM, 320GB HDD. That's 400€/year, and that's all the cost. Note: Rpi4 has 1-4GB RAM.
Next time please consider that people may actually know what they are talking about even if they don't have their name attached to an "internet scale" service.
I've hosted more dynamic webpages with large amount of traffic on servers that were costing me 20$/month.
I'm pretty sure he knows what he's doing and it costs what it costs for a reason.
It's possible $166/mo is not enough of a hit on his income so as to be worth spending time optimizing (unlikely considering how little time it'd seemingly take to optimize), or since he works for AWS it could be sponsored (which would mean he has to justify the continued cost to his bosses when they ask about it).
All valid reasons, but not technical ones. Either there's some aspect of implementing this that we're not thinking of, or there are non-technical reasons involved that we're simply unaware of.
Thousands of people have built that for the past 20+ years without posting a link.
But seriously, someone could probably fork and then convert his existing GitHub repo into a GH page...
This website can literally be hosted on a free tier at almost any major cloud provider.
If the page is 55KB, that means that a single GB is about 18K page loads, but let's make that 15K page loads due to various overhead.
To spend 2000$, you'd need to send about 22TB, which are about 330M page loads.
That equates to 330M/365d = ~900k loads per day.
> it's now grown to about 6 million hits per day, and that's just the traffic that makes it through to the landing page 
So he's paying a discount, even.
* neverssl might be bought out, or re-registered, at some time in the future.
* example.com is a IANA reserved domain , which whilst it doesn't guarantee they'll never deploy SSL, does mean nobody else can register it, ever (RFC 6761) .
HTTP/2.0 304 Not Modified
date: Sat, 02 Nov 2019 22:22:19 GMT
expires: Sat, 09 Nov 2019 22:22:19 GMT
last-modified: Thu, 17 Oct 2019 07:18:26 GMT
server: ECS (sjc/4E71)
Firefox behaves very similarly, except I don't have to visit https://example.com twice before it becomes the default, I just have to visit it once.
Saying "currently" implies it's not guaranteed to always be true. (Although it's more likely to stick around than a random domain registered by a hobbyist.)
Though I'm not exactly sure what it does mean. That it will have at least one DNS record?
It's just your standard parked domain. I typed it in when I was frustrated one time trying to log into a public wifi. It worked and I didn't even understand why back then.
I don't get it. How does browsing to http://neverssl.com help you to log in to other websites?
NeverSSL is a huge frustration reducer, especially as I've been able to just tell less technical able co-workers to just go there.
I don’t know where I found it, but it’s charming!
I usually just futz around with things like the local gateway IP or the business's domain name (e.g. hotel domain name) until it works.
That’s why I just use neverlssl.com now.
It's also especially helpful that recently it's started redirecting to a random subdomain to defeat caching.
And for good reason. Once user has finished jumping through whatever hoops captive portal want them to jump, a new connection to the same server is likely to be attempted, and having a fake DNS response cached somewhere in libresolv or browser in the client is not the least bit conductive to that.
Paypal recently transferred it back to Musk.
There's no guarantee that they won't move over to HTTPS in the future though, so it's nice to know that NeverSSL exists.
Yes. RFC 7710 defines a DHCP option to supply a URI for a captive portal page.
Also has an IPv6 endpoint: http://ipv6.msftconnecttest.com/
edit: woah, two other comments at the same time pointing it out.
Not a single OS or browser has bothered to implement it. Instead they all idiotically try all kinds of bs trying to figure out if a redirect is occurring.
The issue is that https cannot be intercepted by such an access point, and is increasingly popular for all types of web use. "Being worked around" makes it sound like something different, perhaps even sinister.
You can argue the merits of this being a good thing or not. But it’s fair to call it a work around.
HTTPS absolutely should reject a captive portal trying to hijack it, that is the point of it.
But "work around HTTPS" remains a weird way to describe this. The captive portal is the culprit in need of a workaround, not https which is doing what it's supposed to be.
Holy cow ...
[Edited to add] The problem is that websites that require ssl prevent you from getting into the login portals.
I have http://detectportal.firefox.com bookmarked on my phone for this exact reason.
If you travel more than once a month, save yourself the frustration of believing that you have an internet connection, and switch here.
For me that means type "1", the browser fills the rest, hit enter: boom, captive portal.
YMMV, of course.
Every week or so you'd have to visit a non-https site so you'd be reconnected.