If you’re using a mainstream OS that automatically detects standard captive portals, the main reason why you’ll need this is for “tiered” captive portals like the ones offered on some airplanes.
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?
Unless I’m missing something, RFC7710 doesn’t offer anything to address this “tiered” captive portal scenario; it just provides a less vendor-dependent protocol for the captive portal checks that are already being performed by the OS.
Adding another question on top of this, does anyone know how widespread DNS over HTTPS affects this model? I guess you could do filtering based on IP address, but that seems really fragile as well?
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.
I’ve found that non-standard DNS often prevents access to WiFi portals. Removing the Google/Cloudflare dns settings is step # 2 in my public WiFi debugging checklist (after trying to visit neverssl).
But how do you discover which sites are available on the free tier? Better to just serve the portal page to everyone, inform them, and let them select.
Although actually I would like all those portal pages to disappear.
Thanks for this comment, because it explained something I've had passing curiosity about but never bothered to fully investigate or understand. I've been using NeverSSL for ages, but only in one specific scenario, which is in-flight WiFi. I travel a lot so it manages to stay in my top sites, but every other public WiFi network works fine without that workaround.
Considering how brittle this solution is, I wonder what airlines are going to do next?
For those, you create a portal URL on a domain you own, and let people upgrade from there.
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).
I've also used the site to demonstrate cURL and GET requests on a basic level, since there's no TLS handshake to gum up the simplicity of seeing simple HTML returned from a barebones CLI command.
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"
Hasn't changed in 20 years, has no javascript, no tracker. Exist since before websites had ads everywhere, and know it would be laughable to put ads on it.
Just to let you know, https://perdu.com/ actually loads for me (note the scheme is https).
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.
I used to use http://purple.com, which for many years was just a blank website with a purple background. Then a few years ago the domain was sold to a mattress company :(
I was about not to bother to respond, but I have a few minutes.
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.
Maybe, but there are a bunch of smart folks here too, and no one can come up with a good reason for this costing $2k/year.
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.
That's probably true. I'm paying around 70 USD per month for Azure Functions (an equivalent of AWS Lambda) because they charge like crazy for disk read/writes and my application is quite tiny, definitely could fit on a raspberry pi. But I don't bother to optimize.
Free tiers usually only give you a paltry amount of egress bandwidth, like 1GB. This site is serving 6,000,000 hits a day, according to the author. At 2.8kB/hit, its using a little under 17GB/day. Still, that shouldn't cost $2000/year - one would think serving a couple hundred hits/second of static, easily cached data could be done with something like lightsail for $10/month or less.
it's not cache-busting, it's captive-portal busting. there's no reason it couldn't be cached on some service that charges less for bandwidth than AWS does.
Although yours is a valid reason, but I’ve had a colleague of mine who isn’t savvy enough to use this when they need to connect, but they told me they stopped using it because it would show them the page even though they haven’t connected yet because their browser cached the page somehow. I’ve adjusted by using a private/guest browsing mode to open this page but the cache busting cuts it easier for people who have no knowledge of caching.
Not on a custom domain--it's optional, and you have to have a CAA policy that will allow them to get an SSL cert for your domain and agree to allow them to do so. It's only required for github.io subdomains.
Not for the amount of bandwidth they'd be using. Netlify's free tier only covers 100GB, which recently I've been finding I've been getting very close to maxing out in my personal site so I can only imagine for a site like that!
* neverssl might be bought out, or re-registered, at some time in the future.
* example.com is a IANA reserved domain [0], which whilst it doesn't guarantee they'll never deploy SSL, does mean nobody else can register it, ever (RFC 6761) [1].
http://example.com/ does deploy HTTPS https://example.com/ - but a redirect from http is unlikely, at least until the .com TLD is HSTS preloaded (and this might not be for another 10 years or so).
Has an interesting WHOIS record too. The "registrar" is "RESERVED-Internet Assigned Numbers Authority", and no admin/technical/billing contacts like in standard whois entries.
In both Chrome and Firefox, when I type "example.com" into the URL bar, I go to https://example.com , probably because I've visited the https site before and they remember that. So I do not recommend example.com .
I don't think the IANA domains make use of HSTS or anything of the like.
HTTP/2.0 304 Not Modified
cache-control: max-age=604800
date: Sat, 02 Nov 2019 22:22:19 GMT
etag: "3147526947+gzip"
expires: Sat, 09 Nov 2019 22:22:19 GMT
last-modified: Thu, 17 Oct 2019 07:18:26 GMT
server: ECS (sjc/4E71)
vary: Accept-Encoding
If you type "example.com" into the URL, both Firefox and Chrome will try HTTPS first. If you want plain HTTP, you just need to ask for it: "http://example.com"
I don't think HTTPS is the default automatically. When I create a new Chrome profile, then type example.com into the url bar and hit enter, I go to http://example.com . Then when I type https://example.com twice (each time hitting enter) then type example.com and hit enter, I go to https://example.com . So I think it might be whichever is more common in your history.
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.
HTTPS Everywhere uses built-in rules, not heuristics, to determine when to rewrite an HTTP request to HTTPS. There does not appear to be a rule for example.com, so HTTPS Everywhere does not cause a rewrite.
For Firefox, this may occur when the address bar autocompletes from history, pulling the https:// entry. As far as I can tell, it doesn’t have anything to do with prioritizing HTTPS, just whichever is more frequent in your history (if you visit the HTTP enough times it will switch to picking that for autocomplete). If you don’t use the autocomplete entry (for example, by tab-completing it but deleting the trailing slash), then it will use HTTP unless you actually typed https://.
This is very pedantic, but technically nothing requires an HTTP service to be hosted at example.com. It's only guaranteed to be reserved and never assigned to a real organization at the DNS level.
I'm not sure that's even true. RFC 6761 says "IANA currently maintains a web server providing a web page explaining the purpose of example domains."
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.)
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.
"This website is for when you try to open Facebook, Google, Amazon, etc on a wifi network, and nothing happens. Type "http://neverssl.com" into your browser's url bar, and you'll be able to log on."
I don't get it. How does browsing to http://neverssl.com help you to log in to other websites?
On some public wifi networks, you need to load a captive portal page and hit a button (usually to accept terms and conditions) before network to route you to any actual sites. The network often enforces this by redirecting you to that page whenever you try to visit something else. However, this doesn't occur properly when accessing a page with HTTPS. The easiest way to to directly to to the captive portal is to try to go to a non-HTTPS site, but fewer and fewer sites provide this (for obvious securityv reasons). The purpose of this site is to provide an easy-to-remember domain that the owner guarantees will never use HTTPS so that users of such networks can type it in as a way to load the captive portal. I've used it a number of times when using wifi on Amtrak trains.
Captive portals require intercepting and redirecting your HTTP request. You can't do that with HTTPS because it's encrypted. Most sites now automatically redirect to HTTPS and are cached that way by browsers so it's hard to find a HTTP-only site that will get redirected on these networks.
Websites can tell browsers to never connect to them via unsecured channels (hsts/hsts preload), in a secured channel the browser validates the server's encryption certificate is authorized to encrypt traffic for that domain, so the wifi network can not intercept it to serve up the captive porter.
You don't use a lot of hotel, airplane, airport, guest or otherwise captive portals do you? Most will gracefully redirect but a lot are painful. Add in things like HSTS (can't just go to Google), HTTPS Everywhere, etc and it's downright annoying to get to the portal.
NeverSSL is a huge frustration reducer, especially as I've been able to just tell less technical able co-workers to just go there.
Never had any issues typing http://google.com manually and having that get redirected to the capture portals. Obviously you have to specify the protocol otherwise modern browsers will try https first.
One trick that often works at hotels is to enter the hotel's domain name, which typically has an entry in the wifi DNS. I don't know how that works related to SSL, I just know it often solves the problem.
If the WiFi has a login portal, you might not get redirected to it when accessing an https site. If you go to this site, you’re more likely to get properly redirected.
It lets you access the portal to connect to wifi by allowing the router to MITM the connection due to the lack of SSL and bypassing caching with the random subdomain. After successfully connecting through whatever custom router software you'll be able to log in to those other websites.
They might not run a web service indefinitely, nor did anyone ever say they'll not redirect to https. It happens to work just like a random other 90s website might work.
Even with technical prowess - I'm a software developer and spent much of today designing a cloud load balancer architecture for a startup's global infrastructure - I had never realized that this issue had to do with SSL.
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.
I’ve used http://www.fake.com for years just because it worked. If that London-based artificial plant company ever goes out of business, I don’t know what I’ll do! ;)
I used the same until I recently hit a network that allowed that site but was captive for everything else. No idea what would inspire that configuration.
iOS won't consider itself connected to a WiFi network until it can hit that domain and get the response it expects, but some networks want you to be connected even though they don't actually give you full internet access. For example, plane wifi networks where you can stream video to your device but would have to pay for actual internet. So those networks will allow the connection for that site and other captive detectors but intercept actual connection attempts.
Sorry, I understand all of that. This was not one of those situations. I could not get to any place on the network because they had a captive portal but iOS didn’t know to open it because they allowed captive.apple.com through. After navigating to neverssl.com I was properly redirected to the captive portal and able to agree to whatever guest WiFi terms were available.
Whyyyyy... ugh that’s so dumb. That is just someone shooting themselves in the foot for no reason, or maybe some ex employee did something silly on the way out.
Why not just alksjdhflkjahdskjfhalskjdhfas.com or something that definitely doesn't exist? Since there's no HSTS on domains that don't exist, it should allow the wifi network to redirect to http://myloginportal/whatever and do its thing so you can access the network.
Some captive portals do TCP redirection, but no DNS redirection.
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.
Of course some portals do use DNS and so you end up with your favorite site's home page getting a bunch of irrelevant arguments appended to it, resulting in an error page.
That used to belong to a company selling a proprietary implementation of X11 a while back (I want to say MetroLink? They had ads in the Linux print magazines at the time).
Probably avoid caching. Just taking a guess, but you do not want your DNS cached when the poorly-programmed router login page is trying to spoof DNS, and redirect you to their login portal.
I just wanted to give a shout out both the OP for posting this, and other users here for providing alternatives like http://perdu.com/ or http://example.com! It made my day (currently on ICE in Germany, and WiFi portal came up instantly like a charm)!.
So, sites like this are useful. (It's certainly better than memorizing the URL that various hotels use for their wifi portals, which I have done before, sadly.) But is there anybody working on solving this problem transparently to the end user? It seems user-hostile to require people to remember a non-HTTPS URL, especially as more and more sites move.
And if you think there are things that need doing beyond RFC7710 (you would be correct) the place to go help/ bring your ideas is the IETF's capport (Captive Portal Interaction) Working Group: https://datatracker.ietf.org/wg/capport/about/
I used http://www.dia.mil for years, and expected that if anyone could be relied on to computer as wrong as possible it would be the US government; but that now 301s to the HTTPS version.
Serves a completely different purpose but I also frequently use badssl.com for testing TLS configurations (for instance you can load it on a kiosk, gym screen, etc - if it loads successfully then your connection is not being verified and could be MITM-ed)
It's SSL that causes this? I always thought it was DNS caching. That's why I just try an address I've never been to, or just make something up, adfkjghasdkfg.com, and I get to the wifi consent page.
What do you mean by "the issue being worked around"?
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.
Consumer operating systems started detecting captive portals long ago, and at a time when HTTPS was much less common than it is today for casual usage. Post-Snowden, there has really been a multi-industry push to use HTTPS everywhere even for "boring" use cases where a naive person wouldn't assume snooping to have much consequence. But captive portal detection appeared from Microsoft, Apple, Google, etc. years before that push.
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.
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.
Some WIFI networks require a login like airports or hotels. When you use https sites it wont redirect to the proper “wifi login” page as it should. This site being http should redirect you to that “wifi login” page
Some wifi networks will display a login/payment page to you by mitm'ing your connection & replacing the page you tried to load. But of course this only works for HTTP pages.
Mamma mia, this is so wrong and so bad on so many levels. So instead of fixing the borked captive portal (there are other ways of intercepting the connections not requiring messing with encryption) we tell users to disable encryption? Somewhere on a public wifi where you actually need it the most?!
I miss the old purple page at purple.com which unintentionally served the same purpose. Comcast techs used to use it as a test for whether you were in their captive portal.
Well now that text isn't very helpful, might be cached by any middlebox or endpoint. I expected at least a time like "Yes as of 2019-11-03T19:19:19Z" (I have a subdomain, http://time.lucb1e.com, that does I use for this)
I always used my own IP until I got to a portal that didn't work with that. Now I use a subdomain of my site. Then one very smart captive portal "moved permanently"'d that and my browser cached it, as it should, and on the next WiFi it tried to load the old one's captive portal x_x. Not sure what the solution is for that, it would happen with neverssl or any of the alternative domains mentioned here as well. I guess you'd have to manually type a random subdomain of neverssl or so.
I've been using nossl.google.com even before I worked at Google. Somehow I found out about it in the crazy wild west internet of the 2000s and most of my colleagues didn't even know about it. Still works today.
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?