2

We are using, as default, PEAP and MS-CHAPv2 as inner authentication.

I was concerned with security risks when it comes to rogue APs but a colleague told me that there are no risks for preconfigured clients.

He told me there are risks only for clients with WiFi not preconfigured, because most users would trust a fake certificate. Instead, for preconfigured clients, all supplicants would drop or reject the connection and the user wouldn't be allowed to trust a fake certificate. But why's that? Maybe because the supplicants check if there is already a certificate installed for that SSID?

Also, supplicants have always have been this safe regarding this matter? Or patches have been applied during time? If the latter is the case, how would I know when the patches have been applied and in which OS versions? It would be helpful because, for instance, I could suggest for Apple mobile devices to use only from iOS 7 and above (I just took a guess, I don't know if it's the correct version).

Jade Kush
  • 21
  • 2
  • Was your colleague talking about a specific deployment or in general? Depending on the specific deployment/environment he could be correct. In general, he is mostly wrong. – YLearn Dec 17 '19 at 01:08

2 Answers2

0

In theory PEAP exchanges only happen over a tunnel established by a certificate trusted by the CA.

Client behaviour when presented with an untrusted certificate is down to individual UX implementation. My android 8.1 phone will prompt me to accept a certificate which is not trusted, my MacOS Sierra machine will just go ahead and connect.

Although widely used; MsChapsv2 is not a secure inner tunnel authentication mechanism! It can be directly computed with 100% success rate in a couple of hours on an FPGA or for only a few hundred dollars of cloud compute.

GDev
  • 123
  • 3
  • >My android 8.1 phone will prompt me to accept a certificate which is not trusted, my MacOS Sierra machine will just go ahead and connect.
    Even if there is a previously installed certificate for that SSID?     – Jade Kush Mar 17 '19 at 17:21
  • After viewing about 20 live certificates, I am 99% sure that the only connection between ESSID and certificate is in the network management software. On MacOS you add the certificates in Keychain Access and on Android you add them in settings > security nowhere near the network manager. On Linux most things follow the network-manager-gnome model of a CA per connection. I think you can also use a signed SSL certificate without a CA if the constraints are compatible. It also seems sensible that the certificates are not 'pinned' to an ESSID as they periodically expire or are replaced. – GDev Mar 17 '19 at 18:11
0

There's absolutely no standard defining how to associate the Wifi network's SSID with TLS server certificate used by the EAP-TLS end-point. (One would have to define a standard similar to RFC 6125 and this would have to be adopted by all implementors.)

That's the reason why it's recommended to use a dedicated root CA for issuing the EAP-TLS server cert and configure the WPA supplicant to solely trust this dedicated root CA for connecting to a Wifi network with a particular ESSID.

Community
  • 1
Michael Ströder
  • 307
  • 1
  • 6