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