HSTS accepted from HTTP origin behind HTTPS proxy

curl/libcurl appears to accept and persist Strict-Transport-Security from an http:// origin when the request is sent through an https:// proxy. After that, a later http:// request for the same host is automatically upgraded to https:// due to stored HSTS state. ## Affected versions 8.12.0 through 8.19.0 This appears to be introduced by commit 25b445e https://github.com/curl/curl/commit/25b445e4796bcbf9f842de686a8c384b30f6c2a2 As a side effect of that broad switch from handler-based SSL checks to connection-based SSL checks, the HSTS gate now passes for plain http:// requests sent over an HTTPS proxy because the first connection hop is TLS. ## Reproduction First request: ```bash curl -v \ --proxy https://127.0.0.1:18443 --proxy-insecure \ --hsts ./hsts-cache.txt \ http://hsts-probe.test:18080/ ```` origin replied with `Strict-Transport-Security: max-age=31536000` curl stored an HSTS entry for hsts-probe.test Second request with the same HSTS file: ```bash curl -v \ --proxy https://127.0.0.1:18443 --proxy-insecure \ --hsts ./hsts-cache.txt \ http://hsts-probe.test:18080/ ``` curl printed: `Switched from HTTP to HTTPS due to HSTS => https://hsts-probe.test:18080/` curl then sent `CONNECT hsts-probe.test:18080 HTTP/1.1` to the proxy I can provide a minimal test script if needed. ## Expected behavior An http:// origin response should not be able to set HSTS just because the proxy connection is HTTPS. Proxy TLS should not be treated as origin HTTPS for HSTS learning. ## Impact Persistent HSTS state can be learned for a host from an http:// origin when that origin is accessed through an https:// proxy, causing later http:// requests for that host to be automatically upgraded to https://