1

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
  • 11
  • 2

1 Answers1

0

There are three ways a supplicant can verify it's talking to a legitimate server:

  • Verify an attribute of the certificate presented by the RADIUS server matches what it expects. This is usually the CN.
  • Verify a trust relationship exists between one of its trusted CAs and the certificate the RADIUS server presented (note the RADIUS server can send additional certificates to help complete this chain).
  • Check that the server sent along an OCSP stapling response as part of the handshake. This is essentially the server performing an OCSP check on behalf of the client and forwarding the response.

Profiles/configurations are generally bound to SSIDs. If a configuration matching the current SSID is found, the configuration will be used to determine which checks to perform and set values for things like expected CN, and CA.

If these checks fail, then the TLS session will be destroyed before phase2 of the EAP method is started.

If a profile/configuration isn't found for an SSID, most supplicants (tested with Win10 and macOS High Sierra), will prompt the user to accept the presented certificate, but will not enable any of the above checks for the resultant ephemeral configuration profile. If the certificate presented by the RADIUS server changes, the supplicant will prompt the user to re-affirm that they trust this new cert while not explicitly telling them that the certificate has changed. If the user accepts the new cert the supplicant will modify the existing ephemeral configuration and start phase2.

So your colleague is correct on all counts.

As for patching, that's a very difficult question to answer. As far as I know, this behaviour has been consistent since it was introduced into the various operating systems, but I can't guarantee it. I know that at least the initial release of the Microsoft supplicant in Win 2K SP4 exhibited the behaviour described above, and know that Win 10 also exhibits it, but beyond that, I don't know if it's been consistent.

Arran Cudbard-Bell
  • 1,514
  • 1
  • 9
  • 18