It’s unfortunate that, below HTTPS and a light smattering of WiFi encryption, there’s essentially no authenticity controls on LAN management protocols.
So the hostapd configuration for SPR has the following components: - ap_isolate=1 - per_sta_vif=1 - unique passphrases for devices - firewall rules
ap_isolate stops the AP from doing L2 forwarding between clients using the pairwise keys. the per_sta_vif=1 will also ensure that each client has a unique GTK so they can't use group key encryption to communicate without the AP.
Next, unique passphrases are used. Without this, it's possible for a malicious device to decrypt WPA2 traffic passively or spin up a Rogue AP to capture traffic from peers.
And lastly -- firewall rules with default deny connect devices by policy.
That ap_isolate alone is not enough is kind of interesting, as it's possible to instead push packets to the router that will then forward to the client destination. Most off the shelf routers have forwarding on without a default deny policy, enabling this. The subtlety here is the attacker uses the router as the L2 destination instead of the other wireless client. At the very least attackers can send UDP packets to bypass the intended isolation. This bypass is especially powerful when changing mediums between Wireless and Wired as the Wired victim receiving packets will be responding back to the router, and on many consumer routers a full TCP connection will be possible then.
Soon we are planning to support an OpenWRT package that will allow people to link up into SPR from lots of APs, provided the AP card supports AP/VLAN mode which is critical for the segmentation.
We have no plan to work more closely with managing RADIUS right now, enterprise wifi authentication is difficult to deploy securely without client-side certificates for authentication. So that makes it less appealing due to our goal of supporting any kind of wifi capable device.
Lastly, SPR does have an upsell feature where we support leaf node APs running SPR that have backhaul into a primary instance.
I think SPR looks neat, it’s a more well-packaged version of essentially what I already do (albeit in a kludgey way), hence the curiosity about ambition.
Can it make it painless to manage multiple APs and to get fast roaming, etc working? UniFi pulls this off nicely — there’s nothing particularly fancy under the hood AFAICT, but it all just works. A more intelligent solution where clients got assigned to appropriate VLANs would IMO be extra nice.
(The enterprise vendors seem to have decent ACL and maybe even anti-spoofing measures for their wired networks, and they have some security features for wireless, but I haven’t seen anyone with a nice solution that makes wired and wireless security cooperate. I haven’t looked that hard.)
If only we could get the industry to move to this model, we could dramatically reduce the amount of congestion due to APs broadcasting multiple SSIDs.
The Nintendo Switch actually had a browser either at launch or close to it, then removed it in an update, and didn't add it back until about 3 years later.
It's really hilarious that a device that touted its portability from the beginning was literally incompatible with most public Wi-Fi for years.
We used to just login on our phones, then tether the work laptop to the phone over USB. The security people caught up to that a couple years ago and disabled USB tethering. So now I alter my laptop's MAC to be the same as that from the work laptop. That tricks about 90% of hotel wifi into allowing the work laptop to connect without need of a splash page. But for the other 10%...
(Not a joke, I do this) I sometimes login to the hotel wifi on my personal phone, tether that phone to my personal laptop, then setup that laptop as a router. The work computer can then connect to the wifi from the personal laptop, which tethers into the phone, which is on the hotel wifi. All of this just avoid another ridiculous wifi login page.
Does the OS not pay attention to DHCP option 114:
This document describes a DHCP option (and a Router Advertisement
(RA) extension) to inform clients that they are behind some sort of
captive-portal device and that they will need to authenticate to get
Internet access. It is not a full solution to address all of the
issues that clients may have with captive portals; it is designed to
be used in larger solutions. The method of authenticating to and
interacting with the captive portal is out of scope for this
document.
Why go through a laptop? Isn't this exactly what generating a hotspot from the phone does?
It has not: it's simply easier (less infrastructure) to not implement 802.1X.
Basically every corporate / enterprise-y password where you use your AD/LDAP credentials to log into Wifi has gone through the effort. Not everyone wants (or needs) to do that. (Source: recently implement 802.1X as IT when we moved to a new work office.)