Multiple realms and network validation with WPA2 Enterprise
b.candler at pobox.com
Sat Dec 24 17:48:30 CET 2016
On 24/12/2016 00:07, Henti Smith wrote:
> To put it another way. Users have been taught to look at browsers address
> bar, to ensure they are talking to the correct server and that there is a
> lock next to the https to indicate the SSL cert fo rthat host has been
> validated (admittedly byt a thir party, which you have already pointed out
> has it's own insecurities)
Basically you have to configure the client to require a certificate with
a specific identity, otherwise they are wide open to man-in-the-middle
credential gathering attacks.
I use a real certificate from Letsencrypt: you can set up a webserver
called (say) "wireless.yourdomain.com" and get a certificate from
letsencrypt for that; then you copy the private key and cert onto your
radius servers. This at least gives you a green tick in some clients
But there is still no binding between SSID and certificate identity.
When users connect who *haven't* pre-configured their client, they would
still have to be trained to look for (a) a valid certificate, and (b)
the identity is "wireless.yourdomain.com". And you know how bad users
are like for clicking through things.
So using something like the CAT tool to preconfigure their client is way
> I need to show the business the same risk
> management before we can switch to WPA2 Enterprise away from a shared key,
> which again has it's own set of insecurities.
Yes, EAP-TTLS/PEAP has the problem you outlined, and like everything,
it's a balance of risk.
Two other solutions you can look at:
* EAP-TLS. You deploy certificates to all the clients to identify
themselves, *and* they have to know which certificate identity to look
for from the SSID to avoid MITM. It's a pain unless you have central
deployment of certificates to all clients.
* EAP-PWD. This offers strong mutual authentication using just a
password for each user, and is secure against off-line dictionary
attacks. However: (1) you need the cleartext password available
server-side, and (2) unfortunately many clients don't support it. (It
might be workable if you are an all-Linux and all-Android shop)
More information about the Freeradius-Users