CVE-2022-43551: Another HSTS bypass via IDN

## Summary: I found an issue similar to CVE-2022-42916 again. Since the phenomenon is the same, I will describe the same as last time. HSTS checks are bypassed if any character in the IDN convert(Nameprep) to a '.' for example"。"(UTF-8:E38082). I think there are other characters that become ".(UTF-8:2E)" as a result of converting with IDN. This is because the host name before IDN conversion is used when writing to the HSTS cache. ## Steps To Reproduce: [add details for how we can reproduce the issue] 1. Start from a state where there is no entry for the access destination host name in the HSTS cache 2. `curl -v --hsts hsts.txt https://accounts.google%E3%80%82com` 3. `curl -v --hsts hsts.txt http://accounts.google%E3%80%82com` Result of 3. ``` C:\test\curl-7.86.0-win64-mingw\bin>curl -v --hsts hsts.txt http://accounts.google%E3%80%82com --head * Trying 142.250.206.237:80... * Connected to accounts.google縲Ｄom (142.250.206.237) port 80 (#0) > HEAD / HTTP/1.1 > Host: accounts.google.com > User-Agent: curl/7.86.0 > Accept: */* > ``` If you execute 3. after executing the below, you will access the site with HTTPS. `curl -v --hsts hsts.txt https://accounts.google.com` I use [this](https://curl.se/download/curl-7.86.0.zip) in a Windows environment. I checked the HSTS cache after executing 2. and found the host name before IDN conversion. ``` # Your HSTS cache. https://curl.se/docs/hsts.html # This file was generated by libcurl! Edit at your own risk. .accounts.google。com "20231029 15:57:29" ``` I think the problem is in http.c:line 3727. data->state.up.hostname is the hostname of the IDN unconverted. ``` CURLcode check = Curl_hsts_parse(data->hsts, data->state.up.hostname, headp + strlen("Strict-Transport-Security:")); ``` ## Impact HSTS bypass.