Background

PR #1091 fixed the TLS CONNECT intercept path to respect the configured upstream_proxy / external_proxy (issue #1048). However, support for authenticated corporate proxies (where the proxy itself requires a Proxy-Authorization header) was explicitly left out with a fail-secure 502 and this note in the code:

Auth is configured but not yet implemented. Fail loudly rather than silently connecting without auth — the corporate proxy would reject anyway.

The InterceptUpstreamProxy struct introduced in #1091 already has a proxy_auth_header: Option<&str> field reserved for this, but server.rs never sets it to Some(...) — the auth branch always returns early with a 502.

Current behaviour

If external_proxy is configured with an auth section in the profile, any TLS-intercepted request returns:

HTTP/1.1 502 Bad Gateway

with the message:

external proxy authentication is configured but not yet implemented; remove the auth section from the external proxy config or wait for a future release

Expected behaviour

nono-proxy should support authenticated upstream proxies in the TLS intercept path, the same way other proxy clients do: by sending a Proxy-Authorization header on the CONNECT request to the corporate proxy.

Scope

• Populate proxy_auth_header in InterceptUpstreamProxy when auth is configured in ext_config.auth
• Remove or replace the 502 early-return in server.rs::handle_connection for the intercept path
• Handle at minimum HTTP Basic auth (Base64-encoded username:password), consistent with how the rest of the proxy handles Proxy-Authorization
• Add unit and/or integration tests covering the authenticated proxy path
• Consider whether credentials passed to the corporate proxy should be zeroized after use (per project memory-safety policy)

Related

• Issue: TLS CONNECT interception ignores configured upstream_proxy #1048
• PR: fix(proxy): respect upstream_proxy in TLS CONNECT intercept path (#1048) #1091 (introduced the stub and the 502 guard)