Verify intercepted upstream certificates #48
No reviewers
Labels
No labels
bug
dependencies
documentation
duplicate
enhancement
good first issue
help wanted
invalid
question
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
mikluko/multiproxy!48
Loading…
Reference in a new issue
No description provided.
Delete branch "feat/verify-upstream"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Candidate 6 of the architecture review, together with the upstream verification gap.
handlers.DefaultTransportsetInsecureSkipVerify, so on an intercepted connection a client trusting multiproxy's CA could not tell a forged upstream from the real one.handlers.DefaultTransportverifies against the system roots, and a failed verification answers502 Bad Gatewayinstead of 500.proxy.Config.Transportmakes the upstream transport a declared seam.-upstream-ca <file>trusts a private CA beside the system roots, and-upstream-insecurerestores the old behaviour. The two are mutually exclusive.Tunnelled and plain-HTTP traffic is unaffected.
Breaking: an intercepted host with a self-signed or private-CA certificate now gets 502 until one of the flags is added. The changelog marks it.
Tests that intercept
httptestservers now trust the certificate those servers share, through theirClient().Transport, instead of relying on the insecure default. The router's routing test reaches its upstream aslocalhost, which that certificate does not name, so it skips verification with a comment saying why. New tests cover the 502 on an untrusted upstream, a trusted one, both flags, and the flag errors.Smoke run: intercepting
https://example.comthrough the binary with default verification returns 200. The reference, the interception how-to and the explanation page are updated. The suite passes three times in a row under-race.