NeverSSL | Hacker News Reader

NeverSSL

fdbhclmrkstnvwxz.neverssl.com

346 pointsrahuldottech199 comments

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?

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).

The closest thing I know of is Wi-Fi Passpoint: https://www.wi-fi.org/discover-wi-fi/passpoint

but I think it lacks the features necessary to do tiered auth

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.

https://tools.ietf.org/html/rfc7710 tries to solve this at network level..

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.

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?

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.

How do you serve the captive portal page to a user if you don't control a valid certificate for it and it uses HSTS?

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).

http://neverssl.com/changes

> 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?!

from the same page:

> 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.

That page says 6 million hits per day.

1 raspberry pi 4 could handle this...

On whose internet?

Who's opinion carries more merit regarding how a thing can be built? Someone who has built the thing or someone who hasn't?

I'm continually stupefied by how willing so many HN commenters are to publically advertise their ignorance by giving useless advice to actual experts.

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.

right! they need to set up a cloudflare proxy, or have github host it for example.

Can't do any useful caching for a purposefully cache-busting website

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.

Ctrl-shift-R solves that?

Only if you have a keyboard. If I'm on a captive portal, most likely I'm on my phone.

Read http://neverssl.com/changes

I'm pretty sure GitHub would require SSL, no?

There's an option to enforce it.

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.

Bandwidth, maybe? That page is 53.8 KB total. $2k does seem high though.

When used "properly" it should take even less bandwidth.

A GB of outbound transfer on AWS costs about 0.09$.

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.

But that’s not accounting for gzip.

This. Firefox's dev tools says 3.38KB transferred (including redirect and favicon). Taking that into account, it's closer to 5 billion page loads.

Well if he’s getting 6 million a day that’s a little over 2 billion hits a year. Maybe he’s overprovisioned an AWS instance or something.

I think he's including the transfers from twitter in the 55kb (which is over 50k of it), which wouldn't cost him anything personally

> 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 [0]

So he's paying a discount, even.

[0] http://neverssl.com/changes

Looks more like 2.7KB and then it loads some resources from Twitter to make up the rest of the size.

With no graphics

AWS costs add up over time. $166 per month is not bad, especially if it's a high volume traffic site.

I don’t understand. What’s the pricing costs? Bandwidth? Instance hours? S3? A database?!?

This website can literally be hosted on a free tier at almost any major cloud provider.

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.

You could do it on Digital Ocean or Linode or Vultr or many other providers for $5 a month and use just over half the included bandwidth.

I have been using http://perdu.com/ for 20 years for that purpose.

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.

Beware, sometimes the browser will make you think it fetched the page, but it's cached.. Don't panic, there is perdu.org (no cache directives)

I have a similarly funny one I like to use for this purpose: http://zombo.com/

I am confused but glad I enabled Flash for that.

Looks like pi-hole is blocking it, any idea why? or did it get hackernews'd?

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.

ow, I've shared perdu.com a few hundred times I think - that is one of the first websites I stumbled upon on the internet when I was in junior high.

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 :(

Ya maybe use Netlify? It’s free!

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!

that's either a lie, or that's because the owner doesn't care about saving costs.

I've hosted more dynamic webpages with large amount of traffic on servers that were costing me 20$/month.

The owner is Colm MacCárthaigh https://twitter.com/colmmacc. He's a Senior Principal Engineer at AWS Networking and is the author of s2n - https://github.com/awslabs/s2n.

I'm pretty sure he knows what he's doing and it costs what it costs for a reason.

No doubt he is smart, but it literally costs so much because he is using extremely expensive tools for that. It's literally static content.

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.

You know what else no one here has done? Built something cheaper and posted a link.

Why would I as a user care to use that instead?

I hear it's expensive! :D

But seriously, someone could probably fork and then convert his existing GitHub repo into a GH page...

> You know what else no one here has done? Built something cheaper and posted a link.

Thousands of people have built that for the past 20+ years without posting a link.

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.

You can put an S3 Website behind a Cloudflare distribution (with SSL not enabled) and do it all on the free tier, as far as I know.

It just takes a few badly behaved scripts constantly polling the domain.

$20/month for hosting, $146/month for the webmaster's fee.

What a waste of money. The code is hosted on GitHub and it takes 1 minute to move the site to GitHub Pages.

$0/year, forever.

Can you get github pages without TLS? Usually that would be stupid but in this case it's the core feature of the website.

The website redirects to a random subdomain which could explain the cost, but even then 2k sounds like a lot.

http://example.com also does this, albeit without the promise of never switching

Another one: http://http.rip

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 .

Indeed, "browser.urlbar.autoFill" option (enabled by default) would do that in Firefox.

There should be no forced https redirection if you fill in http:// prefix by hand though. At least for now, until example.com adds HSTS headers.

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.

This could also happen because of an extension like HTTPS Everywhere, which requests the https by default when both are available.

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.

It also sends the "Upgrade-Insecure-Request" header, which can cause that switch to take place.

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://.

The Firefox instance I'm using at the moment goes to the non-TLS version when I type "example.com" in the address bar.

And with a different relationship:

* 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].

[0] https://www.iana.org/domains/reserved

[1] https://tools.ietf.org/html/rfc6761

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.

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).

I think the only promise example.com has is that the domain will always exist.

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.)

"the domain will exist" does not mean "someone will run a web server there and respond to traffic", though.

Though I'm not exactly sure what it does mean. That it will have at least one DNS record?

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've always used terrible.com

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?

It gets you to the network's captive portal.

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.

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.

Apple devices try to go to http://captive.apple.com/ for this purpose.

Thanks for the explanation - I've definitely encountered that situation. Do you know why it works that way?

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.

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.

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.

http://example.com is my captive portal triggering website go-to. IANA reserved and will be there when I need it forever.

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.

Doesn't work for me, seems to fail to resolve. https://i.ibb.co/KmBk7DB/Screenshot-20191103-002332.png

your recursive resolver may be doing funny things. It's a valid and resolvable host:

https://www.whatsmydns.net/#A/example.com

I just use http://captive.apple.com

That upgrades to SSL for me

Really? When I try to visit the site over SSL it gives me an error.

Since everyone is posting alternatives, here is Firefox's way:

detectportal.firefox.com

This site is so useful. Whenever I'm in an airport, or on a plane, or in a hotel, I use it to make sure I make it into the portal.

It's also especially helpful that recently[0] it's started redirecting to a random subdomain to defeat caching.

[0]: https://twitter.com/NeverSSL/status/1136488879106666496

The fact you need this is incredibly unintuitive to anyone without technical prowess.

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.

My favorite to use is http://perdu.com/

I don’t know where I found it, but it’s charming!

I use http://bbspot.com since it'll probably never have ssl and the mid-2000s nostalgia.

Mine is always good old http://zombo.com.

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 think it's common in France. I've been using perdu.com for long for that purpose.

This will be much easier to remember than http://clients3.google.com/generate_204.

I use captive.apple.com if a public network fails to load the login/getting-started page.

That's super useful, I never knew about that.

It's what iOS uses. Not sure about macOS.

Same on macOS.

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.

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.

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.

That’s why I just use neverlssl.com now.

http://www.msftconnecttest.com/redirect is Microsoft's equivalent, in case that ever doesn't work.

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.

you never know how poorly a restricted WiFi access point is implemented

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.

Ah, makes sense. I don't think I've encountered one like that, but I can imagine they exist.

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.

Shortest SSL-free domain I've found is "x.com". Also works for email. Apologies to x@x.com (sorry Elon!).

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).

It used to belong to Elon Musk's online banking platform which went on to become PayPal.

Paypal recently transferred it back to Musk.

Any idea why http://neverssl.com redirects to http://{random_characters}.neverssl.com?

Avoid caching.

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.

Apparently because ISPs sometimes muck with caching headers? https://twitter.com/NeverSSL/status/1136491293113180160

I've been using http://ftp.debian.org and http://archive.ubuntu.com for the same purpose. APT mirrors provide GPG signatures for packages, so they don't usually use HTTPS.

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.

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.

> But is there anybody working on solving this problem transparently to the end user?

Yes. RFC 7710 defines a DHCP option to supply a URI for a captive portal page.

https://tools.ietf.org/html/rfc7710

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/

You can also use Microsoft's Network Connection Status Indicator (NCSI) URL: http://www.msftconnecttest.com/

Also has an IPv6 endpoint: http://ipv6.msftconnecttest.com/

Not nearly as memorable.

Just remember it has two non-adjacent t's, two adjacent t's, two adjacent n's, and two non-adjacent s's. It's easy!!

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.

That’s a surprising expectation given that they funded and created the Internet.

DIA is a HUMINT agency, so they should have been among the first organizations to go HTTPS-only. Instead they were among the last.

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)

I believe http://captive.apple.com/hotspot-detect.html does the same thing.

edit: woah, two other comments at the same time pointing it out.

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.

So far, I used http://example.com for (manual) portal detection. Is there some reasonable risk that it will go away in the future?

I think captive.apple.com also works for this use case.

Typing 1.1.1.1 (Cloudflare DNS) or 8.8.8.8 (Google DNS) into the address bar does the same job, is quicker, can be easily remembered, and is safer.

It's not an advertised function, so it might change. I just went to 1.1.1.1. It was HTTPS.

1.1.1.1 might be HSTS preloaded in the future (although not in the near future - there were issues with captive portals[0])

0: https://chromium.googlesource.com/chromium/src.git/+/36b8980...

I use captive.apple.com regularly but just realized that https was the issue being worked around on WiFi. Learning something new.

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.

He means that TLS on all domains breaks some use-cases and thus, in those cases, there needs to be some way of working around the situation presented.

You can argue the merits of this being a good thing or not. But it’s fair to call it a work around.

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.

There's actually an RFC on a DHCP option for captive portal advertisement.

https://tools.ietf.org/html/rfc7710

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.

Then there is http://uselessaccount.com/

Everyone seems to understand this but me... how does connecting to a non-ssl website disable ssl on other sites?

It doesn't, it gets you into the wifi network's login portal, from which you can log in and then ssl will start working.

[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.

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.

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

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?!

Holy cow ...

I often use this for awkward public WiFi hotspots. Short, easy to remember and keeps its promise ;)

Huh, I've had that problem before but recently found that if you visit a local (non-routable, I guess) address then it picks up the captive portal.

For me that means type "1", the browser fills the rest, hit enter: boom, captive portal.

YMMV, of course.

This is my homepage for my cell phone and my laptop -- immensely useful for airplane wifi and hotel wifi.

If you travel more than once a month, save yourself the frustration of believing that you have an internet connection, and switch here.

Thank you neverssl. Since reading about it here I have used it countless times!

I've always used http://www.msftconnecttest.com/ which I guess is Microsoft's.

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.

I've seen the described behaviour on an internal network for a major wifi provider.

Every week or so you'd have to visit a non-https site so you'd be reconnected.

Here is another similar site i've been using for years: http://amionline.net/

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)

http://icanhazip.com is also good for this.

Redirected me to https, I have not visited that site before (probably).

It didn't for me (over ipv6, not sure if that makes a difference).

When I’m having trouble logging into a Wi-Fi network I just go to 128.1.1.1. Seems to work every time.

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.

NeverSSL already does that for you.

Yeah but if that redirect gets overridden...

I just use captive.apple.com for this purpose--I believe Microsoft and Google have similar domains.

http://httpforever.com

Are there any plans for a newer version of WiFi to fix the need for this sort of hack?

Another alternative, that seems to be lighter, is nohttps.com

Doesn't load for me.

It's a completely empty page, which is probably why it's lighter.

Well, now it's just a parked domain. Are you sure you got the right site?

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.

I just use bestbuy.com. It’s much easier to remember.

just use http://captive.apple.com

well, https://neverssl.com

I love this, so useful, thank you.

seems strange that trying to use it over ssl gives a security warning

Just got to 1.1.1.1.....

literally used this this weekend at motel6.

Thanks!

nossl.cn

test.at

Reply on news.ycombinator.com