CVE-2023-28321: IDN wildcard match

How it was found

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.