It was reported [1] that wpa_supplicant does not properly check certificate subject name, which might lead to "man in the middle" attack. Relevant part of the original report: ... wpa_supplicant, linked against openssl performs this check: if (depth == 0 && match && os_strstr(buf, match) == NULL) { wpa_printf(MSG_WARNING, "TLS: Subject '%s' did not " "match with '%s'", buf, match); preverify_ok = 0; openssl_tls_fail_event(conn, err_cert, err, depth, buf, "Subject mismatch", TLS_FAIL_SUBJECT_MISMATCH); } strstr() is vulnerable to extension attack, for instance, one would like to match on /CN=wireless.nikhef.nl, but explicitly not match on wireless.nikhef.nl.honestachmed.tr. There is no way to implement a secure EAP-TTLS/PEAP configuration using public certificates this way. When linked against GnuTLS, the problem is even worse: if (i == 0) { /* TODO: validate subject_match and altsubject_match */ } Now, it is current best practice to run EAP-TTLS/PEAP with public certificates, because on Windows, this automatically pins the CN and CA from the certificate. ... [1]: https://bugzilla.redhat.com/show_bug.cgi?id=1178263
In the discussion with upstream, it was determined that this CVE assignment was not correct, as subject_match was intended and documented and substring match against the whole subject string. As this CVE got used publicly (e.g. in https://bugzilla.gnome.org/show_bug.cgi?id=341323#c28), this bug is made public as well. It was realized that existing alternatives to subject_match - alt_subject_match and domain_suffix_match - do not provide commonly needed / expected behavior of an exact non-substring match against server name that can be listed in X.509 certificate's DNS subject alternative name or subject common name (CN). Therefore, domain_match was introduced, that behaves similarly to domain_suffix_match (it compares defined name against DNS subjectAltNames and falls back to checking subject CN if certificate includes no DNS subjectAltNames) and does full name check. Further details can be found in bug 1178263.
Statement: Red Hat Product Security determined that this flaw was not a security vulnerability. See the Bugzilla link for more details.