NeverSSL | Hacker News Reader

NeverSSL

neverssl.com

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.

Apple could also makes the mini-browser supports those captive portal instead? Then none of this bypassing would be required.

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.

The mini-browser (Captive Network Assistant) is designed to protect the user's privacy, so support for Javascript and cookies is deliberately disabled.

Javascript IS enabled in CNA!

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.

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.

Apple already has captive portal detection, but it doesn't redirect to a whole browser - it just displays a mini browser with a Safari WebView.

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.

> captive portals are whitelisting the domains it hits to check for a captive portal.

Why?

As the OP said,

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

Yes, Android 6.0 will be extremely annoying when trying to get you to click the captive portal.

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.

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?

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.

RFC 7710 specifies a way for DHCP servers and router advertisements to specify a portal page: https://tools.ietf.org/html/rfc7710

Do you know if any clients (iOS, Android, etc.) have implemented support for this RFC?

Not yet; too recent.

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

For what purpose? > Schools and BYOD.

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.

> why there isn't a better solution...

There is a better solution: No captive portals.

What would you suggest for the case of someone wanting payment for the connection?

Like it or not, a lot of places do that.

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.

But on the plus side:

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

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.

Then people either have to pay offline or you need to set up a different unencrypted network with a captive portal to facilitate payment.

What would you suggest if someone wants payment for a water tab? Ever seen that?

I think we should move towards considering Internet access as a general service that people make available for their guests/customers.

How do you see this scaling?

Do you think hotels and restaurants can deliver reliable internet without charging for it?

Is it reasonable to assume that companies that don't charge for wifi can afford the staff to make sure that users don't abuse it?

I am considering your proposal & I don't see it working at all.

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

"It shouldn't be too expensive for a restaurant to do."

Heck, most McDonalds restaurants have free wifi these days, and that's about as cheap as it comes.

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.

People usually don't lurk in those places anyway, I think. Usually there are coffee shops etc. that are much more open to that kind of thing.

Cost of internet can priced into the prices for goods and services provided

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

I was thinking the same thing, with [[lights]].

More like mustard and ketchup and napkins, along with a functional (clean, stocked) washroom.

Internet WIFI should be treated as a condiment. A business that can't afford condiments probably shouldn't be in business.

> Do you think hotels and restaurants can deliver reliable internet without charging for it?

Yes. Because most already do.

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.

Because it's usually people that can afford it, or a business trip, where the company will pay for it.

My company will pay for it, but it's a hassle to pay for it, submit the receipt, etc.

I simply choose better hotels.

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

I see it scaling the same way hannob's example does, with water. Who charges for a drink of water?

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

Most restaurants in most countries charge extra for a glass of plain water. The USA impresses foreigners with its free universal iced water.

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.

There are still part of the world where you are require by law to log who is accessing the internet, in case he/she does something illegal.

Yet another fantastic reason to get rid of captive portals. They spy on you _and_ are frequently broken.

I don't want your shitty slow internet. I want to pay $20 for fast enough Internet on a plane, not some 56.6kbps bullshit.

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

On a plane?

> but $2 would be a more appropriate price tag for a few hours of Internet

Correct. That's (one of the reasons) why Starbucks coffee is pricier.

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.

> The overwhelming majority of captive portals I see are just trying to get your contact info...

IIRC in some countries they're required (by law) to do so, because, y'know, terrorists.

Far worse than terrorists, filesharers.

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.

802.11 standard could come up with some kind of captive portal standard.

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

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.

Good idea by the way!

A link to a privacy policy at the bottom shouldn't confuse anyone.

Keep in mind that you'll also get hits from users with devices that completely lack automatic captive portal detection.

> No captive portals.

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.

This isn't generally a problem on smartphones and tablets because they can usually detect captive portals and prompt the user appropriately.

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.

It's go.microsoft.com. I Think you can be pretty sure that will forever be without https as well since it is hardcoded into several Windows versions

I believe it's http://www.msftncsi.com/

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.

Apple uses a large amount of domains to avoid this problem.

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.

Some networks started sniffing for the user agent 'CaptivePortalAssist' instead of domain.

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.

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.

How DO captive wifi portals work?

Can I set one up on a home network with a regular router without WifiDog or some other OpenWRT firmware?

Maybe somehow use one of the computers on the network to run a DNS server that all requests go through??

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.

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.

How do these guys do it:

https://www.fusionwifi.com/

There are a lot of social wifi solutions now

You must be able to MitM something to get this to work.

If you can MitM connections on your network just by connecting a client to it, with no particular participation from the router, your network sucks.

Your linked site notes that they provide the router hardware.

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?

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.

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.

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.

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

This is a proposed spec, no one has implemented this. I was in the BoF for this session a few years ago.

I think OS X opens captive.apple.com

It does, and so does iOS when you connect to a WiFi network that has a portal.

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.

https://github.com/imwally/starbucksconnect

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.

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.

I have a feeling that should it result in giving up, they will stop providing WiFi rather than stop using captive portal.

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.

Will do, thanks! Feel free to send me any specifics colm AT allcosts.net.

Update: I've added Cache-Control and Expire HTTP headers to the HTTP responses for neverssl.com

example.com works as well. it doesnt redirect to https://example.com

http://captive.apple.com/ also. That's what Apple devices use when trying to present the login for a captive network.

Is that better in any way than using example.com?

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.

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.

To be fair, example.com is on an anycasted CDN too and is owned by IANA.

Didn't realize that about example.com. TIL!

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.

[1] https://www.ietf.org/rfc/rfc2606.txt

[2] https://en.wikipedia.org/wiki/Example.com

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

that may perhaps depend on whether one is an example.com evangelist.

You can also use http://detectportal.firefox.com/ that we set up for FirefoxOS captive portal detection.

Is this also used in the new captive portal detection that's coming down the pipe for Firefox?

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.

There's actually a huge list of domains that macOS/iOS try: http://stackoverflow.com/questions/18891706/ios7-and-captive...

> The captive portal browser (pop-up on macOS, slide-over on iOS)

I have never seen a captive portal interceptor on MacOS (much to my disappointment), only iOS. Is there some setting I previously screwed up?

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

Here's a screen shot I found: https://www.wireless.bris.ac.uk/gfx/eduroam-osx/captive_port...

Drat, I've never seen that on OS X. Just on iOS.

Because of this thread I simulated it on my network and couldn't cause it to show up.

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.

I think I saw my Android phone use http://gstatic.com/generate_204, though more recent phones might use something different.

does it actually make an outbound connection or just a local page?

It makes an outbound connection. It's a real website, managed by the IANA (Internet Assigned Numbers Authority).

I like http://purple.com for this. It always gets a laugh if someone happens to be looking over my shoulder while I'm "fixing the internet".

Yep! I always used http://example.org

Came here to say this. "NeverSSL" is just too cumbersome to "swipe" on mobile.

TIL that ICANN needed to buy an SSL certificate from DigiCert to use for https://example.com

I was really hoping for a (possibly unhinged) manifesto against ssl, but this is good too.

Captive portal craziness.

"Click the confirmation link in the email we sent you to get online"

"Enter the code we sent you via SMS to confirm your number"

"Login via Facebook - provide permission to post on your behalf"

"Share on FaceBook for internet access"

"Confirm acceptance of our 6000 word terms and conditions"

http://http.rip is another site with this purpose. Pretty easy to remember too.

You don't even need an actual website. I just type 1.2.3.4 and it always redirects fine for me.

Afaik portals use dns

Many portals just mitm the HTTP connection.

Some do, some rely on DNS spoofing.

I hope this site can reword their explanation. It's a bit confusing what their intent is, especially in the final paragraph.

I just use connectivitycheck.gstatic.com/generate_204. The URL is a bit long, but I have it bookmarked.

www.gstatic.com/generate_204 should work fine; that's what I use regularly.

I just tried, and it looks like it'll still work after dropping www as well:

  gstatic.com/generate_204

httpbin.org/status/204 works too

0118 999 881 999 119 725 — 3

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.

Can some ELI5 (explain like I'm 5) to me? I don't get this. Seems like something I should know about.

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.

But what is the purpose of this page?

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.

Don't use public wifi unless you really need to!

> Don't use public wifi unless you really need to!

Well if you always turn on VPN I don't think it would be such a huge issue would it

It will never use HTTPS, so by visiting it, you allow the man-in-the-middle to do its thing, and show you a log-in page or whatever.

So, this is for use captive wi-fi portals that are served over HTTP that would otherwise not work when initially connecting to a site using HTTPS?

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've always used example.com for this purpose, but this is cool. Thanks!

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.

Ah OK thanks for the explanation. I guess they don't want to redirect HTTPS traffic as well for obvious reasons.

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.

For the French speakers among us, http://perdu.com/ has been around since the 90s.

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.

I don't know about newer versions, but I know on Android 5 it's generally a roll of the dice.

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.

The current list is https://www.google.com/generate_204 http://connectivitycheck.gstatic.com/generate_204 http://www.google.com/gen_204

according to https://github.com/android/platform_frameworks_base/blob/5b2...

My go-to for this situation is http://www.example.com

Cool, I've been using www.cats.com. This will do nicely.

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'll add mine to the list - http://bom.gov.au

Useful to see the weather updates as well!

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.

There's already a site for that: http://example.com

The name is bad :(

SSL is not used any more and it shouldn't get into people minds. Its either https (as a common word) or tls.

Words get to have more than one meaning. Your comment is not made from a cow, but there's nothing wrong with calling it bs.

Thank you for doing this. For years the NYT has been my unencrypted go-to; having something like this is great.

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

Ask the owner of neverssl.com if you can redirect the domain to them until it lapses. That way it might see at least some use. :)

usually i do craigslist.org

Considering how much clandestine activity has historically gone on on Craigslist, I'm shocked to hear it's not https only.

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.

Nice, I use http://perdu.com usually

I always used msn.com but yes, I see this site as being helpful.

I've always just used asdf.com, but I suppose there's always the risk it might switch over to HTTPS; might switch to this instead.

For this purpose, I usually use http://example.com/ or .org

Or you could just go to any non-http site like http://purple.com.

foo.com is my weapon of choice :-)

I was just thinking about this today! The New York Times had been my go to site but that won't work anymore. This is perfect!

Great idea but wish it was a shorter url. I use cnn.com because it's quick to type even on mobile.

I usually use rawr.com It has no guarantees but the site hasn't been updated in a very long time.

http://www.bing.com also works ^^

example.com is something that'll do the same job, and its reserved https://en.wikipedia.org/wiki/Example.com

I don't get it. What does it do stop redirecting users to the https version?

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.

It doesn't. It loads a page that's HTTP only, so that the wifi provider's login page can be displayed without an SSL error.

> so that the wifi provider's login page can be displayed without an SSL error

AHA! That's it. Now it makes sense.

I was always using ya.ru

Easier to type and they never plan to add HSTS because of that reason.

I've been using bing.com for this, but this will probably replace that.

Ah something for the day xkcd[1] makes https mandatory.

1. http://xkcd.com

Yep. I used to hit Reddit, but they went to SSL by default. Since then, I've had to route people to xkcd who didn't know how to get around this issue.

So that's three of us. Funny how so many of us come to the same conclusion of using xkcd.

Weird. Me too. I think it's because it's a frequently-visited site, so it shows up next to the Facebook button in the Chrome default page.

I use yahoo. I don't want to use a site that I would otherwise intentionally use-- captive portals often poison the DNS.

Yahoo is starting to use Strict-Transport-Security now...

I'd love to be in the meeting where they discuss adding security features lowers their traffic volumes...

use example.org, that's it.

example.com ?

always used xkcd for this

always used http://vimcasts.org/ . So glad someone made neverssl

I don't understand how this website works. If I visit http://neverssl.com/ I just see a home page that explains how it works which is to visit http://neverssl.com/. Can someone explain me step by step how to use http://neverssl.com/?

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"

Thanks for the lucid explanation!

Reply on news.ycombinator.com