Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Captive Portal IPv6 Support

github.com

Post reply on HN
Print view View original

41–50 of 57 posts

Re: Captive Portal IPv6 Support

#41

Post by gruez »

chikere232 wrote: post #40
gruez wrote: post #19

Earlier quoted context omitted.

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.

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

Doesn't seem like it. For instance the WPA enterprise setup dialog has a field specifically for a CA certificate[1]. Other OSes have something similar [2]. Presumably that's only used for WPA authentication purposes rather than being added as a sytem CA.

[1] https://askubuntu.com/questions/1317320/how-can-i-automatica...

[2] https://documentation.meraki.com/MR/Encryption_and_Authentic...

Re: Captive Portal IPv6 Support

#42

Post by Gud »

snvzz wrote: post #5
gruez wrote: post #4

Earlier quoted context omitted.

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.

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.

Re: Captive Portal IPv6 Support

#43

Post by ninkendo »

I wonder how captive portals are supposed to work with IPv6 temporary private addresses (RFC4941).

I’ve never run a captive portal but I always assumed that the router just redirects all port 80 packets to the portal (and rejects everything else), and then upon authenticating, the gateway puts your IP in the “allow” bucket and you get access.

But if you’re generating random addresses every few minutes, you’d need to continually reauthenticate, unless the system has some way of associating the temporary addresses with the original connection. Maybe it listens to ndp and uses MAC addresses to associate? That would be more advanced than most captive portals I’ve seen which seem to only care about ip addresses. Maybe just none of them use IPv6, or simply break with temporary addresses?

Re: Captive Portal IPv6 Support

#44

Post by mannyv »

ninkendo wrote: post #43

I wonder how captive portals are supposed to work with IPv6 temporary private addresses (RFC4941). I’ve never run a captive portal but I always assumed that the router just redirects all port 80 packets to the portal (and rejects everything else), and then upon authenticating, the gateway puts your IP in the “allow” bucket and you get access. But if you’re generating random addresses every few minutes, you’d need to…

In general they work by having an allow list and by using a captive DNS. Some will also try to redirect http/https.

Once the agreement is accepted the MAC is added to the allow list.

Not sure how MAC address randomization works in these schemes, but it does. There must be some standard algorithm that everyone follows.

Re: Captive Portal IPv6 Support

#45

Post by ninkendo »

mannyv wrote: post #44
ninkendo wrote: post #43

I wonder how captive portals are supposed to work with IPv6 temporary private addresses (RFC4941). I’ve never run a captive portal but I always assumed that the router just redirects all port 80 packets to the portal (and rejects everything else), and then upon authenticating, the gateway puts your IP in the “allow” bucket and you get access. But if you’re generating random addresses every few minutes, you’d need to…

In general they work by having an allow list and by using a captive DNS. Some will also try to redirect http/https. Once the agreement is accepted the MAC is added to the allow list. Not sure how MAC address randomization works in these schemes, but it does. There must be some standard algorithm that everyone follows.

I guess different captive portals work differently, because I’ve heard of plenty of them that can be bypassed by simply statically assigning the address of someone else who’s already authenticated (ie session hijacking), but it makes sense that any “decent” captive portal system uses MAC addresses to mitigate this.

The randomization I refer to is of the outgoing IPv6 address, not the MAC address… nothing that I’m aware of randomly cycles MAC addresses (Apple’s OSes can be configured to randomly generate a MAC every time you connect to a network, but it won’t regenerate them continuously in a session. IPv6 addresses however are continuously generated, as per the RFC4941 spec.) If the system is using MAC addresses to identify users, then temporary/cycled IPv6 addresses should be no problem.

Re: Captive Portal IPv6 Support

#46

Post by zamadatix »

mannyv wrote: post #44
ninkendo wrote: post #43

I wonder how captive portals are supposed to work with IPv6 temporary private addresses (RFC4941). I’ve never run a captive portal but I always assumed that the router just redirects all port 80 packets to the portal (and rejects everything else), and then upon authenticating, the gateway puts your IP in the “allow” bucket and you get access. But if you’re generating random addresses every few minutes, you’d need to…

In general they work by having an allow list and by using a captive DNS. Some will also try to redirect http/https. Once the agreement is accepted the MAC is added to the allow list. Not sure how MAC address randomization works in these schemes, but it does. There must be some standard algorithm that everyone follows.

There are 3 main types of "random Wi-Fi MAC addresses". The most well known one is randomization of the MAC while the client is probing from SSIDs (prior to connection). This has been around for many years and doesn't change the actual connection MAC later on. Another randomization type that's slightly more common these days (e.g. iPhones default to it now) is choosing a random MAC per SSID. That way you can't be tracked by MAC across multiple networks but you still have consistency for captive portals and business networks. The third is true rotating randomization - this is relatively uncommon as it breaks captive portals (there is no well known algorithm or it'd be relatively pointless). iPhones were going to adopt this with rolling MACs but it was too broken and offered little over approach 2 in terms of privacy.

Re: Captive Portal IPv6 Support

#47

Post by 0xbadcafebee »

gavinsyancey wrote: post #33
gavinsyancey wrote: post #31

Earlier quoted context omitted.

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

Apparently, there's a newer one that is supported by Android 11+, iOS 14+, and macOS Big Sur, at least https://www.rfc-editor.org/rfc/rfc8910.html https://www.rfc-editor.org/rfc/rfc8908.html https://developer.android.com/about/versions/11/features/cap... https://developer.apple.com/news/?id=q78sq5rv

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

Re: Captive Portal IPv6 Support

#48

Post by sebazzz »

WatchDog wrote: post #36
zamadatix wrote: post #11

As a heads up your project is MIT licensed - that means companies do not need to reach out to purchase a license for commercial use. It might make sense to change that to an offer for official support (or relicense the project to meet your desires if applicable).

SQLite is public domain, but they apparently get enough enquiries about purchasing licenses, that they offer a warranty of title. https://www.sqlite.org/purchase/license

Yes but that is specifically (they actually mention this) because some companies don’t recognize public domain license, so those companies rather buy a few thousand dollar license than going through the internal bureaucracy to get it approved - if even possible.

Re: Captive Portal IPv6 Support

#49

Post by abdrzj »

zamadatix wrote: post #11

As a heads up your project is MIT licensed - that means companies do not need to reach out to purchase a license for commercial use. It might make sense to change that to an offer for official support (or relicense the project to meet your desires if applicable).

You are right, I forgot to delete the mit license.

I have now removed the mit license and modified the license to accommodate commercial use of the source code.

Best regards

Re: Captive Portal IPv6 Support

#50

Post by abdrzj »

Uptrenda wrote: post #24

This is really cool. Nice work and I find the MIT license you've chosen to be interesting. I chose the very same license for my own open source project because I wanted there to be few excuses not to use it. Damn, you've done significant work on this. Will have to check this out more in depth.

I forgot to delete the mit license. I have now removed the mit license and modified the license to accommodate commercial use of the source code.

Best regards

Post reply on HN