Tim ODriscoll wrote:
A recent security audit told me that I need to use 'username/password authentication with digital certificates' for my WiFi authentication. The concern was that a rogue access point could trick an end-user device into attempting authentication and revealing a password hash. The theory is that the client device has a certificate to prove it is a trusted device. How would that work with FR?
That would be EAP-PEAP-MSCHAPv2 or EAP-TTLS. The RADIUS server sends a certificate that is signed by a CA. The OS checks that it trusts certificates signed by the CA before sending a password. The client does not need a client certificate in these modes. (FR supports having one anyway IIRC, most clients won't do that for you, though.) That's at least how it is SUPPOSED to work. But, the client has to check the DN/CN of the certificate to ensure no evil twin can steal passwords. Otherwise anyone with a stolen or even a legitimately obtained certificate issued from the same trusted CA can cause the client to initiate password authentication in its tunnel. The client has to be specifically configured to check the domain of the CN/DN, though some OSes will "pin" the certificate after the first join to the network. This behavior varies widely from client OS to client OS However, some clients make it really easy (not scary enough) for users to click through the warning windows when they detect a new certficate. Be sure to check the CN/DN "domain"... if the client has an option to see if the CN/DN "contains" a string, that is not good enough as an attacker could do yourdomain.hisdomain.tld. We rely on the CA not to issue fishy sounding certificates and only issue certificates to authorized domain owners here, unless we run our own CA, and put the root for that CA in the trust store on all our client devices. Yes this is all an utter mess. Unless we get to dictate what client OSes or supplicants are in use, we're at the mercy of client OS vendors who do not seem to care much how ugly this gets. - List info/subscribe/unsubscribe? See https://nam10.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.freerad...