Hacker News Reader

Comment by lxgr | Hacker News Reader

It’s kind of baffling that after decades of wifi and captive portals, we still don’t have any kind of standard for the network to properly signal the fact “you’ll need to visit <url> in a browser” to a device.

It’s hacks (DNS hijacking) upon hacks (captive portal detection) upon hacks (captive portal detection evasion, used e.g. to allow devices to stay connected to networks offering “messaging only” plans).

On top of that, after a captive login, the entire session is only identified/authenticated via MAC address, which is very sniffable/cloneable in unencrypted wifi… At least I have yet to see any captive portal hotspot to leverage OWE for something more secure than that.

View on HN

Not sure if this is deliberate, but it seems like a straightforward application of the "paving the cowpaths" approach to standards that was advocated so much in the last decades.

Basically I guess, browser vendors decided that there is no way to convince every captive portal operator on earth to adopt some kind of standard, so they just "standardized" the existing practice of querying some random http host and see if it gets intercepted.

I think there are also discentives to standardisation, unfortunately: Captive portal operators want their portals seen by humans, often just to get people to agree to some ToS. If this were standardized, someone would build a tool that could log into a captive portal without user interaction, and while this would be awesome for me and you, it defeats the entire purpose of the portal from the operator's perspective.

So I fear, this is why we (techies) can't have nice things.

> so they just "standardized" the existing practice of querying some random http host and see if it gets intercepted.

What I have seen a lot is only certain URI's redirecting you to the captive portal. ("A lot" being some minority of open access points, not most of them which redirect everything - but it's common enough)

For anyone stuck in this labyrinthine hell, the two which always work belong to warring big tech behemoths:

https://www.google.com

http://www.msftconnecttest.com/

Others may work on these AP's; I haven't had to try different ones after trying these two.

https://www.google.com will most likely not load because browsers nowadays have HSTS, and they will stop loading as soon as the server offers the wrong certificate...

Yeah, ran into that one a few times. Sometimes clicking "advanced" if presented as an option, lets me proceed. Other times, I think I just used Internet Explorer to get around it.

example.com, example.net, and neverssl.com all lack HTTPS.

I have "neverssl.com" as a prominent bookmark; as its name implies, the lack of SSL means I get directly to the captive portal page.

Except every once in a blue moon when the opposite happens: HTTPS 443 gets blocked/hijacked while HTTP 80 goes out just fine (in which case either of the beforementioned generally gets you to the portal).

How would that work? The entire point of https is that it can't be hijacked.

(Or rather, you can hijack it, but you can't show a portal on that connection, so what would be the point?)

I'm not saying it works as intended or that there is a point to it. Just that it does happen.

You can add

http://connectivitycheck.android.com,

http://connectivitycheck.gstatic.com, and

http://www.apple.com/library/test/success.html

to your list.

> Captive portal operators want their portals seen by humans

The concept of "engagement" strikes again. The objective there isn't to complete some business transaction or payment (otherwise it would be in every party's interests to make tooling to facilitate said transaction), it's to explicitly waste a human's time.

"It’s kind of baffling that after decades of wifi and captive portals, we still don’t have any kind of standard for the network to properly signal the fact “you’ll need to visit <url> in a browser” to a device. "

We do, actually, and have for decades.

https://en.wikipedia.org/wiki/WISPr

Back in ~2010 I wrote a simply python script that parses out the WISPR data that you get, and submits data to the place specified by the XML.

It works on 90+% of hotspots i've ever encountered.

Could you share your script? That sounds really useful!

That sounds cool – are you saying that commercial hotspots actually use this? The specification website seems to be offline, for one thing.

Assuming that's indeed a thing, I wonder why the experience (at least on macOS/iOS) is still so mixed then.

For example, in inflight Wi-Fi, I practically always have to manually navigate to a non-HTTPS site in my browser to hopefully get redirected to airlinename.com/wifi or whatever they use, to be able to pay for an internet pass (with credit card or by watching their ads).

I suspect this is because many airlines now offer free in-flight entertainment and messaging on their free tiers, and the OS's native captive login UI would interfere with that. So I suppose that WISPr protocol doesn't support communicating something like "limited connectivity, navigate to URL x to pay for full access, portal available at URL y".

Yes, most commercial hotspots use it. Particularly the redirect to login page ones. If you get some form of “you need to login” pop up notification, it is the main way they detect that. Those that don’t give you such a notification are probably not using it

For the captive-portal detection part, there’s an RFC covering it: The network provider can tell the device where to send the user, and can provide an endpoint to get info like how long is left on the session.

Apple has a page on it, here: https://developer.apple.com/news/?id=q78sq5rv

Actually, we do. The WISPr standard (https://en.m.wikipedia.org/wiki/WISPr) has since evolved into ETSI recommendations, and the new ones are automatable. But cheapskate hotel Wi-Fi systems are only upgraded when the building is torn down.

It is problematic because it would still require that you even have a compatible web browser.

On the other hand, this sort of nonsense is why some places just have an AP and give the wifi password and you can just connect.

(instead of visiting a page, setting a bunch of cookies and tracking you all over the universe)

Reply on news.ycombinator.com