Hacker News new | ask | show | jobs
by arjvik 610 days ago
As much as we need infrastructure to move us all the way to IPv6 (no more CGNAT please!), I'm not sure I want more captive portals in the world. I'd much rather an addition to the WiFi standard to support interactive login, though I suppose that would be hard pressed to come by now.
4 comments

Interactive auth sounds attractive at first but it's really the wrong place for an answer once you look at all of the ways captive portals are used (i.e. more than just "check this agreement box"). You really need the power of the browser to display a custom form behind the solution or you end up with n+1 solutions instead of replacing captive portals.

Something like a DHCP option or NDP option ends up being a lot more natural: "Hey, here's your IP along with the information needed to access the network" is already a function of that layer. Some devices (e.g. macOS/iOS/iPadOS, Windows, Android) take a similar approach in the reverse by probing for a specific test url. That's also a bit hacky and unreliable (e.g. it can falsely trigger) but some minor standardization of it to e.g. a well known DNS name could be another good option.

A DHCP option would be the correct way to specify a captive portal on a LAN. We have DHCP options for tons of things: IP phones, TFTP servers, cable boxes. One more option for a captive portal authentication URL would properly inform clients that there is a captive portal and how to access it. (It being a URL means it can also specify the protocol, so you aren't even locked into web browsers)

My assumption is this wasn't adopted because operators want the option of placing the captive portal upstream of the local network DHCP server. DNS spoofing works great over multiple network hops, but DHCP doesn't. (I'm not sure if that's a valid argument, but I'm sure somebody insisted on it)

There is a DHCP option for a captive portal URL. It isn't very well supported and nobody uses it.

https://datatracker.ietf.org/doc/html/rfc7710

If they got the top 5 wifi router vendors to support it, for sure you'd see other clients support it too, because the whole point of captive portal support in browsers is to react to what those routers are doing for captive portaling.

Since those vendors largely use open source tools, if you patched open source DHCP servers with that option, it would get adopted quicker by them.

- KEA DHCPD supports it as option 114: https://gitlab.isc.org/isc-projects/kea/-/blob/master/src/li...

- ISC DHCPD is officially ended (whoa!), but it looks like it supports option 114: https://gitlab.isc.org/isc-projects/dhcp/-/blob/master/commo...

- Dnsmasq author says they added the option (https://www.mail-archive.com/dnsmasq-discuss@lists.thekelley...) but I don't see it in their latest release

- Udhcpd doesn't seem to support it, so somebody could send them a patch, looks trivial to add

There already was! It was called Passpoint R2 Online Sign-Up, but it never got traction on the phone side of things, so it's now being deprecated by the Wi-Fi alliance.

It's really a business problem. IMO you shouldn't have to solve this just because you've gone indoors – you already pay a carrier for connectivity – but many carriers don't want to own that responsibility.

Is there even an alternative to captive portals?
Just give internet access directly.

Or do not offer internet access at all. People carry their own already-connected devices anyway.

16% of Canadians in 2022 didn't have a data plan on their phone, according to Statistics Canada. Roughly 6 million Canadians or so.

So not everyone. Actually a decent number of people that don't.

seems easy to confuse % of plans with % of ppl. probably a lot of obscure use-cases in there
Captive portals are used for many, many things that aren't just internet access gateways. Many IoT devices use them to enter wifi credentials so the device can connect to the wifi router. One of my projects is an IoT device with a custom web interface that can be used from a cellphone when there are no nearby wifi routers for the IoT device and phone to connect to - the phone connects directly to the IoT device and gets the custom device control interface.
Hotels absolutely don’t want to provide open access to all for obvious reasons. Although I have a “global unlimited” business SIM, I find it rarely works all that great. Getting a local SIM is not always an option.
What if legal wants to show a TOS page, or you want finer grained authentication than a shared key?

>Or do not offer internet access at all. People carry their own already-connected devices anyway.

Travelers don't typically have gigabytes of bandwidth to spare. I for one like having unmetered internet access even when there's theoretically internet access available through roaming (absurdly expensive) or esims (expensive)

>What if legal wants to show a TOS page?

The reality is that nobody wants to bother with any of that.

Either just connect me to the internet without extra steps, or don't at all. Don't waste my time.

>The reality is that nobody wants to bother with any of that.

I don't either, but for IT departments in large organizations, ignoring the legal department isn't an option.

Gues they just won't provide access then. Oh, what's that? There's a reason they need to provide access? Well, too bad the IT standards people invented a way to make sure we didn't interfere!
I appreciate the sentiment, but having a shitty Wi-Fi is better than none at all IMO.
> or you want finer grained authentication than a shared key?

Configure your access points to use RADIUS or SAML for auth?

Is WPA enterprise authentication still a dumpster fire? Last time I set it up it was still a hassle because you had to import CAs and manually choose the authentication protocol. Definitely not a good experience for someone who's stopping by a cafe for 30min and wants wifi.
In your coffee shop-like scenario, what benefit does a captive portal on anonymous Wifi offer to either the customer or the coffee shop, over regular Wifi authentication, and a sign on the wall that says "wifi username/passowrd is..."

As for importing a private CA. Use a certificate trusted by a public CA and you won't have this problem?

If someone makes you import a CA, you have to assume they intend to eavesdrop on ssl encrypted communications. Enterprise WPA doesn't require it.

The right flavour of incompetence might get you there without bad intentions but really if you give someone the capability of eavesdropping you have to behave as if they're intending to use it

... use regular authenticated wifi?
CGNAT is ok for IPV4 because it provides us some level of protection against state ( sponsored ) actors.
You’re going to have to explain that one.

I don’t see how CGNAT does anything but allow easier access to attacks (using private ip space outside of the local network)

All the details can be found in the EUROPOL publications begging for it to be banned.
IIRC there was some hullabaloo made with RIPE in ~2017. Half of it was "go to IPv6 and it isn't a problem" and the other half was "or also log the source ports so we can complete the identification through CG-NAT".

It's nearly 8 years later, we haven't moved to IPv6, and they stopped making noise so I'm left to assume they either got more source port logging or found some other method?

politics still clinging to the idea of identifying ppl by obvious traffic meta-data
There is people using chef/kitchen knifes for murder too. That doesn't mean we should regulate them for army use and monitor all cooks. Yet this is what many but certainly not all decision makers are doing. Good, fundamental, stuff is happening too, such as RPKI for example. Some "politics" is definitely not happy about that, but its good for the internet.
Ah, allows hiding behind a massively shared single address with less traceability.