WPA3 Enterprise 192-bit mode at home
smallstep.com
smallstep.com
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.
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.
What government are you living under that is routinely compromising WPA3 from mobile vans?
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."
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.
Fortunately, wired networking continues to work reliably, unlike frequently "New and Improved" wireless increments.
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.
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?
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...
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.
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.
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.
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.
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...
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.
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.
Also, it means replacing an AP would require reconfiguring all the clients.
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).
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.
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.
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.
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.
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?
[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.
But not you.
Because it would regress security back to inferior bearer authentication.
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.
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.
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.
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.
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)
I used to do this but it became too much of a hassle.
I'd do it so that I could more easily prevent the IoT stuff from phoning home.
And to donate to OpenWRT, of course!
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.
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.
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.
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.
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.
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.
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.
It's actually maybe already possible to consider it a fraud
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.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".
https://community.ui.com/releases/UniFi-Network-Application-...
However I guess this feature is WPA3 only which means I'll still need the SSIDs for years to come :'(
*: 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...
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.
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
[0]: https://www.nsa.gov/Resources/Commercial-Solutions-for-Class...
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.
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.
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.
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.
What could possibly go wrong?
How do you do this without trusting some external CA?
FreeRadius can help:
https://wiki.alpinelinux.org/wiki/FreeRadius_EAP-TLS_configu...
(I'm not generally aiming to mitigate state level actors, but you put "NSA-grade" in the headline...).
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
You support a self-hosted foss solution that enables on-prem wpa3 eap tls?
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
Love Let’s Encrypt — we’re sponsors — but using them for WiFi is a terrible idea. You need internal PKI for WiFi.
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.
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.
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.
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.
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.
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.
Idea was great in theory but in practice routers were often placed in the most inaccessible parts of a house (closet, ceilings, or walls)
Blackhat 2026: WPA free(not three) Enterprise, how to flood and bypass WPA3 with certificate forgery and dual pair attack in 5min!
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.
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...
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.
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.
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.
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?
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!
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)?
If you do trust the root cert for everything, couldn't the access point MITM all your traffic?
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.
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...
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...
Do not download and install and fully trust root CAs from anyone on your iPhone.
If you want to self-host, see eg:
https://wiki.alpinelinux.org/wiki/FreeRadius_EAP-TLS_configu...
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.
I remain disappointed that there's no standard mechanism for mapping between an SSID and a domain name to know which SAN to trust.
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.
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?
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.
After all, reliability is a cross-cutting concern :)
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.
>Wi-Fi
No.