FreeRADIUS is great, and I wouldn't use anything else.
But to increase the adoption of EAP, what would be better is a super simple daemon, you point it at LDAP or a file, and it sets itself up for PEAP or EAP-TTLS and you just have to point your APs at it. FreeRADIUS is far to complex for most use cases.
I note that many APs now come with nice web interfaces and can integrate with LDAP and Active Directory directly, which is a great step forward.
Ideally AD would support something like SRP directly so you wouldn't even need server certificates.
> But to increase the adoption of EAP, what would be better is a super simple daemon, you point it at LDAP or a file, and it sets itself up for PEAP or EAP-TTLS and you just have to point your APs at it.
You mean like hostapd provides? :)
##### Integrated EAP server ###################################################
# Optionally, hostapd can be configured to use an integrated EAP server
# to process EAP authentication locally without need for an external RADIUS
# server. This functionality can be used both as a local authentication server
# for IEEE 802.1X/EAPOL and as a RADIUS server for other devices.
# Use integrated EAP server instead of external RADIUS authentication
# server. This is also needed if hostapd is configured to act as a RADIUS
# authentication server.
eap_server=0
# Path for EAP server user database
# If SQLite support is included, this can be set to "sqlite:/path/to/sqlite.db"
# to use SQLite database instead of a text file.
#eap_user_file=/etc/hostapd.eap_user
I want simple, non-enterprise wifi, but I want the "enterprise" feature of per-user credentials.
Sadly, setting up a RADIUS server is the only way I can see this is possible.. way to complicated, I'd sooner just put a static file on the router, but I'm not sure if this is possible.
Some of the small business gear has this feature. I use Ubiquiti access points, and through the Unifi interface I enabled the built-in RADIUS server and added some users to it. Now I have enterprise-style WiFi authentication.
Honestly it's not that complex to set up a freeradius or similar server. You can have freeradius read a static file for user management, you don't need to use LDAP necessarily.
One issue with WPA2 Enterprise is the client user interface. It's hard for users to configure the correct settings because there is no feedback about configuration issues - wrong EAP mode - vs credential errors - wrong user password. All you get is a "Can't connect".
There is also the problem of so many eap modes. There are some interesting EAP modes that have come along - like EAP-PWD - that remain unimplemented on major platforms, and are basically unusable. So you're left with EAP-TTLS with PEAP and MSCHAPv2 (stores passwords weakly), or EAP-TLS with client certificates. And no one wants to manage client certificates if they can help it.
Both of the above make WPA2 Enterprise on BYO devices quite a challenge.
EAP-PWD seems like a weird thing to want. It's probably incrementally better than WPA2-PSK if you actually have a small number of users who can keep the secret (or in a home network with no guests) and if you use a decent secret, but that's a pretty narrow scenario.
It's not obvious that you're better off security-wise with EAP-PWD than you'd be on WPA3-PSK for example, the UX for PSK is better, and the compatibility story for WPA3 is probably acceptable today, so there's no reason to want EAP-PWD now even if it might have been better than the status quo five years ago.
MSCHAPv2 is garbage but that's Microsoft's fault, and the uncomfortable reality for almost any medium or large organisation will be that there is a bunch of Microsoft stuff and so whatever crap they shovelled into Windows is what you have to put up with.
The more I think about "evil twin" and read/ re-read this thread, the more I think maybe the most attractive new-build answer is throw away WPA2 Enterprise in favour of WPA3 with no password†, then do BeyondCorp / ZeroTrust and defend your systems at their edge not by hoping a poorly defended WiFi network or VPN saves you from doom.
†In WPA3 networks with no password are still secured against passive adversaries, so the UX is nicer but it's just as safe as having a WiFi PSK that inevitably is easy to find out. And unlike MSCHAPv2 it doesn't let bad guys harvest all your users' credentials for the price of a DES cracker.
I agree totally. My phone company gives me access to their hotspots using EAP-SIM/AKA, which is really useful, but there's no way for an AP to advertise the EAP methods they support which sucks. And EAP-PWD is awesome but like you said, rarely implemented. There's also EAP-GTC which I think allows you to do secure password auth as well.
We currently use PEAP with MSCHAPv2 since the user credentials are protected in transport and our domain controllers are pretty secure, but it'd be nice to be more flexible.
Having recently set up FreeRADIUS + WPA2 for the first time, I have to say, it wasn't really that hard at all. It wasn't any harder than setting up a mail server, or web server, or commercial grade router, or any other similar task that anybody's IT department (or contracted IT service) shouldn't be able to handle without a sweat.
> I have to say, it wasn't really that hard at all.
I agree; I think the problem is that it looks hard, with a truckload of config files and settings. It's not obvious that you wouldn't need to touch most of them. That's a UI/UX problem really...
My phone used to do that. Now I have to force it to connect manually whenever I need it, because it doesn't recognize the captive portal, and it only recognizes it as a network that doesn't have internet access.
yes, at least turn off "auto-join" for popular APs like that if you don't want to delete them from your network list.
the main advantage of saving a network is not to retype the (should-be-)hard-to-remember password, but the popular ones are usually open, in which case that advantage goes away. but when you've curated the order of the list just so, you may not want to delete them outright, but rather turn off auto-join.
Actually, on second thought, this doesn't really help Rachel's scenario. If the imposter knows our PSK then WPA3 does not defeat that. Huh.
[Also there ought to be a way to zap that +Karma on a comment that I now realise isn't helpful ]
Original post follows:
Note that WPA3 is intended to fix this, but...
* Your corp network probably doesn't talk WPA3 yet
* Even if it does it probably also allows WPA2 back compatibility for older devices
* Lots of devices can be fooled into accepting that just because the 'foocorp' AP it usually talks to is WPA3 maybe this 'foocorp' AP is WPA2-only and that's fine
* Cheap devices (maybe not your laptop or iPhone, but perhaps a cheaper phone and definitely other devices) are too constrained to safely run the secure algorithm.
WPA3 uses a PAKE here (it calls this "Simultaneous Authentication of Equals but it's just the Dragonfly PAKE) so the advantage is that devices don't tell anybody what the PSK is. But we're probably a decade from being able to tell people (especially conservative corp sites) to turn off WPA2 altogether.
If you already use a sane 802.1x setup instead of a PSK WPA3 doesn't meaningfully improve anything and you needn't rush to update, but of course random cheap consumer WiFi gizmos that expect a PSK won't work.
This is why 802.1x and RADIUS are key. I used to maintain the RADIUS servers at an ISP and dealt with the craziness that were the initial implementations of 802.1x, and to this day I keep finding corporate networks that do crazy things like rotating standard WPA Wi-Fi passwords via policies instead of just setting up 802.1x properly.
Of course, vendors don’t help here. Spending six digits on Cisco gear to get “out-of-the-box” end-to-end authentication (that then is weirdly inflexible in hooking up to your corporate AD) is certainly not on most small companies’ radar, especially when they get cheap APs that “work”.
For home use, I’ve bee looking for decent APs (_not_ proprietary fancy mesh setups) that support 802.1x and don’t cost an arm and a leg, and I’ve been seriously considering ripping out my Airports (which are amazing Wi-Fi gear, and sadly discontinued) and going with a combination of OpenWRT gear and an embedded RADIUS server.
But I’ve been wondering if there are decent SOHO solutions out there for 6-12 APs and up to 50 users — it would be great for small companies/startups.
"Kenin said malicious actors were exploiting a vulnerability in the routers that MikroTik had patched in April -- just one day after the flaw was first discovered."
So an exploit was found (it happens) and patched within 24 hours.
From memory this was only vulnerable if you didn't block incoming winbox traffic on your wan port (which is of course good practice, and I believe the default configuration).
Upgrading a mikrotik router is a matter of running "system package update install". You could stick that in a scheduled script if you wanted.
Upgrading a cisco or juniper router requires things like support contracts, tac accounts, and other nonsense, then in many cases doing things like using tftp (!!) to copy a binary to the router, then ensuring you have a serial connection (!!) to the switch for when it breaks.
Upgrades on Mikrotiks are so simple. I used them for over 10 years and never once had a problem.
In my previous experience both from my ISP days and some time in a corporate IT "networks" department, almost nobody upgrades their "enterprise" (Cisco) routers or switches. It's too risky.
Sounds more like a track record of owners not patching their routers. Every brand of network devices has had serious security flaws. At least MikroTik is cheap and functional.
We are a small company and we use Ubiquiti Unifi gear for that; for now including the supplied RADIUS server. We do have a domain, but for something that public as Wifi and VPN passwords we went with separate credentials.
Corporate WiFi networks should be untrusted. Once a device is connected to the WiFi users should then be required to connect via VPN before internal network access is granted.
We use the described setup at our company and the VPN software (Viscosity) auto connects so seamlessly that you never really need to do anything manually. Works really well.
Basically every big corp uses always on VPNs and it works fine. You can even do stuff over group policy on Windows to get the VPN configured and auto join enabled.
Would you care to elaborate? I worked pretty closely with the Corporate IT folks at that company for 6 years and never heard of any issues from them nor complaints from non-tech users in the organization. This company had over 15,000 employees, not the largest but not small.
Unfortunately the proposed solution WPA Enterprise has its own set of pitfalls. Unless one opts for EAP-TLS, which is quite secure, some fun can be had with certain other EAP methods if implemented insecurely. It is especially inadvisable to use AD credentials and skip certificate validation or make it optional. For further research: https://github.com/opensecurityresearch/hostapd-wpe
Notice this does not setup certificate validation (and therefore does not authenticate the AP is actually from Cornell). It also tells you to use the completely broken MSCHAPV2 and login with credentials that allow access to a number of other university services.
So in this setup, not only can you still trivially impersonate a Cornell AP, all clients also give you their specific login credentials in a way that allows you to recover their passphrase.
It's true that it doesn't (and can't) authenticate that the AP is "actually from Cornell" and indeed that's the point of EduROAM.
But it will be talking to Cornell to authenticate you and so no you can't "recover their passphrase".
EduROAM is a global federation. So what's happening goes like this:
Let's say I'm a Cornell student
1. I follow these instructions, probably while on campus to make my, let's say, iPhone work with WiFi. My "NetID" is tialaramex for this example.
2a. Probably my phone automatically concludes that network-access.it.cornell.edu is really network-access.it.cornell.edu because it has a Web PKI cert that says so, just like on an HTTPS website.
2b. But if not I have a step where I tell the phone this certificate looks OK. This is effectively TOFU (Trust On First Use) because I'm a naive user which isn't great but it'll protect against many attacks later.
3. I go to the University of Sydney, in Australia, as an example.
4. My device sees an AP named "eduroam" because I'm at a university in a developed country and the Network Effect means it makes sense for all universities to join eduroam.
5. My device says "Hi I'm tialaramex@cornell.edu † let me in"
6. Sydney's AP talks to an Australian server which talks to Cornell, which agrees to talk to my device about this, over TLS
7. My device confirms that this TLS connection matches the certificate we saw earlier, or has a trusted certificate for network-access.it.cornell.edu
8. Using the risible MSCHAPv2 protocol (but happily inside TLS) my device proves I am really tialaramex@cornell.edu
9. Cornell tells Sydney that yup, I am an authorised Cornell network user, let me in.
10. I get the same privileges as a local Sydney student/ professor in terms of network access. If there's any problem (maybe I use 40GB in one day from PornHub) Sydney know which Cornell user I am and they can take it up with Cornell. In extremis they can "blacklist" me.
† It is possible to arrange that the local institution does not find out your "real" username at your home institution, since they don't need to know that in order to connect to the right authentication service. But mostly nobody cares.
You don’t have to set up a certificate because the university is using a public cert. My old uni configures their network the same exact way.
And the situation isn’t really all that dire because once you connect to the real university wireless once it will pop up a warning if another network with the same SSID appears but doesn’t present the cert.
You could imagine a system where you configure your laptop with a public-key hash of the wireless network, maybe using ssh-style TOFU (trust on first use), to defeat this kind of attack. You could even use the OPIE or BIP39 or bubblebabble wordlists, or randomart images, to confirm that first use. There's really no reason the Wi-Fi standards, developed decades after ssh was, need to be less secure.
Once I had to reconfigure some Airtame devices out in the field. They couldn't connect to the cloud, but I made a hotspot with the same SSID and credential settings as one of our guest networks at work. The devices were able to connect to it, and I successfully reconfigured them. Some time later at work my phone was feeling warm. I was surprized to see I was subsidizing random office internet traffic with my cellular data plan.
Access protection is usually done more diligently for important networks, but the simplicity of a MITM attack makes it apparent that all corporate networks need RADIUS or similar protection.
It's interesting to see a website that just copy and paste content from other sources without any sort of credit or referencing having this attraction (usually in the HN top ranks).
In fact the way it's presented it even seems that was 'authored by rachel, the anonymous valley dev'.
Harmless attitude when it's just someone trying to land a hotsite and earn some extra bucks/attention. But later don't complain when the same attitude is in place by big companies/VCs draining your career.
Tech scene really reached a new low these days: "put the minimum effort; try to extract and profit the most" -- while trying to be 'smart/efficient' people lost the self perception of predatory behavior.
Maybe could be renamed to Grasshopper By the Bay. :P
This threat vector is interesting, but is it really a huge deal? I don’t think many company devices restrict the networks you can connect to (certainly not ones you bring on Caltrain) so why even target a corporate pre-shared-key network and instead host xfinitywifi or another popular public SSID?
Because the people working for the target of your attack might never connect to an xfinity wifi network, but they are pretty likely to connect to the wifi at their office.
Exactly, this would likely work fairly well for a targeted attack. Yes, shared Wi-Fi names might work for some employees, but using the employee’s work’s Wi-Fi SSID/psk is virtually guaranteed to work (if they use WPA PSK anyway).
Some great stuff happened when I was moonlighting as IT at a company. One time someone randomly plugged in a cat5 cable and created a loop in the network, causing an ARP packet storm.
The company also had 2 different networks, one for data and one for VOIP. They had wall plates in the conference rooms that had a data RJ45 and a VOIP RJ45. Someone decided to plug a cable from the VOIP port into the conference phone (which had a pass through), and plug a cable from the pass through on the phone into the data port, causing all kinds of weird chaos. That was a fun one to track down.
Spanning Tree is under-rated :) Although I read a twitter thread earlier where someone did this and they had spanning tree which in theory prevents this but the switch had some kind of bug causing it to crash and reboot right after disabling the port with spanning tree.
It was a long time ago and most of the equipment was either hubs or dumb switches with no budget to overhaul. That’s a really great bug to have in your equipment out in the wild
Wait you already have the wpa preshared key? Why would you go the trouble of creating a clone network when you can already join the actual network and arpspoof at will?
One might choose to do this because the admins thought they were "smart" and said, "Oh, I know, we will only allow 'known' MAC addresses to connect to the network! That will fix it."
And it does, kinda. Except it doesn't stop you from capturing clients on your "fake" network, and the goal isn't necessarily to be on the "real" network, the goal might be to just man-in-the-middle a juicy site or two, with is on the big Internet (say, the company's bank)
Capture the controller's login into the bank and win "free money"
Not disagreeing with you here, I am wondering however if you have ever surveyed or even had casual conversation with people who self identify as "an IT person at company <X>."
In my discussions with such people[1], I have found that a preponderance of them believe that a MAC address filter is a strong protection against unauthorized equipment on their wireless network.
[1] I have had many occasions in my career where I have hired people in the IT/Ops role and during the interview process I have often probed their understanding of the plumbing of IT beyond the parameters necessary to enter on a screen in order to get something "up." My admittedly non-scientific sampling suggests that "knowing the plumbing" is not a valued skill for many of these people.
* It may have client isolation enabled though that thwarts certain critical use cases like having those private, wifi enabled boom boxes on the corporate WLAN...
* The goal stated in the article is to lure clients onto a rogue AP far away from the office anyway.
1. Have access to their computer to retrieve the wpa key.
2. Create a clone of the wifi network, spoof a bunch of sites and hope to catch one that doesn't use http.
Why can't I replace step 2 with: Install a root kit since I already have access to their machine.
1. Find some one to steal a key from but which I don't care about.
2. Locate a third person that I want to target and move close to them in non office hours.
3. Create a clone of their wifi and try to spoof some website. Hopefully I can be close enough to their device that it would join my clone instead of their other preferred networks.
At step 2 seems like a better idea to move close to the office and start probing around?
To get that close to the office would be very obvious. You'd have to loiter all day or set up a remote host with some power.
To get near a target in the wild isn't that hard, especially if you know where they like to go on a regular basis.
It's lot easier than a lot of other methods, especially for a high level target like a C-level exec who might have access to bank accounts with millions of dollars and like to work at a local coffee shop on weekends.
You don't have to spoof sites. If you capture the client they will invariably use DHCP to get an address and you can pass along that you are the web proxy for HTTP/HTTPS. Voila, all your bases are belong to us, right?
That might work nicely for plain TCP traffic, but it's not very useful for TLS encrypted connections by itself.
An attacker wants to decrypt the packets passed on as the man in the middle without alerting the victim. A big red "insecure connection" browser warning due to an untrusted certificate used by the MITM can easily thwart the attack.
To make this work, the attacker needs access to a CA the victim trusts to sign certificates on the fly. If the attack is limited to a single target page, stealing the associated private key from the legitimate website operator is an option, too.
Block port 443 and hope sites aren't configured to upgrade insecure requests.
Redirect all traffic to a site which looks like the corporation you're spoofing, asking for corporate login credentials, how many will enter them reflexively, especially with poor corporations that ask for authentication on a frequent basis.
From memory captive hotspot popups on apple devices at least don't even show the URL they have loaded, but www.targetcorp.com-secure.com etc works well in many cases.
Interesting idea, but im pretty unconvinced its a threat in practise. People will connect to any free wifi they can find, you don't need to trick them into it. Use HSTS if you need security. (The author of course says its easy to forget on some obscure part...well yes. Security is hard for a reason)
You are thinking about a coffee shop scenario, when the article is about an office environment. They are talking about spoofing the office SSID that devices already connect to automatically, not people manually connecting to open networks.
They were talking about people autoconnecting to an office ssid on the bus. If you use your office phone on the bus, you probably use it at the coffee shop too.
It would have been trivially possible to use the Web PKI here if APs advertised an FQDN instead of a short text string as their visible name.
If you were signing into "Starbucks.com" then logically we can arrange that the AP needs to prove it has a certificate for starbucks.com or some-wifi-made-up-prefix.starbucks.com or something and it could use the Web PKI to make that work safely for everybody.
But APs do not have FQDNs. The WiFi industry has talked about trying to get to roughly the same place by a circuitous route, but the problem they run into is: Who is allowed to call their AP "Starbucks" and why? If you decide it's fine we'll hide a signifier elsewhere, then the user doesn't know why this Starbucks and that Starbucks don't interoperate. Their experience is disappointing and even if you claim it's for security reasons they're left puzzled.
However, there is no need to involve "deploying certs" anyway.
You can use your existing (very likely) Active Directory or similar and single-sign-on infrastructure to allow employees WiFi devices to prove who they are to the WiFi AP, without giving away any secrets. There are an impressively confusing array of different ways to do this, but the good news is that even the really terrible ones are safer than a PSK.
You can even federate this system, a good proportion of all degree institution students and staff in the industrialised world have EduROAM, their laptops (iPhones, whatever) connect to any AP that claims it is EduROAM (maybe in Venice, or New York, or Sydney) and they tell it their email address with their home institution (e.g. where they're employed or registered to take classes) and then they give that institution credentials to connect. The local institution can see that e.g. OK this NYU student is on our network, and if there's a problem (looking at PornHub in class? Not here) they can tell NYU about it and if necessary blacklist a problem user. But they don't get credentials for the user, and the user doesn't get local credentials. No more need for toxic "guest" networks for visitors.
> If you were signing into "Starbucks.com" then logically we can arrange that the AP needs to prove it has a certificate for starbucks.com or some-wifi-made-up-prefix.starbucks.com or something and it could use the Web PKI to make that work safely for everybody.
So there's really no way to do so currently, correct?
> There are an impressively confusing array of different ways to do this, but the good news is that even the really terrible ones are safer than a PSK.
Which would be actually the safest one that would primarily avoid evil twin attacks?
> But they don't get credentials for the user
Assuming there's no easy misconfigurations made by the user? E.g. they can't click "accept this invalid cert" somewhere?
> So there's really no way to do so currently, correct?
AFAIK Nobody does this today. It would be difficult to retrofit.
> Which would be actually the safest one that would primarily avoid evil twin attacks?
Ah. Unfortunately this "evil twin" impersonates an AP and 802.1x does not end up giving us confidence in the identity of the AP per se.
For example say you're using PEAP-EAP-MSCHAPv2 (a common way to set things up with an Active Directory service authenticating your users) - if the bad guys can connect to the server you're doing PEAP-EAP-MSCHAPv2 on from their "evil" AP then your users will consider everything looks fine. The bad guys can't directly learn their credentials in the process because there's a TLS layer, but your users end up connected to their "evil" AP.
Even with certificates (say EAP-TLS) this is no different, if the bad guys are able to talk to your legitimate service they can have your users authenticate with your legitimate service on their AP.
So the main thrust ends up being: Do not trust the network. Use TLS and other technologies to secure your traffic so that you don't care who is providing the network, whether it is who you expected or somebody else.
Sorry.
> Assuming there's no easy misconfigurations made by the user? E.g. they can't click "accept this invalid cert" somewhere?
Good point. That would definitely vary by client device. There's no good reason why a device should let you do that, but I wouldn't be surprised if lots of them do.
This is why you treat the office wifi connection as any other connection, don't create a 'turtle shell' (hard outside, soft inside) infra and control the DNS configuration of your employee's laptops.
Interesting way of cloning networks but still MAC addresses would differ. Original network has a MAC address of a router and clone network has a different MAC address of an access point.
You mean BSSID. It looks like a MAC address and in some cases it actually is one, but it’s not required to be. Each AP broadcasting for a given network will have a different one and I’m not aware of client side native behavior to alert or enforce a whitelisted set. Even if there was, you could easily spoof the BSSID too, just would need to war drive to get it.
I just mentioned basic security check but I don't know anything about corporate networks or how to manage them. One thing I know is that Microsoft has robust network directory service called Active Directory which "authenticates and authorizes all users and computers in a Windows domain type network—assigning and enforcing security policies for all computers and installing or updating software." So for example you could register all corporate access points to a Windows domain and no way you get connected to a wrong access point.
The article does make the same point. Basically companies could configure their WiFi in a more secure fashion but many won't. I'm certain many small companies use very basic setups similar to a home WiFi and at best will just change the WiFi password periodically.
This is why major OS providers are taking it on themselves to tackle some of these issues independently of the WiFi setup - like taking the location in consideration and warning you if you connect to the same network in a different location.
wpa_supplicant can be told that a network is non-BSSID-filtered, locked to a specific BSSID, and/or be provided optional black-, and whitelists of BSSID for that network.
Having multiple access points with different BSSIDs (sibling comment explains those) but the same SSID and credentials is how network roaaming works. As a client's signal strength goes down (and also periodically) it will scan for other APs. If one of those APs (with the same SSID and credentials) has a better signal, the client will usually switch to it to maintain good connectivity. For larger corporate networks it's fairly common to have multiple APs for one SSID to have WiFi connectivity over a larger area, but it's becoming common even in home environments with the two APs being 2.4GHz and 5GHz.
This is a good way to target individuals too. If know someone uses wireguard and has it set to automatically connect except when on their home wifi, you can pretend to be their home wifi to lure them into a false sense of security.
I would contend that this is a problem with wireguard. It shouldn't be trusting the name of the wifi network.
Commenting from the perspective of iOS and its configuration profiles, you can configure them to match based on an HTTP connection (among other things). I haven't tested it (yet, I think I know what I'm playing with tomorrow), but if the URL is one that would require a TLS connection I would hope that iOS is checking that certificate. If it is and the domain of the URL is one you control that could be a way to implement the check (assuming that URL is also only available on networks you trust).
> Any modern enterprise WiFi setup will support containing rogue APs. So this vector won't work if configured correctly
You misunderstood the issue. Modern enterprise wifi won’t detect a “rouge AP” that’s setup near a worker’s home (or coffee shop), only ones in radio range of the corporate APs.
Not quite on the enterprise wifi side, but I have been pleasantly surprised that iOS has alerted me when I connect to a wifi network with the same name, at a new location. So endpoints can play a part in this.
I’m not sure if there is some kind of MDM policy that would restrict locations that are valid for wifi use, but expect it is coming soon.
> Not quite on the enterprise wifi side, but I have been pleasantly surprised that iOS has alerted me when I connect to a wifi network with the same name
Actually, that’s the exact opposite of what I was quoting. That’s client side detection, not “rogue ap containment” which is an entirely different thing. Rogue AP containment is where a Wi-Fi controller detects unauthorized APs within its AP’s radio range and sends client disconnects to the devices connected to it, effectively isolating (“containing”) users from it.
Not only that, the newer WiFi standards are doing away with the dissociation attacks (which is what they are) that some vendors had been selling as "containment" because they're also quite obviously a denial of service attack vector.
You can imagine what happens when two corporations are in adjacent spaces in the same building and both have their WiFi configured to "contain" the neighboring tenant's access points.
> You can imagine what happens when two corporations
I don’t need to imagine, I’ve done it to my apartment complex before by mistake. I have an Aruba 3200XL controller and a bunch of APs (couple 335s, couple 225s, and some older 105s, with the 105s being used as Air and Spectrum monitors). Decided to see the impact and quickly learned all my neighbors lost WiFi access.
Corporate WiFi networks are capable of Creating multiple SSID’s tied to different VLAN’s. Creating a VLAN with client isolation while using WPA2 personal should be trivial.
Giving that network a VLAN to exist on with just an internet gateway should be trivial.
Coupling the VLAN with client isolation should be adequate for most companies.
Any reasonably administered corporate network should be able to then provide company issued devices with more reasonable security.
Posture assessment and other aspects of network management are important for compliance.
None of that should scare anyone. You can still stream music in the bathroom while offering more security for corporate devices.
Is that going to prevent phones and laptops in random places from automatically connecting to a spoofed network?
To my knowledge, it will not. So you'd need that SSID and VLAN to be something like a guest wifi. Preferably with a key that rotates often enough that people will not try and remember the network.
Cause otherwise, it just became a whole lot easier to get a layer 1 MitM on anyone who has that network on auto connect.
But to increase the adoption of EAP, what would be better is a super simple daemon, you point it at LDAP or a file, and it sets itself up for PEAP or EAP-TTLS and you just have to point your APs at it. FreeRADIUS is far to complex for most use cases.
I note that many APs now come with nice web interfaces and can integrate with LDAP and Active Directory directly, which is a great step forward.
Ideally AD would support something like SRP directly so you wouldn't even need server certificates.