curl: 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.