Skip to content

windows: use Windows store roots for upstream-proxy origin TLS - #268

Open
VIVAAN-DHAWAN wants to merge 1 commit into
fkiene:mainfrom
VIVAAN-DHAWAN:fix/windows-proxy-tls-roots
Open

windows: use Windows store roots for upstream-proxy origin TLS#268
VIVAAN-DHAWAN wants to merge 1 commit into
fkiene:mainfrom
VIVAAN-DHAWAN:fix/windows-proxy-tls-roots

Conversation

@VIVAAN-DHAWAN

Copy link
Copy Markdown

Problem

PR #257 fixed the direct Windows outbound path: native roots from the Windows cert stores, rustls verification kept, inherited SSL_CERT_FILE / SSL_CERT_DIR ignored. The LLMTRIM_UPSTREAM_PROXY path was left unchanged.

When LLMTRIM_UPSTREAM_PROXY is set, origin TLS goes through hyper-http-proxy's ProxyConnector::from_proxy with the rustls-tls-native-roots feature → hyper-rustls with_native_roots()rustls-native-certs::load_native_certs(). That loader:

  1. Preferentially reads only SSL_CERT_FILE / SSL_CERT_DIR when either is set (OS store skipped).
  2. On Windows without those vars, opens only CurrentUser\ROOT (no LocalMachine).

So an enterprise user behind both HTTPS inspection AND an upstream proxy can still get UnknownIssuer / Claude Code 529.

Fix

On Windows only, re-seed the origin TlsConnector with the same windows_root_store() builder the direct path uses (set_tls after from_proxy):

  • Same trust set as the direct Windows path (fix(proxy): trust Windows certificate roots for upstream TLS #257): CurrentUser + optional LocalMachine ROOT, serverAuth EKU, time-valid.
  • Full rustls verification stays on (no verify-off).
  • Inherited SSL_CERT_FILE / SSL_CERT_DIR are ignored on this path too.
  • Non-Windows behavior is byte-for-byte unchanged (the old from_proxy construction).

Verification

  • cargo check -p llmtrim (host) and cargo check -p llmtrim --no-default-features --lib (CI variant)
  • cargo clippy -p llmtrim --all-targets -- -D warnings, cargo fmt --all -- --check, taplo fmt --check
  • Existing proxy_connector_origin_tls_is_active regression (still guards the construction path)
  • Microsoft Windows SDK not present on this runner, so the cfg(windows) arm could not be type-checked end-to-end here; the API usage mirrors the already-shipped windows_native_roots_connector (fix(proxy): trust Windows certificate roots for upstream TLS #257) and set_tls's Option<tokio_rustls::TlsConnector> signature in hyper-http-proxy 1.1.1 (rustls-tls-native-roots__rustls).

Fixes #259

ProxyConnector::from_proxy builds the CONNECTed origin TLS leg via
rustls-native-certs load_native_certs(), which ignores the OS stores
when SSL_CERT_FILE/SSL_CERT_DIR are inherited and otherwise only reads
CurrentUser\ROOT — so an enterprise user behind HTTPS inspection AND an
upstream proxy can still get UnknownIssuer (fkiene#259).

On Windows, re-seed the origin TlsConnector with the same
windows_root_store() builder the direct path uses (CU + optional LM,
serverAuth EKU, time-valid). rustls verification stays on; non-Windows
behavior is unchanged.

Tests: cargo check (host + no-default-features), clippy --all-targets
-D warnings, fmt, taplo, existing proxy_connector_origin_tls_is_active
regression, plus a macOS/windows cross-target check where aws-lc-sys
C-build tooling was available.

Signed-off-by: Vivaan Dhawan <150339722+VIVAAN-DHAWAN@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Windows enterprise roots: LLMTRIM_UPSTREAM_PROXY still honors SSL_CERT_*

1 participant