Differences

This shows you the differences between two versions of the page.

--- public:2021-10_advisory_mutual_authentication_server_certificate_validation [2021/10/07 15:56] – lolaharrejisc
+++ public:2021-10_advisory_mutual_authentication_server_certificate_validation [2021/10/12 13:46] (current) – lolaharrejisc
@@ Line 2: / Line 2: @@
-Published: 07/10/2021
+Published: 12/10/2021
 **This advisory applies to all organisations providing a Home or Home and Visited (Wi-Fi) service.**
@@ Line 21: / Line 21: @@
 **There are no reports of this vulnerability being actively exploited.**
-Apple iOS devices that have accepted the organisation's server certificate on initial connection (otherwise known as Trust On First Use, or TOFU), will 'pin' the server certificate and will reject server connections where the server certificate fingerprint does not match. This will, in the presence of an 'evil twin', lead to an authentication failure, which in turn may, as indicated above, then lead to the user disconnecting (by 'forgetting' the network connection) and reattempting an authentication. Devices using the Android mobile OS before version 11.0 are offered the opportunity to not validate the server certificate. This setting in particular is contentious as it does allow the misconfiguration of Android devices in the manner described by the article.
+Managed devices configured with a profile installed via Group Policy or MDM should not be affected as these profiles ought to contain one or more root certificates, which the profile configures as the only certificate(s) that the server certificate may be validated against. Optionally, a Common Name (CN) is configured that will have to match both the server certificate's CN and subjectAltName data. Additionally, the profile may specify which authentication methods are to be used. If the validation of the certificate (or these parameters) fails, the authentication attempt fails, and no login credentials are exposed.
-Devices configured with a profile installed via Group Policy or MDM should not be affected as these profiles ought to contain one or more root certificates, which the profile configures as the only certificate(s) that the server certificate may be validated against. Optionally, a Common Name (CN) is configured that will have to match both the server certificate's CN and subjectAltName data. Additionally, the profile may specify which authentication methods are to be used. If the validation of the certificate (or these parameters) fails, the authentication attempt fails, and no login credentials are exposed.
+Non-managed Apple iOS devices that have accepted the organisation's server certificate on initial connection (otherwise known as Trust On First Use, or TOFU), will 'pin' the server certificate and will reject server connections where the server certificate fingerprint does not match. This will, in the presence of an 'evil twin', lead to an authentication failure, which in turn may, as indicated above, then lead to the user disconnecting (by 'forgetting' the network connection) and reattempting an authentication. Non-managed devices using the Android mobile OS before version 11.0 are offered the opportunity to not validate the server certificate. This setting in particular is contentious as it does allow the misconfiguration of Android devices in the manner described by the article.
 The article also refers to the use of plain-text credentials inside the EAP (Extensible Authentication Protocol) mechanism, known as PAP (Password Authentication Protocol). PAP is no longer widely used or recommended. The only EAP mechanism to use PAP is EAP-TTLS, whereas the commonly deployed PEAP protocol uses the MSCHAPv2 password mechanism, which, as the article points out, is based on a challenge-response model and is not vulnerable to this risk.