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.
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.