Govroam

The Roaming solution for the public sector

User Tools

Site Tools

You are here: start » public » 2021-10_advisory_mutual_authentication_server_certificate_validation
public:2021-10_advisory_mutual_authentication_server_certificate_validation

Differences

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

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
public:2021-10_advisory_mutual_authentication_server_certificate_validation [2021/10/07 14:19] – ↷ Page moved and renamed from public:2021-10_advisory:mutual_authentication_server_certificate_validation to public:2021-10_advisory_mutual_authentication_server_certificate_validation adminpublic:2021-10_advisory_mutual_authentication_server_certificate_validation [2021/10/12 13:46] (current) – lolaharrejisc
Line 1: Line 1:
 +====== Advisory: addressing claims of misconfiguration vulnerabilities ======
 + 
 +
 +Published: 12/10/2021
 +
 **This advisory applies to all organisations providing a Home or Home and Visited (Wi-Fi) service.** **This advisory applies to all organisations providing a Home or Home and Visited (Wi-Fi) service.**
  
-Recently Jisc, its CSIRT, and the govroam UK team, were made aware of an article on ThreatPost ((https://threatpost.com/misconfiguration-university-wifi-login-credentials/175157/)) that claimed that some international Wi-Fi networks could be exposing login credentials through misconfiguration. This article is based on research by WizCase ((https://www.wizcase.com/blog/eduroam-vulnerability-report/)), which focuses on the worldwide eduroam wireless network system but also points out that other wireless networks may be similarly affected.+Recently Jisc, its CSIRT, and the UK govroam and eduroam teams were made aware of an article on ThreatPost ((https://threatpost.com/misconfiguration-university-wifi-login-credentials/175157/)) that claimed that some international Wi-Fi networks could be exposing login credentials through misconfiguration. This article is based on research by WizCase ((https://www.wizcase.com/blog/eduroam-vulnerability-report/)), which focuses on the worldwide eduroam wireless network system but also points out that other wireless networks may be similarly affected. 
 + 
 +As the govroam and eduroam services utilise the same technologies and roaming model, we would like to address the question of whether this threat applies to organisations participating in govroam. 
  
 Misconfiguration of any system, IT or otherwise, is likely to compromise its function – imagine servicing your car brakes without bleeding the brake lines. In that sense, an article that flags a problem if people misconfigure their profile is neither new nor surprising. Misconfiguration of any system, IT or otherwise, is likely to compromise its function – imagine servicing your car brakes without bleeding the brake lines. In that sense, an article that flags a problem if people misconfigure their profile is neither new nor surprising.
  
-We would like to reassure our members that govroam is no more or less affected than any other enterprise Wi-Fi network. To ensure a secure set-up, there is nothing you need to do for govroam that you wouldn’t already need to do for any other Wi-Fi network that uses the WPA Enterprise (802.1x) standards.+We would like to reassure our members that **govroam is no more or less affected than any other enterprise Wi-Fi network**. To ensure a secure set-up, there is nothing you need to do for govroam that you wouldn’t already need to do for any other Wi-Fi network that uses the WPA Enterprise (802.1x) standards.
  
-According to the vulnerability map published in WizCase’s report, no active egovroam UK sites were highlighted as vulnerable to this risk. While it is true that an 'evil twin' attack is possible, it has limited opportunity:+While it is true that an 'evil twin' attack is possible, it has limited opportunity:
  
   * This is not a remote attack, so it can only be attempted within close proximity of misconfigured client devices.   * This is not a remote attack, so it can only be attempted within close proximity of misconfigured client devices.
Line 14: Line 21:
 **There are no reports of this vulnerability being actively exploited.** **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. 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.
Line 24: Line 31:
   * Discontinuing the use of EAP-TTLS/PAP, unless it is absolutely required, and replacing it with alternatives such as EAP-TTLS/MSCHAPv2 or PEAP/MSCHAPv2, or, if the option exists, with EAP-TLS.   * Discontinuing the use of EAP-TTLS/PAP, unless it is absolutely required, and replacing it with alternatives such as EAP-TTLS/MSCHAPv2 or PEAP/MSCHAPv2, or, if the option exists, with EAP-TLS.
   * Discouraging the use of ad-hoc instructions that limit themselves to TOFU, as well as those which recommend, on versions of Android older than 11, the use of the 'Do not validate' option.   * Discouraging the use of ad-hoc instructions that limit themselves to TOFU, as well as those which recommend, on versions of Android older than 11, the use of the 'Do not validate' option.
-  * Jisc would like to encourage all UK govroam operators who operate a 'Home Only' or 'Home and Visited' service to double-check that their site and server configurations conform with the above best practices.  +  * Jisc would like to encourage all UK govroam operators who operate a 'Home Only' or 'Home and Visited' service to double-check that their site and server configurations conform with the above best practices. The govroam team at Jisc would be happy to advise if you are unsure. 
- +
-The govroam team at Jisc would be happy to advise if you are unsure. +
  
 Please contact us at **govroam@jisc.ac.uk** if you have any questions or concerns. Please contact us at **govroam@jisc.ac.uk** if you have any questions or concerns.
public/2021-10_advisory_mutual_authentication_server_certificate_validation.1633616362.txt.gz · Last modified: 2021/10/07 14:19 by admin