Skip to content

fix(forward): with a token set, every HTTPS request was refused - #5

Closed
praxagent wants to merge 1 commit into
mainfrom
fix/forward-auth-https
Closed

praxagent wants to merge 1 commit into
mainfrom
fix/forward-auth-https

Conversation

@praxagent

Copy link
Copy Markdown
Owner

The bug

With PROXY_FORWARD_AUTH_TOKEN set, the forward proxy refused every HTTPS request, right token or not. Plain HTTP worked.

  • HTTPS sends Proxy-Authorization on the CONNECT only, and the requests tunnelled through it carry none.
  • Auth ran only in the request hook, so it never saw a credential.
  • Found while live-testing per-program rules.
  • No deployment is affected, because none can run with the token: production's HTTPS_PROXY carries no credential, so its proxy runs open on loopback, with the startup warning. The documented hardening could not be switched on without breaking every model call.

The fix

  • Authenticate at http_connect and remember the caller per client connection in a WeakKeyDictionary. This is the shape of mitmproxy's own proxyauth addon.
  • A plain-HTTP request still carries its own credential, and is checked as before.
  • Also fixed: the injection audit line read the caller after the credential was stripped, so it always said caller=-. The caller is now read before the strip. feat: a wire record of what the agent asked the model, outside the agent #3 carries the same one-line fix, so whichever merges second needs a trivial rebase; I'll do it.

Verified

  • Real mitmproxy (mitmproxy/mitmproxy:latest), throwaway container, no credentials loaded:

    Request Before After
    HTTPS, right token 407 200
    HTTPS, wrong token 407 407 at CONNECT
    HTTPS, no token 407 407 at CONNECT
    HTTP, right token 200 200
    HTTP, no token 407 407
  • Unit: 5 new tests. An authenticated tunnel carries its requests; a bad CONNECT is refused; another connection doesn't inherit a tunnel; with no token configured, tunnels stay open; the audit line names the tunnel's caller. 68 passed, ruff clean.

After merge

To actually turn the token on, Prax's HTTPS_PROXY needs http://prax:<token>@…. That is a production .env change for TJ to decide, and I haven't touched it.

HTTPS sends the proxy credential on the CONNECT only; the tunnelled requests
carry none, and auth ran only in the request hook. So setting
PROXY_FORWARD_AUTH_TOKEN refused every HTTPS request, right token or not —
which is why no deployment runs with it. Authenticate at http_connect and
remember the caller per client connection (the shape of mitmproxy's own
proxyauth addon). Also: the audit line read the caller after the credential
was stripped, so it always said caller=-.
@praxagent

Copy link
Copy Markdown
Owner Author

Folded into #8 (stacked PRs re-conflict after every squash merge). Every commit from this branch is in #8 — merge that one.

@praxagent praxagent closed this Oct 2, 2026
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.

1 participant