Skip to main content

proxy_is_active

keyhog_verifier

Function proxy_is_active 

Source 
pub fn proxy_is_active(explicit: Option<&str>) -> bool
Expand description

Returns true iff the resolved proxy policy actually routes traffic through a proxy. Mirrors [apply_proxy_config]’s mode resolution:

  • explicit Some(url) or KEYHOG_PROXY=<url> → true
  • explicit Some("off"|"none"|"") or KEYHOG_PROXY=off|none|"" → false
  • none of those set → checks reqwest’s standard env-proxy vars (HTTPS_PROXY, HTTP_PROXY, ALL_PROXY). NO_PROXY alone does not make a proxy active. Empty strings count as unset, matching reqwest’s own builder behavior.

Issue #2: pre-fix proxy_in_use was set from KEYHOG_PROXY.is_some() alone - KEYHOG_PROXY=off (documented “disable” sentinel) ALSO set the flag to true, which in turn disabled DNS pinning in resolved_client_for_url() even though no proxy was active. Operators using KEYHOG_PROXY=off for direct-connect verification lost DNS- rebinding protection.

Issue #3: pre-fix the check ignored reqwest’s standard HTTPS_PROXY / HTTP_PROXY / ALL_PROXY env vars even though the shared client honored them via reqwest defaults. A user with HTTPS_PROXY=http://burp:8080 got proxy_in_use == false → verifier rebuilt the pinned client from scratch and dropped the env-proxy. The pinned path then connected direct, bypassing the operator’s interception/audit layer. Including the reqwest env vars closes that gap.