WPA3 Enterprise 192-bit mode at home
smallstep.comPersonally 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 client onto a restricted VLAN in the first place, but from there only a VPN will get to management webguis, sensitive services, or unrestricted internet access. Regrettably the design process for WPA3 was the same old mediocre industry affair. It's not worth trying to put many bandaids on vs just moving things to a higher level. As a practical matter WiFi also just isn't that fast vs high performance clients, it's not like WG has to handle tens of gigabits, so there isn't even any downside in performance.
WiFi auth at this point kinda feels like a polite lock on the screen door. Not useless at all, but anything really important should have other layers in front that are more secure by design from the ground up.
What is your threat model to warrant this effort at home? Are your work-related machines not networking through an encrypted tunnel in some other way (that would be a serious oversight!)? What government are you living under that is routinely compromising WPA3 from mobile vans? Are friends/guests so untrustworthy that you can allow them into your home but can’t trust the VLAN implementation of your network equipment to protect you from them accessing your network admin plane?
I’m asking incredulous and probing questions because I used to live life the way you are currently, and it’s frankly unhealthy for the human brain. If “home” feels like such an unsafe place to warrant your current measures, you need to either make serious changes to where home is, or your mental state. Neither is easy but at least one is necessary.
I imagine living in any decent sized downtown area would have your network being scanned by thousands of machines daily. Especially if near important infrastructure, law enforcement, etc.What government are you living under that is routinely compromising WPA3 from mobile vans?That is not enough for a threat actor to modify the network control plane with WPA3. There are tight timings involved. It is only enough to be able to passively capture packets that can be retroactively decrypted and even then if there isn’t TLS working on those packets you already screwed up worse anyways.
That's the wrong question to ask. Instead, we should be asking ourselves, why is it after all these years that we still don't have secure and easy to use multi-account WiFi networks with per-account configurable security policies in our homes? It's the current state of things that's unhealthy, not the people demanding better.
Security measures should be evaluated based on their own merits, not by appealing to friendship or any other relationships. We can lock our front doors and have a healthy relationship with our neighbors! These two things aren't mutually exclusive. Though I will add that trusting government authorities not to routinely abuse their powers is a hard ask given their track record all across the globe, even in democratic countries.
WiFi is ubiquitous and is used to exchange sensitive information 24/7. Its compromise can result in financial, reputational, or even physical risk. Considering that raw signals can be intercepted outside of our homes, devices on the network should at the very least be mutually authenticated and their connections encrypted.
Also, let's not forget about the devices too. Say you trust the people you let into your home. Can you also trust their devices and the software that runs on it? Do you trust your work laptop and its "security" software to respect your privacy? Do you even fully trust your own devices? Do you have faith in current commercial hardware and software to respect boundaries, or even comprehend the concept of user ownership? Because the answer to all these questions increasingly sounds like a "no."
> we should be asking ourselves, why is it after all these years that we still don't have secure and easy to use multi-account WiFi network
But that’s exactly what we do have! Any old router/AP combo you buy at the store or get from your ISP will let you set up a normal network and an isolated Guest network. All with a nice UI/UX that involves checking one box and choosing a password. Considering WPA3 to be insecure is just not rational or based in reality. Exploits against it are really complicated and just don’t happen all that much.
I don’t have to trust all the junk IOT devices that end up in my house because I just throw them on the guest network and call it a day. Nothing bad is going to happen to me as a result of this practice.
When I wrote "multi-account WiFi networks with per-account configurable security policies," I meant WPA Enterprise style networks. Having 2 SSIDs and 2 passwords is a horribly insufficient setup which doesn't fit my description. That feels just as secure as running a Tor exit node right in my home, since there's no separation in the primary network and the password is bound to leak the more you share it to people.
> unhealthy for the human brain
Fortunately, wired networking continues to work reliably, unlike frequently "New and Improved" wireless increments.
Honestly, wired networking can be less secure, depending on your threat model. Not everyone lives in some kind of a physical fortress; breaking into someone's house is usually a simple matter of some lock picks that you can buy off the Internet, then compromising the wired network just requires installing an interceptor, not to mention stuff like hardware keyloggers. The truly paranoid user needs to check all their wired connections before each and every use, which few people do. They will need to seal the cases of each of their machines with some kind of tamper-evident seal, with transparent cases to ensure that nothing has been added internally with countermeasures taken against the tamper-evident seal, including the cases on the video cameras that they have set up to try and catch would-be intruders.
The point remains, people either generally feel safe in their homes, or they don't. If you do, then honestly a lot of these security measures are just overkill. If you don't, then you should deal with the root cause instead of its symptoms.
> generally feel safe in their homes
The human occupants of homes and businesses may be surprised by IEEE 802.11bf through-wall imaging of human activity by WiFi 7 Sensing, including keystrokes, breathing, motion and location in rooms.
Should the sale of new wireless imaging powers come with vendor responsibility and liability to secure those powers, or should that be delegated to the feelings of customers?
Will an enterprise VPN be sufficient to protect corporate assets which rely on the integrity of devices located in WFH employee homes, with walls transparent to WiFi 7 Sensing?
You might be right, but this person might just be really intuitively good at network config and this is their hobby.
Thanks god for shitty wifi ranges!
>What is your threat model to warrant this effort at home?
Same normal one as everyone else in a connected world? I find this interesting and do the same stuff for both home and work. You make a lot of mistakes and wrong assumptions, but a big one is failing at all to consider cost amortization. You're assuming this is a burden, but that's backwards. I need/want a decent network anyway. I want to use open source for core areas to avoid actual problems I've had (not theoretical) with lock-in going wrong anyway. There is absolutely real work and cost in setting that up, same as a good NAS, virtualization (or home k8s clusters some people do or whatever else), etc. But once you do, the marginal cost of doing more stuff with it is tiny, which of course is some part of the whole value in doing it in the first place. It's absolutely wise to pick where one spends their time and resources with care, and I have zero issues with leaning on COTS and other professional in plenty of areas. Self-hosting is both something I enjoy, something I think is important/valuable, and of professional interest.
>I’m asking incredulous and probing questions because I used to live life the way you are currently, and it’s frankly unhealthy for the human brain. If “home” feels like such an unsafe place to warrant your current measures, you need to either make serious changes to where home is, or your mental state. Neither is easy but at least one is necessary.
This is a lot of projection and confusion on your part I'm afraid. None of this has anything to do with "feeling unsafe" beyond the basic ways perhaps we should given the state of smart home devices, cloud service dependencies etc, and how valuable our digital lives and monitoring of them now are. As far as security you've literally got it backwards though: moving to an open less complex higher layer is simpler, more practical, more reliable, and thus it reduces vs adds mental burden. I don't need to think as much about whether some new aggressive smart home thing is trying to scan my network and what issues it might have (they are, they do, and no I do not get total veto on what comes in vs family desires/needs), about making use of still good but now old and never updated kit, about issues in the network hardware itself (like when some UniFi gear was leaking traffic between VLANs [0]), about new surprises in WPA, ever more automated attacks, and on and on. A minute to setup a tunnel once and a lot of that evaporates for years at a time. It significantly reduces the surface area of stuff that is critical to stay on top of vs "eh, check on updates once in awhile".
None of this comes from the strange state you describe yourself as in, but from curiosity, interest, and reasonable respect for the amount of risk against both my own limitations and positive features that I want to take advantage of in my life. Indeed if I didn't consider my home, office, and other work spaces fundamentally physically safe that would undermine the foundation of self-hosting! But physically safe with great neighbors and so on is separate from the connection to the entire rest of the planet, and the various black box objects we bring into said safe home made by profit seeking multinationals capable of communicating without our approval over said connection to the entire rest of the planet right? I hope you're making progress though!
----
0: https://community.ui.com/questions/BUG-NanoHDor-broadcast-an...
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.
Tailscale. It's Wireguard under the hood but with a company doing got UX on top.
I’m familiar with Tailscale but could you provide more detail on how to use it as an authentication method?
The two ways I see:
On my home server, only allow incoming connections from the Tailnet. However, this seems lockout prone.
Or I could create a VLAN and put all hardwired devices in it. All running Tailscale. But this wouldn’t cover securing my laptop (has to be on WiFi in my situation). This still seems lockout prone?
Additionally, the router is still exposed “normally” and can be compromised without requiring VPN access
Sorry if this post is a bit of A mess. Thanks.
Maybe they expose the wiregard port through the firewall and VPN into a flat management network
For most stuff I've been comfortable with having my OPNsense gateways be trusted points, which has struck a reasonable balance for me between convenience, security, and compatibility. So I Wireguard into that, and from there it's normal firewall and routing in one place, with the ability to lean on hardwired subnets or VLANs so that the universe of old sensitive appliance things (like UPS interfaces) can still be reached. I have site to site wg tunnels between gateways as well. For LAN usage going through a central point has generally not been a significant performance burden, the only thing I have personally that is both very demanding and secure is iSCSI and there I've gone to the trouble of just physically isolating it. Going through a point also means there isn't much in the way of provisioning to do, each client just needs the single WG to the gateway for all (or most) traffic and that's it. Most stuff can be provisioned with ansible, a few mobile clients though I just use QR codes for manually. I should really try to figure out if Wireguard can be provisioned on iOS/Android with MDM but that's been a backburner so far.
I've started to play around with having some things go exclusively into a Nebula mesh with OPNsense only running a lighthouse, but it's more work and rougher. And unlike WG to the gateway and leaning on VLANs for some older kit, really putting everything behind a virtual network they don't natively support requires sticking a translator between them and the rest of the network. Fun to play with a little and the potential is cool, but I don't think there are any prebaked options as smooth and cheap as would be ideal for that, and I suspect the ROI there at my level is getting pretty dang low. IPMI access is the main place I think might be worth it since that's just so sensitive yet simultaneously so useful in resolving issues all while having extremely mediocre security on its own.
Whereas WG to the gateway does leave the gateway as a point of failure, but I'm depending on that to a significant degree for now anyway. And it is fast, simple, reliable, easy to manage/reason about, and eliminates layer 2 auth from the picture entirely. Don't have to worry about someone plugging into some open ethernet port either for example and any necessary effort to secure those, not just WiFi. Threats may evolve but hopefully the options we have to combat them evolve in concert to some degree. Lots of other HNers are vastly more experienced in this then me, and I'm not unaware of some of the potential failure points, but it's hard sometimes to figure out how to balance risk vs resources we have to spend on them (not just money but time).
Also there are other good gateway/firewall options like VyOS, or just working directly off your favorite flavor of Linux or OpenBSD or whatever, that might fit your needs/preferences/tooling better than OPNsense. I don't mean to suggest that it is the best choice, it's just what I've settled in on as a good balance of other values.
And here I just deployed 802.1X wireless and wired across our four hospitals. Maybe you’re not doing something right.
That's a good attitude. All the essential stuff should be end to end encrypted at this point. For example, if you use the web. All your connections are over SSL. Depending on how that is set up, your connections might leak some information about domains you are talking to. But beyond that it's just unreadable garbage for any man in the middle. So, how much does it matter if you use a public wifi in a hotel, airport, or some mobile phone network, etc. Answer: it mostly doesn't matter. Unless you are a network security expert; you should treat your home network with the same level of distrust as you would treat any other public network. You can't assume it to be 100% secure. No matter how many acronyms your router supports.
If you feel strongly about it use a vpn. Wireguard is nice for this indeed. And indeed some IOT has pretty shit network security so you might want to care about securing that in your home or office network. But beyond that, your exposure should be pretty minimal even if you don't use a VPN.
And reality check: most people aren't network security experts. I'm certainly not one even though I've been active as a developer for a few decades and kind of know what I'm doing.
So, IMHO WPA3 is a waste of time. I don't care about it. It might be more secure by some unknowable degree. But since it is unknowable (for me), I can't be bothered to care. I'd on principle treat it as just as insecure as WPA 1 & 2. Or no network security at all. Which is good enough for me to run my SSL connections over them. And even if it is super duper secure, I don't necessarily trust the Chinese manufacturers supplying the router chips and firmware to do the right thing. In my experience, the vast majority of routers run years out of date firmware supplied via a very shady chain of suppliers for chips and software that I definitely don't trust.
So, WPA 3 is a security blanket. A false sense of security. If you have reasons to be paranoid, go for it. It probably helps. Just like tin foil hats, Faraday cages, and all the rest. I don't use those either. But for the rest of us who aren't network security experts with operator supplied routers at home and working in office environments as well as on the go with random third parties maybe taking care about network security a little bit in the networks we connect to, I treat all networks equally: 100% untrusted. I don't care about what acronym soup applies to the network or how shit-hot the graybeard that manages it is. I just blindly assume network security is mediocre at best and connect anyway. For me network security is about being able to use my laptop safely in a completely untrusted network. Because that's where I use it all of the time.
We already have .1x which supports various auth methods such as certificate auth and can use policies to assign clients to VLANs
"NSA grade" irks me - to think these guys have your best interest at heart. In the 1970's they weakened DES [1]. In 2015 the NSA created a backdoor and pressured companies into installing it [2]. In 2016 you had the leaked tools stolen and used by the Shadow Brokers / Equation Group [3]. More recently the NSA made arguments against double encryption to combat weaknesses in potential quantum-safe encryption algorithms [4].
The point is that "NSA grade" likely means "NSA accessible". The major difference between WPA2 and WPA3 is the individual encryption. My guess would be that there is some backdoor during SAE and they could force a complete reconnect by temporarily jamming/disrupting all users on a network.
[1] https://arstechnica.com/information-technology/2013/09/the-n...
[2] https://twitter.com/matthew_d_green/status/14334701097425182...
On your first point, I’m not aware of NSA weakening of DES. Only in-fact strengthening it against differential crypto analysis. Your link seems to echo that. Were you thinking of something else?
Of course, the fact the NSA was aware of differential crypto analysis some years before the rest of us is another thing…
This I guess?
> Of course, the fact the NSA was aware of differential crypto analysis some years before the rest of us is another thing…
It is more a case that somebody else discovered it and they were forced to get in-front of it.
NSA. Is that the organization of unemployed mathematicians that thinks it is 1989? The group that can't crack the super secret algorithm of "https". Yeah, that is the one, the group that is puzzled by large prime numbers.
I know I shouldn't, but... https isn't an algorithm.
lol. I know. I should have used "for"
I 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 necessary, and single use passwords could be used too.
That would give all the same benefits as WPA Enterprise (after the initial pairing), and all the ease of use of a preshared key.
It's not unusual to run multiple APs on a single SSID. Your scheme doesn't work for that without coordination between the APs.
Also, it means replacing an AP would require reconfiguring all the clients.
You don't need active coordination for this. APs serving the same SSID could verify client certificates issued from any other AP by verifying that the certificate is signed by a trusted certificate authority. You'd just need each AP to use the same CA to issue signatures from.
You could give each AP its own intermediate CA tracing back to the same root CA to avoid sharing private keys and allow easily revoking certificates signed by a compromised AP.
You would only need coordination for revoking client certificates (but you can't really avoid that regardless of model).
Isn't coordination between APs something that Ubiquiti APs already do?
> Isn't coordination between APs something that …
All non-consumer grade (and some consumer grade) AP systems do. Ubiquiti isn’t first, unique, or best in this category.
Re: sibling comment, and no, WiFi Alliance isn’t what resulted in this working, you have it the wrong way around.
They have a rather clean implementation of standards called RADIUS and 802.11r, if that’s what you are talking about. It’s not unique to one manufacturer, that’s the whole point of Wi-Fi Alliance standards.
Couldn't it just fall back to the password version like it does every time now? Like optionally use the keys if present if not renegotiate
Is that any stronger than using a password if an attacker could force a connection to fall back to the password?
I'm guessing that's going to be an issue for handoffs between APs. Think walking around a multi-story office on a Wi-Fi call. Now picture 30 APs and 100 people on wifi calls/VoIP etc. with DHCP recycling addresses, randomized MACs and so forth.
Is there any obstacle to having a centralized server these APs talk to, which manages authentication? I'm not seeing a hard obstacle, just another piece of network kit and it's cheaper to keep a clunky UX
In theory I suppose. But you have to take into account that these APs can potentially be on different subnets, physical networks, talking across ipsec tunnels, dealing with multiple VLANs etc. There's just more overhead. It's easier to push out the info to the APs than to pull from who knows where.
Edit: For example: Say you have two buildings connected via an ipsec tunnel/static route. You have 4 wifi networks on 4 separate VLANs, 2 per building, guest and internal. Generally you'll have an internal wifi controller on an infra VLAN as well.
The wifi VLANs are not allowed to route to the infra VLAN, but infra can route to wifi. Rather than punching holes back allowing the the APs to talk to infra, you push out from infra to the APs.
you just described RADIUS
This is nonsense. If you are using WPA3 Enterprise across multiple AP, you need coordination, period. This comment raises zero significant concerns.
The parent suggestion is perfectly sound. More user-friendly means to mint certs would be grand. The caveat is that, if you can mint a cert from a low security password, what's to keep an attacker from attacking the password directly, rather than the cert? It might not let them snoop traffic, but it'd still let them on with the password.
Saying that it is like WPA3 Enterprise after the initial pairing is somewhat unfair. The trust in the initial pairing is a large part of the draw. The trust on first use model you describe is similar to using a self signed certificate on a website. Sure, after you connect and trust the self signed certificate your connection to the server can use the same algorithms that it would have used with a trusted CA. But for large deployment there is something to be said for being able to trust that you are connecting to the right infrastructure.
SSH does mostly fine with trust-on-first-use.
It is really not. It's only fine if accessing the wrong machine is considered less bad than access by an unauthorized user. Depending on what you'd upload or download, that assessment might differ.
You can already do this with hostapd under WPA3 or WPA2 - The password alone can identify each client, and activate different configs for each one.
Some commercial APs support this under different names but it's hard to make it work with RADIUS, which is usually necessary on larger installations.
But without preloaded certificates, the clients don't know that they're not connecting to a rogue access point.
Hotspot 2.0 was going to solve that part, but kind of died last year as the WiFi Alliance let their last KPI partnership die off.
> The password alone can identify each client, and activate different configs for each one.
That's interesting, first time I hear this. How would that be represented in the hostapd config file? Would it be WPA enterprise using a radius server, or would it actually use WPA-PSK?
Check the wpa_psk_file option in the main config file [1] which lets you specify a file full of PSKs [2], each with its own options like vlanid=X and keyid=X:
[1] https://w1.fi/cgit/hostap/plain/hostapd/hostapd.conf [2] https://w1.fi/cgit/hostap/plain/hostapd/hostapd.wpa_psk
Works with WPA2 or WPA3-Personal modes, but (if you didn't know) an attacker that sniffs a WPA2-Personal association can learn the password they're using.
I guess the problem is it's the same until after the initial connection. And it not even clear that it is strictly better. It probably is, but now you are relying on two schemes instead of one so if the second scheme is broken you are worse off.
shameless plug: https://github.com/spr-networks/super is a project I work on that makes it easier to handle per-device wifi passwords on a single SSID, and it supports WPA3
What would happen if you tried to reconnect to the network and the AP didn't have the pre-shared key? Presumably, you'd prompt the user and ask them if they want to connect. This is the same pattern as trust-on-first-use (TOFU) for SSH, except for non-expert users. It's a good thought but I think it'd fall apart in practice. You'd still be vulnerable to phishing / evil twin APs.
Because industrial grade encryption isn't for us plebs, comrade, but for the various ~government bureaus~ megacorps who deserve security.
But not you.
> 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.
That would be an improvement, but authentication would still be based on a phishable credential vs a cryptographic assertion, and ultimately exploited in the enterprise environment it was designed for.
The enterprise environment would run the more secure version of it, and the prosumer people would run the less secure version. Doesn't mean the secure version is any less secure
> However, if you want a home network that’s simple to configure, easy for your guests to borrow, hassle-free, and that all of your Smart Home gadgets can connect to, then you should close this tab now
Or do what I do: run multiple APs. I have my primary one, which is very tightly secured and monitored, and only gives access to my local VPN. I have a guest one, which is only as secure as any average AP and gets you internet access, but no access to my LAN. If I used "smart" gadgets that I couldn't really control and trust, I'd set up a subnet just for them alone.
You can run multiple SSIDs on the same AP and segment your networks with VLANs. No need to buy multiple APs unless you need the coverage.
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.
I guess it depends on what kind of friends you have, but assuming iot devices are insecure rubbish, I wouldn't want them on the same network as guests. But then again you might want to turn on client isolation for the guest network, so that wouldn't really be an issue.
Yeah, I have guests all isolated from the LAN already.
Client isolation means the clients on the network can't reach each other. This would prevent them from attacking each other or your insecure iot devices. Otherwise your friends will backdoor your security camera. ;-)
Yes, that's what I meant, I guess I don't know the terms: no one on the guest SSID can talk to anyone else on either network, only the internet.
I want my guests to be able to cast to my TV, add songs to the Spotify queue, etc. As far as I can tell, these sorts of features work via broadcast frames and thus require the relevant devices to be on the same subnet.
Things like my printer and wifi-connected grill live on a much more restrictive VLAN. (with some firewall rules to allow devices on the trusted network to still print to my printer's hard-coded IP address)
You can do it some routers (e.g. opnsense) that let you retransmit that (e.g. with UDP broadcast relay). The main downside is that you have to set it up for each type, and open ports, troubleshoot a lot, waste many hours, etc.
I used to do this but it became too much of a hassle.
I have a separate VLAN for things like security cameras with perhaps-dodgy firmware, and a firewall rule that drops connections that devices on that VLAN try to establish. They have no business connecting anywhere, when I want to see what they see I'll ask them.
I split it off and give it zero access to the Internet, it's strictly internal. Everything can talk to the IoT VLAN, but not the other way around.
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.
> Is there a reason you split IoT stuff off of the guest network?
I'd do it so that I could more easily prevent the IoT stuff from phoning home.
That makes sense. In my case, I don't have a lot of IoT, but what I do have is entirely cloud based—if there's no phoning home then there's no point to having the device.
Yeah this is what I do. Both guests and naughty cloud devices get put on the same LAN as everyone else but can only talk to the gateway and the internet.
OpenWRT offers this. It's a good strategy to buy devices supported by OpenWRT.
And to donate to OpenWRT, of course!
Yes, this is actually what I do. They're conceptually separate APs, so I talk about them as such.
This is exactly what I do. IoT stuff sits on its own AP attached to a jailed LAN.
So do you have to switch the wifi on your phone to access the IoT stuff?
No -- not the GP, but I have a separate IoT SSID and VLAN with a distinct subnet.
I run an mDNS repeater (or rather, my Unifi controller runs it for me) to allow discoverability across subnets. The benefit, such as it might be, is in the ability to use a stateful firewall between the subnets and that I can have a relatively secure PSK that I don't need to rotate when I rotate any of my other SSID PSKs.
Relevant to the article, I also have a WPA-3 Enterprise SSID, a WPA-3 PSK SSID and a WPA-2/3 PSK guest/children's SSID. The different subnets have different sets of rules for what they may access and which DNS settings are applied by default.
I'm guessing it's the same wifi network, just on a different vlan
Anyone can have access to my LAN. It’s not a security boundary, and pretending like it is means you can never safely connect to airport or hotel wifi.
> Because you need certificates, your Smart Home devices won’t support WPA3 Enterprise. Home printers won’t support it. A lot of things won't support it. In fact, it’s a miracle that some consumer-grade routers and access points support it at all.
It's not really a miracle. It's just much easier to do from the access point side because the whole authentication process is basically offloaded to the radius server. It doesn't add a lot of complexity to the actual access point or router. The radius server itself is usually not included with these solutions, they're just capable of talking to one. It's just an easy to achieve bullet point for a feature list.
On client devices however it's a huge pita building a mechanism to manage client certificates, the verification chain and related requirements. It also has to be able to verify the radius server's identity so it needs a full list of fully up to date root CAs (including private PKIs and a way to add them too) and be able to check their revocation. And you need accurate time while not actually having internet access yet. And then there's automatic issuing. Most businesses don't just hand you a certificate, it's issued on the fly by a company HSM after the client device first generates its private key and then installed automatically by MDM after it determines your device is trusted enough. Like obeying security settings like encryption, having the required Antimalware installed and updated etc. It's also automatically revoked if that is no longer the case.
If you just hand it to a user and let them use it wherever they want it's not a lot better than a password really. So nobody actually does this in the real world. So the endpoint needs to be able to talk to various MDMs which is certainly feasible on a phone or computer but not on a simple printer, IP cam or smart device.
> On client devices however it's a huge pita building a mechanism to manage client certificates...
Yep.
This is why "replacing" PSK-protected WiFi with EAP-PEAP, and open WiFi with EAP-TLS was absolutely THE way for the WiFi people to go. (With EAP-PEAP you have the option of setting (and revoking) per-device credentials. With EAP-TLS, you get an open-to-anyone network with data encrypted over the air.)
Despite what the nerds at Google would have you believe, using either EAP mechanism without verifying the cert of the RADIUS server is totally, completely supported by the spec. It's nuts that Google didn't (and maybe still doesn't?) let you operate in the "don't bother verifying the RADIUS server cert" mode, because in the EAP-PEAP mode it's no worse than standard PSK, and in the EAP-TLS mode it's strictly better than Open WiFi.
EAP-PEAP without certificate verification is a surefire way to leak incredibly weak hashes of used passwords.
EAP-TLS is generally a great practice, as EAP-PEAP is vulnerable to MITM issues (fix proposed in https://www.ietf.org/archive/id/draft-josefsson-pppext-eap-t... but never adopted).
For the use case cited -- blocking MAC spoofing, EAP-TLS doesn't quite solve it, it mainly only solves authentication. The outer layer is not wrapped with TLS and is instead based on an ephemeral session key. Additional work is needed to stop the spoofing. The RFC states explicitly that channel binding, which would help stop the MAC spoofing, is not implemented https://datatracker.ietf.org/doc/html/rfc5216. What it does prevent is a client from being man-in-the-middled.
What's even wilder is that on some access points, when set to bridge mode, with an upstream Radius Authentication Server, as described, they may be vulnerable to ARP spoofing of the upstream radius server IP. This is something we've reported to vendors and were told "won't fix". Names include Netgear and TP-Link, though we don't suspect all routers from them are affected by this. We have not tested with the unifi access point referenced in the article.
So to restate the attack, cause it's so ridiculous, you should know about it: an anonymous, unauthenticated wireless station associates without a password. Next it would begin the EAPOL negotiation but it instead then proceeds to perform ARP spoofing to claim the IP address of the upstream Radius that is supposed to only be routed over the uplink interfaces. Even without knowing the shared secret, it's possible for the client to pretend to be the radius server to the AP, and authenticate itself onto the network. One thing you want to be very sure of when setting up 802.1X Radius Auth, is that your access point is not going to be misconfigured to allow clients to do this.
> For the use case cited -- blocking MAC spoofing, EAP-TLS doesn't quite solve it
The idea would be to rely on the client certificate authentication and not use MAC filtering at all. For example, you could have an EAP-TLS network that's unrestricted and not let Mallory on it. Or you could use RADIUS reply attributes to put Mallory on a restricted vlan.
Why not just set up multiple SSIDs then? The devices connected to different SSIDs belong to different VLANs. Then you don't have to consider MAC spoofing or even deploy EAP-TLS: just give different devices a different password.
I'm sure there are simpler ways to deal with the use case in mind, but I think this article just wants to have fun with NSA-grade WiFi.
Right, although the article did not mention how to stop the spoofing. I started this thread to raise awareness and point out that the details around RADIUS can really matter here when not using a secure AP because some of the security assumptions about radius clients do lead to hilarious security failure
If you're doing EAP-TLS wouldn't the ARP attack you're describing fail at the client when it's unable to verify the RADIUS server's certificate?
Correct, a wifi station client would not be attacked this way. As for the radius client -- the answer is it depends.
For many radius clients used by a common consumer AP, it's been possible for the spoofed radius to just say "okay, authenticated" to authorize itself -- and the shared secret is never used. It's worth noting that RADIUS may use MD5 with that shared secret, which is vulnerable to cracking attacks as well but I have not had to go down the rabbithole that far.
It would be interesting to try this against the Unifi AP brand named in the article and see how it handles it. My understanding is they run a custom Openwrt image so maybe they provide source code.
Companies should be able to be sued for things like this (deliberately leaving such a big vulnerability there without even warning the customers).
It's actually maybe already possible to consider it a fraud
A middle ground in complexity is WPA3 with a unique passphrase per VLAN, which allows grouping of devices by risk, or even giving each device a unique identity for access control and traffic management.
OSS golang reference code is available, https://news.ycombinator.com/item?id=38402289
VLAN tagging per SSID is a valid approach as well if a router supports it. Thats a lot stronger than how many routers implement their guest isolation.
As for Multi-PSK -- the use case is creating micro-segmentation in a network with zero-trust, where the identity on the network is rooted in that password.
Without Multi-PSK, if it's not clear, every device that has the WiFi password can sniff encrypted traffic with WPA2, make a Rogue AP to attack WPA3 in case its in use, and can perform ARP spoofing on the network to interfere with other devices.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-...
I was very excited by this, but I found that some of my dumber IoT devices would refuse to connect to the network if it used PPSK. If I connect them to a separate SSID I use for IoT devices with a basic WPA2 PSK, they work totally fine, but I didn't dig too much so it could also be user error
I did not know that. Wow nice. Having so many SSIDs is drawing attention to all the equipment in my flat.
However I guess this feature is WPA3 only which means I'll still need the SSIDs for years to come :'(
The opposite in fact. It only works with WPA2 which means that you cannot combine it with Wi-Fi 6E or use it on any WPA3-enabled SSID.
Ah ok, strange that the feature is only becoming mainstream now (as in added by Unifi, and I never heard of it before). It's very good to hear actually because most of the devices I want to have on separate VLANs are quite dumb (IoT home automation stuff in particular) and they won't have WPA3 (and often even only have 2.4Ghz).
Aruba, Cisco, Extreme, Mist, Ruckus. The first I saw use it was Aerohive (now part of Extreme) and it took the enterprise market by storm about 5 years ago. For most enterprise deployments 802.1x (either username+password or certificate) makes more sense but once you get into BYOD land (say, senior living) not all devices support that (say an Xbox) but you still want to give a user a way to connect anywhere they go not just their main living area. Similar with the BYOD network on schools, give out the PSK to anyone staff and a year later the kids all have it and you have to change every PSK only device to a new PSK manually to fix it. Use multiple PSKs to give different groups of devices different PSKs, and even different staff different keys, and you not only contain the problem but can actually narrow down on the worst leak offenders as well.
Doing multiple PSK / PPSK is not compatible with WPA3 (at least as supported by most APs today*, as WPA3 requires management frame encryption), so you limit to WPA2 only, therefore you're better off just having multiple SSIDs with WPA3 support. (Also that way you can have a "secure" network which is WPA3 Personal only, much easier than using WPA Enterprise and gives a reasonable level of security for home use.)
*: In theory password identifiers (https://www.gabriel.urdhr.fr/2022/06/07/impact-of-the-differ...) could be used with WPA3-SAE, but I don't know how good the support is currently...
hostapd has supported multiple SAE passwords and identifiers since 2019; it even allows to bind a password to a specific MAC address and VLAN id. Since most AP software is just hostapd wrapped up in some GUI, if they don't support these features it's probably just due to lazyness on the vendor part.
My home network is so small I just use MAC VLAN policies on my managed switch. Same SSID and PSK for all devices makes it easy and they all go off onto the untrusted VLAN by default.
That's an interesting idea, but it seems (without having played around with it or knowing you specific setup) like it comes with some security tradeoffs. In particular, MAC spoofing would be an effective way to VLAN hop, if not necessarily a threat you're worried about. It also seems like there is a possibility that devices connected to the same AP could talk to each other without having to go through the switch, bypassing the VLAN tagging entirely.
I'm honestly not sure if the second attack would work or if it would be AP specific, but I imagine most Wifi to wifi traffic through the same AP does not make a round trip through the Ethernet port. This wouldn't be an issue if the AP itself was applying and enforcing VLAN tags, but the MAC spoofing problem would still be an issue.
TS information over wifi? Ok. Have fun with that. Im sure it is legally possible somehow, but it just creates a ridiculously large attack surface. And the internal hassles, making sure connected machines are inside defined perimeters ... just run some wires. It isnt like people need to be reading classified stuff on the treadmill.
The "NSA-Grade" part mostly comes from the application of AES-256 as a cipher, where specific configurations of AES were approved as "Suite B" (i.e. published algorithm) ciphers suitable for up to Top Secret information.
From https://en.wikipedia.org/wiki/NSA_Suite_B_Cryptography
The Suite B algorithms have been replaced by Commercial National Security Algorithm (CNSA) Suite algorithms:
- Advanced Encryption Standard (AES), per FIPS 197, using 256 bit keys to protect up to TOP SECRET
- Elliptic Curve Diffie-Hellman (ECDH) Key Exchange, per FIPS SP 800-56A, using Curve P-384 to protect up to TOP SECRET.
- Elliptic Curve Digital Signature Algorithm (ECDSA), per FIPS 186-4 Secure Hash Algorithm (SHA), per FIPS 180-4, using SHA-384 to protect up to TOP SECRET.
- Diffie-Hellman (DH) Key Exchange, per RFC 3526, minimum 3072-bit modulus to protect up to TOP SECRET
- RSA for key establishment (NIST SP 800-56B rev 1) and digital signatures (FIPS 186-4), minimum 3072-bit modulus to protect up to TOP SECRET
The CSfC program defines a WLAN “capability package”[0] for just this purpose.
[0]: https://www.nsa.gov/Resources/Commercial-Solutions-for-Class...
Does the NSA use WiFi at all other than for clandestine collection systems in the field?
Yeah, they put out an article a few years ago talking about how a limited number of SCIFs have WiFi now
Do they broadcast an SSID? They can't have "NotYourSCIF". That's my home network. Someone else is the building is using "FSB_BugsNet". Another local one i see is "CEyeA".
To be compliant with NSA TEMPEST regulations, the SSID has to be set to FBI_SURVEILLANCE_VAN_69
SCIFs are already shielded for EM, so any Wi-Fi inside of them shouldn’t make it outside of them anyway.
It's not official until you change the MAC OID to 00:20:91 as well.
WiFi and other wireless protocols seem like an elaborate, yet wildly successful, plot to make consumer comms as insecure as possible.
Erroneous assumptions, half-truths, and a clickbait headline have historically never been a barrier to getting to the top of "Hacker" "News".
The title should be enterprise-grade Wi-Fi because the idea of closed-source, foreign-made COTS APs trafficking classified data is hyperbole only.
It makes me sad that even WPA3 doesn’t have a native provisioning mechanism. In a better world, a device would present its MAC address, some description of itself, a public key, and optional extra data (e.g. an attestation of the hardware security backing its keypair, and the network operator could, at its leisure, accept this device. Then printers, smart devices, etc could join without needing to each support an MDM or other proprietary provisioning system.
Also, if you care about availability, don’t use a cloud RADIUS server — if the server or your ISP or your route or the relevant part of your network goes down, there goes your WiFi. If you’re using 802.1x, your wired network is toast, too.
> It makes me sad that even WPA3 doesn’t have a native provisioning mechanism.
And that's how you get spoofing management frames, deauthing, and all sorts of fun attacks.
Cause the moment you talk to unauthenticated and unencrypted machines, well, yeah. Payday.
So you cant do that, even if you really want to.
Huh? Almost every cryptographic session protocol starts out with the parties sending unauthenticated data of some sort to each other. Having a way for a party to send a blob as part of its request to be let in is straightforward.
Plus we’re taking about WPA, which, AFAIK, still uses a horrible hack for EAP even in WPA3, and as you can see mentioned elsewhere in the comments, EAP makes a pretty strong showing in its quest to be the worst widely-used example of giving an unauthenticated party actual access to the network as part of the authentication flow.
Doing this right is not that complicated.
Their was a defcon or a blackhat talk on this issue. Even though the data might be encrypted....developers can leak so much metadata via the handshake that you can build profiles and track devices
The entire point of what I’m suggesting is to have a device identify itself.
If you set your phone to randomize its MAC address, then it should not send anything that specifically identifies it. If you ask your printer to connect to your corporate wireless network and you tell it to use WPA4-self-provisioning or whatever it’s called, then it should fully identify itself. Also, it’s a printer, and anyone in WiFi range is presumably privy to its existence.
Sure, if someone else spoofs the network, then they might collect the printer’s provisioning info, but one way or another the printer needs to decide to trust whatever network it ends up connecting to. And with a sufficiently well designed protocol, if the printer connects to the wrong network, then the owner of that network can’t actually impersonate the printer to the real network, because the derived keys won’t match.
> Toggle the switch on the Smallstep RADIUS Root CA to enable Full Trust. The Smallstep RADIUS Root CA is now trusted.
What could possibly go wrong?
How do you do this without trusting some external CA?
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...).
Well... the title is hyperbolic (as titles are wont to be), but the goal was to configure Wifi that aligns with the CNSA Suite[1] / CNSSP 15[2], which I think is fair to call "NSA-grade" since they wrote the standard.
If the NSA wants to get a certificate that your system trusts there are already dozens of organizations with root certs in your system trust store that they can strongarm. Most organizations can't afford to have the NSA in their threat model. You better not be using public clouds, GSuite, Okta, Azure AD/Entra, etc. This is a difficult security posture to maintain, especially at scale.
For most organizations, delegating the operation of sensitive security infrastructure to a third party results in better security, not worse. Yes, you're trusting a third party. But you're also outsourcing sensitive security operations to experts.
And, we also have on-prem and open source if you really need something air-gapped ;)
[1] https://en.wikipedia.org/wiki/Commercial_National_Security_A... [2] https://www.cnss.gov/CNSS/issuances/Policies.cfm
Historically, cryptosystems are broken through weaknesses in key distribution, not by cracking the encryption outright.
Correct.
> And, we also have on-prem and open source if you really need something air-gapped ;)
You support a self-hosted foss solution that enables on-prem wpa3 eap tls?
it's worth noting that hostapd has a built-in EAP server as well for running Radius. check the config sample for "EAP server" https://w1.fi/cgit/hostap/plain/hostapd/hostapd.conf
As for securing them, there's several labs security researchers provide for breaking into "enterprise wifi"
https://github.com/sensepost/shinai-fi https://github.com/r4ulcl/WiFiChallengeLab-docker
right!? i was hoping this would be a guide with something like freeradius and letsencrypt/acme to handle certs instead of yet another rando “free until we go under/get bought” saas service
You can roll your own with https://github.com/smallstep/certificates. We maintain major open source projects and contribute a lot to other projects. I don’t think that means everything we do has to be open source. Sorry this one wasn’t. Doing this in pure open source would be a book, not a blog post.
Love Let’s Encrypt — we’re sponsors — but using them for WiFi is a terrible idea. You need internal PKI for WiFi.
> You need internal PKI for WiFi. [Let's Encrypt-issued certs are a terrible idea.]
If you're talking about Centrally-Managed Enterprise WiFi, sure, agreed. Feel free to stop reading this comment, as my objections are only relevant to the home WiFi scenario.
If you're talking about home WiFi, then no, absolutely not. With the state of the world as it is (particularly with the various inbuilt CA distribution mechanisms being in the state they're in) I could not disagree more.
Remember that in the home WiFi case, you're replacing a system that does absolutely no verification of the AP that the supplicant is connecting to. So, in the case of EAP-PEAP replacing non-RADIUS PSKs, you're no worse off, and the case of EAP-TLS replacing Open WiFi, you're strictly better off... even when the supplicant does not verify the identity of the RADIUS server it's speaking to.
If I could have my guest scan a QR code (or have me read a number to them for them to enter) to get my CA into their "only trusted for the SSIDs I assign it to and only those SSIDs" cert store, then, sure, passing along this overly-large PSK would be an acceptable burden. But as it stands now, if I don't choose to use a TLS cert issued by an already-trusted CA I have to do one of the following:
* Do some sort of corporate provisioning thing that requires a lot of configuration of the client device. ("Why is this so complicated? You know what? Forget it, I'll just use my cellular connection. What the fuck is wrong with you that you make this so complicated?")
* Have them use some alternate network connection to download my CA cert, then go through the multi-step process to load it into their trust store and blah blah blah. (See the previous bullet point for the guest reaction to this process.)
* Put the CA on removable storage, hope that their phone can USE that storage, and walk them through putting the CA where it belongs. (Again, the guest is simply not going to do this and think I'm an idiot for making it needlessly complicated.)
* (I'm not sure this one is even possible, but I mention it for completeness' sake) Use some Phone App that can pull down a CA from the servers of some VC-funded startup and load that into the phone's CA trust store.
While my guests might actually do thing #4, thing #4 is for me a non-starter. I live in a large city, have lived in small cities, and have also lived in The Country. The number of times I've had someone successfully attempt to impersonate my wireless network infrastructure is zero. The number of times I've had services provided by some company (whether a startup or a BigCo) be discontinued or otherwise changed to become entirely unsuitable for purpose is far, far larger than zero.
If we had a widely-deployed, reliable, inbuilt CA insertion mechanism that normies could (and would) use, then sure, these privately-generated PSKs would be not crazy to use in home networks that you expect normie houseguests to connect to. But with the sorry state of the inbuilt "Add a new CA cert" tools, the habit of companies that produce useful consumer-focused tools to either bait-and-switch, or just evaporate after a few years, and the real-world infrequency of folks doing attacks on home WiFi networks, using a cert signed by an already-trusted CA like Let's Encrypt is the best option... if your supplicants DEMAND that cert checking be enabled.
The article borders on irresponsible by not explaining the full implications and risk of trusting a root CA, even if you're its sole private key custodian.
I work at Smallstep.
In this case you're getting an industrial-grade CA with a properly managed private key, etc. Still, fair. We usually include warnings about this, but looks like we forgot this time. Curse of knowledge. I'll see about getting a warning on there asap.
I would like to see something like this for “home” setups but it would have a much better user experience:
1) user attempts to connect to “home-wifi”
2) owner of “home-wifi” gets notification to confirm or deny access request
3) owner can optionally verify further
4) if approved, then between AP and client device it will create the client certificates with short expiration dates
5) if denied, then no access granted.
6) if user tries to connect multiple times and gets denied for all of them, then their device is blacklisted. No notification.
No more passwords. Minimal friction to adoption.
Wardrivers with sufficient randomization to avoid any denylist you implement will get very annoying if you let those notifications interrupt you. Maybe only receive such requests while you expect guests.
You could just not have notifications.
I'd be fine with a system where when someone tries to connect to my network, I need to open an app or go to a web page and pick from the list of attempts to allow.
It's not perfect, and it still leaves open a DoS by filling the DB with spam, but at that point you know something is wrong.
That seems unlikely to be something I'd ever encounter and solved by muting requests after too many in a row. Yes, a local attacker could DoS the convenience features for my guest wifi. That's fine.
That would be the best way. Turn on notifications when you're expecting a new device. Turn off notifications and auto-deny the rest of the time.
Hi- Did you release your edtech iOS app (the SwiftUI one you posted about)?
Just saw your reply today. That's an excellent memory you have. Surprised anyone remembers me talking about it.
I am still working on it. Just in my spare time. Maybe a release later this year if everything else works out and I can keep focus. Keeping focus is the difficult part, of course.
Annoying yes! And I do like your solution (only get notification when expecting guests). But also would be nice to keep a log of those requests.
APs only have so much range (and I think you can configure it to cover a specific area). So can very easily find out who or what is trying to get in.
It’s a crying shame that WPS was fumbled so hard. It was a consumer friendly idea.
That was the “touch a button on the router” to connect, right?
Idea was great in theory but in practice routers were often placed in the most inaccessible parts of a house (closet, ceilings, or walls)
How do you think that blacklist would work that can’t be trivially rotated around by changing client identities?
> if user tries to connect multiple times and gets denied for all of them, then their device is blacklisted. No notification.
Blackhat 2026: WPA free(not three) Enterprise, how to flood and bypass WPA3 with certificate forgery and dual pair attack in 5min!
If you want do do this 100% locally it's pretty easy with Pfsense/Opnsense combined with the Freeradius plugin. You can create your CA, hook it up to Freeradius, and create accounts and certificates all from the GUI (if you know what you're doing). As a bonus you can use the same certs with say the built-in OpenVPN system, and revocation of certificates is handled seamlessly in the UI as well. Personally I found it much simpler than doing it by hand with OpenSSL commands, which I used in the past when I had a smaller deployment.
The great thing with WPA Enterprise is that you can assign VLANs based on the client's login, just like a 802.1X switch. For instance my phone is sent to one VLAN, my company laptop to another, and my personal laptop to another. I can use a single SSID and get all the benefits of a multi-VLAN setup. For guests I provide a username and password for MSCHAPv2 authentication, while family devices are issued full certs.
What about IOT devices? I generally only use commercial wired gear (IP phones, cams, etc.) anyways with no internet access, and I'm of the belief that if it doesn't support WPA-Enterprise it shouldn't be on the network in the first place :). So that rules out all those data-mining smart speakers and so forth.
Just run FreeRADIUS yourself. If you need your own PKI to generate certs in a manageable way, there is OPNsense [0] or smallstep's FOSS step-ca [1].
Friends don't let friends delegate AAA to an external provider like Smallstep or SSO to Okta. While outsourcing to a third party is fine for a limited test, it's not fine for anything enduring.
Once upon a time, when open, spoofable WiFi was the norm, there was a collective WiFi sharing app that took control of retail WiFi routers with WPA1 enterprise RADIUS support called Radiuz. [2]
1. https://github.com/smallstep/certificates
2. https://web.archive.org/web/20040617153148/http://radiuz.net...
Because the requirements of "192-bit mode" for WPA3 Enterprise fall on not only the actual WiFI but also the backend identity providers, you are explicitly not allowed to do this for Eduroam unless you also provide a parallel WPA2-style (thus WPA3 compliant but not "192 bit mode") WiFi for everybody whose home institution isn't the US government.
Lots of institutions have Eduroam set so that students (and academics, and everybody else like me) are just authenticating against their Windows domain controllers, so going to "192-bit mode" would mean ripping out a bunch of stuff, replacing it, writing fresh documentation, testing thoroughly and then authorising, but since we're talking about the backend every educational establishment in the world would need to do this before you can ship WPA3 192-bit mode. So, that's not going to happen.
???
This is a dude playing with his home wifi. 192-bit WPA3 Enterprise is not for every use case, nor does the author or anyone else make this claim.
Your comment seems misplaced.
Sure, it's just interesting because this seems like just a straight up good idea for authenticated WiFi, but because of the need to significantly change the identity backends it's actually not practical for large federated systems like Eduroam.
I think this is generally barking up the wrong tree and addressing the wrong attack vectors for home wifi.
An actual over-engineered home wifi looks like this:
1. Use, at the very least, prosumer grade router access points. I use *sense and Aruba access points, but you don't need to get this serious.
2. Use heavy DNS filters. This will block a lot of malware by itself. Quad9 DNS is a good starting point.
3. Use a secure wifi password.
4. Don't enable upnp, etc.
5. Don't enable ssh or any kind of remote access.
6. Don't open any ports to the outside. This is the default ruleset for pretty much any firewall.
7. If you ever have guests who require wifi, segment these users on a guest wifi or vlan.
8. Reduce your reliance on wifi-powered devices. Favor zigbee smart home devices over wifi devices.
9. (Optional) segment your IoT devices on a vlan.
10. (Optional) use some kind of security package that includes layer 7 monitoring on your LAN.
11. (Optional) use some kind of security package that includes IPS/IDS.
Items 4-9 accomplish nothing. Your LAN is not a security perimeter. This ain’t token ring.
You work with reality as it is, not as you'd prefer it to be.
A home router is generally protected on the WAN side.
Your threat model is to secure connections originating from the LAN side, which is the only way a threat actor can establish a connection into a default deny network.
Connections into hosts on your LAN doesn’t gain an attacker anything, otherwise it would be unsafe to connect your laptop or phone to hotel, coffee shop, or airport wifi, and it’s not.
TLS 1.2 and not 1.3?
Could a swore we moved to 1.3 a while ago
Also many I'm just not familiar enough with cryptography but that key size seems kinda small.....am I wrong?
Ik RSA uses a different algorithm but RSA it isn't uncommon to see keys 1024 or larger in size. I generated a key of 65,536 and 131,072 bits a few times to see if it would work or break any applications I was using. Also just to I can say "yeah back in my day we generated keys way bigger" cuz I know at least 1 other person in the world did it.
Is their any standard for securing a network both wired and WiFi using a post quantum algorithm?
Also where can I easily find switches that support these standards? AFAIK wpa3 enterprise dosnt always mean this standard is supported....or that some other standard is supported. Is their some database that lists every router/AP and the supported features?
To get 192-bit security with RSA you'd need 7680-bit RSA key and with ECC you need 384-bit key as mentioned in the article. That assumes classical attacks only. For quantum attacks, the smaller key sizes used with ECC do make it weaker.
I haven't gone quite this crazy, but I do have three SSIDs broadcast from my UniFi APs - my main network (WPA3 PSK), a guest one, and a devices network for IoT devices. All these are on different subnets/VLANs and firewalled off from each other.
A lot of the IoT stuff doesn't work with WPA3 or 5GHz, so it's useful even for that reason, but the main thing is screening them off from everything else.
I am setting up a NUC as a little home Proxmox server (for some other stuff mainly) but for "fun" I can actually see myself setting up a Samba 4 Active Directory domain controller and hooking FreeRADIUS up to that to do Enterprise for my main SSID, but we'll see!
> 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?
Not only MITM traffic, but also run arbitrary software since it could also govern code signing.
I work at smallstep.
Not sure about the RADIUS server, but connections to the CA use TLS for SCEP and/or ACME DA so the CA root cert needs to be trusted for TLS. There may be some way to configure more narrow trust for just this one interaction, but I'm not aware of any such mechanism in the current releases of macOS/iOS/iPadOS/tvOS.
> Why is NSA-grade Wi-Fi called "192-bit mode"?
I believe this is due to the use of SHA-384, which is described as having 192 bits of "security strength"[0] against collision.
[0]: https://csrc.nist.rip/library/NIST%20SP%20800-107%20Recommen...
Well, that means I couldn't use my iPhone from work at home as it blocks installing certificates.
But, while not NSA approved, WPA3 itself has support for per-device passwords with WPA-SAE [0] (which isn't called WPA-METRIC outside of the USA...).
[0] https://en.wikipedia.org/wiki/Simultaneous_Authentication_of...
On the topic of WPA3, I recently found that the old iPad 2 or 3 doesn't connect to wifi if it's set to WPA3+2, it only works in pure WPA2 mode. Tried on two different AP vendors, though I have no idea if they might use the same chip or driver or something. It's the only device that didn't work in this mode, everything else was fine, including some whacky iot devices like picture frames and an inverter.
You’re sure it’s not actually the PMF setting causing that? More details here: https://www.reddit.com/r/Ubiquiti/comments/rq6jtr/psa_if_you...
Hm, in that post they say all of the 2.4ghz devices had the problem, while in my case it was just the iPad, and it was broken on both bands. But maybe it still was this (or a similar) issue. I only have access to one of the two APs right now, and there is pretty much nothing configurable regarding WiFi security apart from selecting from WPA1+2, WPA2 only, WPA2+3.
I'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).
As someone noted above the Commercial Solutions for Classified program has been in existence for a long while (probably over a decade). This package is newer but not wildly newer. Installs of the various 'packages' do exist.
Huh interesting. I can't imagine where people would willingly use it.
The white house scif is pretty laissez faire as far as SCIFs go and I imagine there's a whole pile of stuff from Maryland monitoring everything in another room nearby. I can see it being used for ipads for principals as it might be easier to police than stacks of paper.
Yea I wish I could run my router with PMF enabled and WPA2…so many devices do BOT support such options…specially WPA3
> Once you’ve installed the profile, we once again need to manually tweak trust settings. This time to explicitly enable Full Trust for the Smallstep RADIUS server’s root CA. Again, this is not true for a full MDM enrollment.
Do not download and install and fully trust root CAs from anyone on your iPhone.
Unfortunately the article doesn't explain how to setup a RADIUS server for EAP-TLS.
But there's a link so you can lease one in the cloud...
If you want to self-host, see eg:
https://wiki.alpinelinux.org/wiki/FreeRadius_EAP-TLS_configu...
I try not to use wifi as much as possible, but when I do, I connect through it to my home VPN or similar and take it from there, so even if the wifi is compromised, there’s an extra layer of protection there.
I 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.
PEAP can still require a trusted server certificate -- getting set up with MDM is a pain, and scaling by hand is also a pain, but you can (and I do) set up my devices to require a specific valid SAN on the RADIUS connection. No extra certificate trust required, if the RADIUS server has a certificate that chains up to the default trust store.
I remain disappointed that there's no standard mechanism for mapping between an SSID and a domain name to know which SAN to trust.
Just to clarify, are you describing EAP-PEAP or EAP-TTLS wrapping PEAP? I'm still learning a lot of this stuff... but, my understanding is that PEAP doesn't do TLS but TTLS + PEAP does. Right?
Fact remains, though, that users will probably bypass any certificate warnings (if allowed) and send their passwords to rogue APs. EAP-TLS mitigates this. Definitely pros & cons, but that's a clear win for EAP-TLS.
There are a lot of things that'd be nice to see in Wifi. Binding the SSID is an interesting one, though I suspect the folks working on this stuff were reluctant to rely on (and trust) the Web PKI CAs. If you're gonna push your own root cert, you might as well push a RADIUS SAN along with it, I guess.
I have EAP-PEAP wrapping MSCHAPv2[1]. You might still be learning, but I suspect you already know more than I do about this stuff because I pretty much just stuck the right settings into the Unifi controller and poked at it until it started working :).
On Android, I set "use system certificates" and "Domain: radius.jumpcloud.com"[0]. On Mac, I'm given the option to verify the certificate and I can see that it chains up to their publicly-trusted CA. The vendor seems to assume that I'll be hard-coding their certificate in my MDM, but I've not needed to. The Mac wasn't happy when the certificate was rotated, but the Android and Linux devices I have were perfectly content.
My AP controller also has a valid certificate, but it's not in play. As a user, I need a username and password for MSCHAPv2, and to convince the client that the certificate is OK -- which is easy, when the client is willing to use the system trust store :). I'm not provisioning client certificates, so I don't need to generate a root for that purpose. And it's for home, so I only need to worry about provisioning for two people.
I really don't like setting trust bits on root certificates, even ones that I generated myself. Been there, would prefer a bit more certainty that I'm not being spoofed by my own leaked root certificate. I'm much happier trusting Web PKI than I am trusting anything of my own that's sufficiently accessible as to be usable for this kind of thing.
[0]: Yep, I'm using a hosted provider that's not your employer, sorry :P.
[1]: WPA-3 SAE is nice, and it would be really nice if we could use something including that for the EAP. SAE solves the spoofing issue for non-Enterprise use-cases, unless someone trusted with the key goes rogue. Per-user SAE could mean that the rogue user can only spoof themselves, I think?
Do these enterprise modes have any advantages when it comes to connection reliability?
Absent 802.11r, they might improve hand-off between APs.
The disadvantage of WPA Enterprise though, especially with a hosted RADIUS server, is that it's somewhat more difficult to gain access to the network to fix things if they're broken -- if your internet connection is down then you can't authenticate, and if you can't authenticate then you can't fix whatever broke to bring the connection back up. I suspect you can guess how I discovered that problem :).
So overall: no. There might be a small increase in reliability in regular use (although I've not been able to tell the difference), but the reliance on an extra service makes for less reliable connections overall.
You're not going to increase connection reliability/extend your wifi range by enabling radius. If you have any understanding of what's happening here, you wouldn't even ask this question.
What I’m wondering has nothing to do with signal strength. I’m wondering if the protocol differences have any effect on reliability in situations where the wireless connection is less reliable. Because, for example, there’s less negotiation on reconnecting to the network or something.
After all, reliability is a cross-cutting concern :)
Unfortunately it's hard to beat a PSK based exchange in terms of quick connection, particularly with something like this where the authentication server is moved external. The difference in reconnection time is, in general, extremely marginal though. If the Wi-Fi is bad enough your client thinks it actually needs to reconnect instead of retransmit the only meaningful respite is to solve that problem directly.
Instructions ... yeah, not bad. It's essentially WPA3-Enterprise with possibly 192 bit set up. I like WPA3-Enterprise, it's really sufficient for most people when one moves to discontinuous permissions on a network. That said, after developing WPA3/Enterprise/192 for a platform out there, it's really very very restricted - and there were very few clients at the time that supported the combinations of security authentications required. Oh, also roaming clients is somewhat restricted (by no fast roaming protocols, at least as of the last time I went through the specs).
Here's specifics, using hostap/wpa_supplicant style configuration: key management WPA-EAP-SUITE-B-192. (but then they talk about that); pairwise=GCMP-256, group_mgmt=BIP-GMAC-256; EAP=TTLS;
I mean RADIUS support isn't that hard - freeradius will do. TLS - well, need valid certs that work for EAP. (it's not as specialized as Passpoint/Hotspot-2, which requires custom certs that must be validated by a specific CA, but it still takes some steps). My own experiments across a number of clients showed that GCMP-256 support for pairwise and group management weren't that common before Wifi-6 took off. Suite-B 192 though isn't so hard to reach.
Hostly, I prefer WPA3-Enterprise with Fast Roaming. Sadly, typical household devices didn't work well with it (mixed with android devices, generally no for printers and other IOT), so I went back to two networks - WPA2/Personal with PMF=optional for those annoying devices that don't have working PMF, and WPA3/Personal for most devices - at least for household operations.
A do it yourself guide to stuff you shouldn’t do.
This is how DefCon provides WiFi.
Use EAP-TTLS
>NSA
>Wi-Fi
No.
this guy is a good writer