CVE-2023-28321: IDN wildcard match

## Summary: curl /libcurl uses wildcards for validation during TLS communication, even if the hostname is an IDN. Even if wildcards are present in the CN/SAN of the certificate, they must not be used to match if the hostname is an IDN. This is described in [RFC-6125, section 6.4.3.][RFC] [RFC]: https://datatracker.ietf.org/doc/html/rfc6125#section-6.4.3 You probably know that. However, there was a problem with the implementation. `lib/vtls/hostcheck.c` in the function 'hostmatch' on lines 100-106. ``` /* We require at least 2 dots in the pattern to avoid too wide wildcard match. */ pattern_label_end = memchr(pattern, '.', patternlen); if(!pattern_label_end || (memrchr(pattern, '.', patternlen) == pattern_label_end) || strncasecompare(pattern, "xn--", 4)) return pmatch(hostname, hostlen, pattern, patternlen); ``` I think `strncasecompare(pattern, "xn--", 4))` is `strncasecompare(hostname, "xn--", 4))`. `pattern` is a value that contains wildcards because it is CN/SAN. In other words, it will not match "xn--" because it will be a string containing wildcards. ## Steps To Reproduce: 1. Create a wildcard certificate.As an example, attach a certificate and private key with CN value of `x*.example.local`. {F2298301} {F2298300} 2. `openssl s_server -accept 443 -cert server.crt -key server.key -www` 3. Modify hosts so that the name resolution result of `xn--l8j.example.local‘ is the IP of your machine in order to perform the test in the local environment. 4. `curl https://%E3%81%82.example.local --cacert server.crt` When the above is executed, the communication succeeds even though it should result in a validation error. ## Impact Improper Validation of Certificate with Host Mismatch.