This is how DefCon provides WiFi.
WPA3 Enterprise 192-bit mode at home
71–80 of 201 posts
Re: WPA3 Enterprise 192-bit mode at home
#72Earlier quoted context omitted.
I wish more consumer devices supported multiple PSKs on the same SSID. It's a handy feature much better for airtime than creating multiple separate SSIDs and much better for sanity than 802.1x user or cert auth.
> I wish more consumer devices supported multiple PSKs on the same SSID Could you name any enterprise APs that do this, short of running your own custom AP software? As far as I know (would love to be corrected on this), Unifi APs can't do this, and they're at the very least "prosumer".
It seems that feature has been added in a recent update.
https://community.ui.com/releases/UniFi-Network-Application-...
Re: WPA3 Enterprise 192-bit mode at home
#73Earlier quoted context omitted.
Yeah, this isn't really "running at home" - which is a bit disappointing as smallstep does good work on the foss/self-host side of things (I guess this shows their seller side). FreeRadius can help: https://wiki.alpinelinux.org/wiki/FreeRadius_EAP-TLS_configu...
I work at smallstep. Yes. This also works with FreeRadius! We decided to integrate RADIUS into our product since setting up FreeRadius is complicated and, if you're just doing EAP-TLS for Wifi, you don't need all of the features. You don't need to use our hosted RADIUS though.
Right. I think it makes a lot of sense to integrate Radius in your product. But the only way giving full trust to a third party ca could be dubbed "NSA-grade" - would be that it puts you within the reach of the NSA by way of an NSL to that third party?
(I'm not generally aiming to mitigate state level actors, but you put "NSA-grade" in the headline...).
Re: WPA3 Enterprise 192-bit mode at home
#74A do it yourself guide to stuff you shouldn’t do.
Re: WPA3 Enterprise 192-bit mode at home
#75I want to know why WPA3 doesn't have a mode where a password is used for the initial connection , but then the client and AP generate a keypair and each store their half and use that for all future connections. For all future connections, the AP can validate every client, and the client can validate that it is connecting to the same AP. The AP could have an interface to 'revoke' access to any single client if necessa…
> why WPA3 doesn't have a mode where a password is used for the initial connection, but then the client and AP generate a keypair and each store their half and use that for all future connections. Because it would regress security back to inferior bearer authentication.
It's only equivalent if "the password" is fixed and can be used for an indefinite series of "first" connections.
In contrast, imagine that the thing the guest enters into their laptop is a freshly-generated random code which expires within X minutes and can only be used once.
Re: WPA3 Enterprise 192-bit mode at home
#76I know the article is just "here's how", but I don't trust my wifi because of the hardware and software on it, so for me the protocol is irrelevant.
I work at smallstep.
For home wifi this is totally overkill. Better security is always nice but, in this case, there's a significant usability & interop tradeoff for home use (though that may change over time... we'll see).
For business / enterprise settings, this has real value. Distributing a password to everyone doesn't scale and alternative EAP methods have huge security problems. For managed devices, certs can be pushed and EAP-TLS can be configured easily. And it's all seamless for end users[1].
For example, EAP-TLS mitigates "evil twin" attacks, where a rogue access point broadcasts your SSID. If you're using something like EAP-PEAP, which is password based, the user is sending a password to the RADIUS server. If they connect to a rogue AP, they just sent their password to the bad guy. If the password is their LDAP/AD/Okta password, that could be very bad.
There are a variety of mitigations for this sort of attack but, without getting into details, EAP-TLS is widely considered the most secure option. So, yea, if you're relying exclusively on wifi for security you're doing it wrong. But that doesn't mean you don't need to secure your wifi.
Re: WPA3 Enterprise 192-bit mode at home
#77I'm just amazed that there's SCIF approved wifi. I assumed I'd be dead of old age before that happened.
I'll believe it when I see it. They don't cite where it suggests in any capacity that Wi-Fi is ever acceptable for Secret or TS data transmission. If this was approved for anything it'd probably be CUI information at most (ignoring the many issues with their actual implementation).
Re: WPA3 Enterprise 192-bit mode at home
#78Personally I've essentially given up on depending on WiFi auth for anything important. For general access, segmenting various users, IOT etc for performance, monitoring and light privacy WPA-EAP and PPSKs with VLANs does some work as an initial first layer fine and in a simple reliable way that works with everything. It's a low pass filter. But for all sensitive access I use internal Wireguard now. WiFi auth gets a c…
Would love to hear more about how you provision wireguard. I have a simple VLAN setup where I can open a tunnel from my "guest/home" network to my "lab" network (ie. docker hosts, desktop PCs that I use for development, etc) and a second tunnel from the lab network to the network that can access mgmt interfaces, however it's all mostly manual (ie. sudo wg-quick up in a terminal)
Somewhat related -- with the project I work on, https://github.com/spr-networks/super, we do support wireguard peers (and also support combining that wireguard identity with a wifi peer identity as well).
Devices are provisioned by assigning or generating a wireguard keypair in the API.
Next the peers are routed together by policy and by default can't access one another. There's support for bidirectional network groups or one-way firewall rules with NAT.
One area of improvement is multicast support with wireguard, it's doable, just not ready yet.
Re: WPA3 Enterprise 192-bit mode at home
#79> In the “When using this certificate” dropdown, select “Always Trust.” Shouldn't it be possible to only enable “Always Trust.” in the "X.509 Basic Policy" setting, instead of allowing the certificate to be used for everything(including SSL)?
On Mac (which the author appears to be talking about), I believe agreeing to Always Trust when connecting to a WPA3 network only enables it for the "X.509 Basic Policy" setting. I don't know much about how the different trust policies on OSX work though, and it makes me very uncomfortable that trusting self-signed root certificates may become more common for connecting to wifi networks.
If you do trust the root cert for everything, couldn't the access point MITM all your traffic?
Re: WPA3 Enterprise 192-bit mode at home
#80Earlier quoted context omitted.
And in this case the coverage would be even worse unless they duplicated all APs for both networks. It's probably much more cost effective to do what you suggest, and that's exactly what I do. Multiple SSIDs (one for the household, another for IOT stuff, another for work and another for guests) and control access via VLANs.
Is there a reason you split IoT stuff off of the guest network? On my network we just have a guest network which denies LAN access to anything connected to it, but I'm wondering if there's a good reason to split IoT off entirely.
There's a simple reason (among many) that I segment IoT from Guest: I guess my Guest SSID password regularly but don't wish to do the same for my IoT segments (plural, because one has WAN access and the other doesn't.)
For anyone wondering, the frequent changes to guest wifi password are offset by the fact that I make the password easily available to guests in the form of an NFC tap.