Personally 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.
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)
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.
"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.
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…
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 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.
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.
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.
> 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.
> 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.
> 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.
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.
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.
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.
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.
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.
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
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.
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).
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
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.
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.
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]
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.
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 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.
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.
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).
> 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.
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.
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.
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.
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.
xoa|2 years ago
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.
callalex|2 years ago
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.
ghostpepper|2 years ago
doubleg72|2 years ago
jillesvangurp|2 years ago
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.
bogantech|2 years ago
unknown|2 years ago
[deleted]
bArray|2 years ago
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...
[3] https://en.wikipedia.org/wiki/The_Shadow_Brokers
[4] https://blog.cr.yp.to/20240102-hybrid.html
DateThing|2 years ago
Of course, the fact the NSA was aware of differential crypto analysis some years before the rest of us is another thing…
ransom1538|2 years ago
londons_explore|2 years ago
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.
toast0|2 years ago
Also, it means replacing an AP would require reconfiguring all the clients.
dfc|2 years ago
mattbee|2 years ago
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.
benmmurphy|2 years ago
spr-alex|2 years ago
mmalone|2 years ago
unknown|2 years ago
[deleted]
rokkitmensch|2 years ago
But not you.
forward1|2 years ago
Because it would regress security back to inferior bearer authentication.
JohnFen|2 years ago
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.
jmole|2 years ago
tylerflick|2 years ago
sneak|2 years ago
wkat4242|2 years ago
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.
simoncion|2 years ago
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.
spr-alex|2 years ago
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.
mmalone|2 years ago
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.
mmalone|2 years ago
g-b-r|2 years ago
It's actually maybe already possible to consider it a fraud
transpute|2 years ago
OSS golang reference code is available, https://news.ycombinator.com/item?id=38402289
zamadatix|2 years ago
cmpxchg8b|2 years ago
sandworm101|2 years ago
moandcompany|2 years ago
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
bryancoxwell|2 years ago
[0]: https://www.nsa.gov/Resources/Commercial-Solutions-for-Class...
radicaldreamer|2 years ago
wannacboatmovie|2 years ago
forward1|2 years ago
amluto|2 years ago
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.
pierat|2 years ago
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.
Animats|2 years ago
What could possibly go wrong?
How do you do this without trusting some external CA?
e12e|2 years ago
FreeRadius can help:
https://wiki.alpinelinux.org/wiki/FreeRadius_EAP-TLS_configu...
spr-alex|2 years ago
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
testernews|2 years ago
forward1|2 years ago
xyst|2 years ago
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.
hunter2_|2 years ago
callalex|2 years ago
kortilla|2 years ago
tamimio|2 years ago
Blackhat 2026: WPA free(not three) Enterprise, how to flood and bypass WPA3 with certificate forgery and dual pair attack in 5min!
mysteria|2 years ago
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.
1letterunixname|2 years ago
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]
0. https://opnsense.org
1. https://github.com/smallstep/certificates
2. https://web.archive.org/web/20040617153148/http://radiuz.net...
tialaramex|2 years ago
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.
4ad|2 years ago
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.
boringuser2|2 years ago
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.
sneak|2 years ago
tonetegeatinst|2 years ago
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?
serendipitous|2 years ago
stephen_g|2 years ago
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!
WatchDog|2 years ago
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)?
pcthrowaway|2 years ago
If you do trust the root cert for everything, couldn't the access point MITM all your traffic?
mmalone|2 years ago
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.
WatchDog|2 years ago
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...
WirelessGigabit|2 years ago
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...
unknown|2 years ago
[deleted]
iforgotpassword|2 years ago
postpawl|2 years ago
BWStearns|2 years ago
jacoblambda|2 years ago
slicktux|2 years ago
sneak|2 years ago
Do not download and install and fully trust root CAs from anyone on your iPhone.
cynix|2 years ago
e12e|2 years ago
If you want to self-host, see eg:
https://wiki.alpinelinux.org/wiki/FreeRadius_EAP-TLS_configu...
tamimio|2 years ago
devin|2 years ago
mmalone|2 years ago
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.
[1] https://www.youtube.com/watch?v=KSL_Ke7HcpU
fiddlerwoaroof|2 years ago
andrewaylett|2 years ago
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.
parl_match|2 years ago
teunispeters|2 years ago
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.
slowhadoken|2 years ago
demondemidi|2 years ago
cvalka|2 years ago
dontupvoteme|2 years ago
>Wi-Fi
No.
wwarner|2 years ago
pieresqi|2 years ago
[deleted]