Rewriting the URL sounds like it would also allow hitting a dummy server in tests. But how does the rewrite actually happen? If you have the literal URL in your code, then fine, but what if you don't?
I agree that there are downsides to this approach. NVIDIA OpenShell does the same thing: https://docs.nvidia.com/openshell/latest/sandboxes/manage-pr.... I had wondered how they deal with the fact that client programs sometimes come with their own CA bundles. Turns out OpenShell sets various common environment variables (like REQUESTS_CA_BUNDLE used by Python's requests) to try to convince as many clients as possible that the proxy's certificate is to be trusted :) I would assume exe.dev does something similar.
(I was interested in this because I was actually working on something similar recently: https://github.com/imbue-ai/latchkey. To avoid the certificates issue, this library uses a gateway approach instead of a proxy, i.e. clients call endpoints like "http(s)://gateway.url:port/gateway/https://api.github.com/..." which can be effectively hidden behind the "latchkey curl" invocation.)
thankfully more and more projects are supporting the "standard" SSL_CERT_DIR/SSL_CERT_FILE environment variables [1]
i think requests is a tricky one, as it _should_ be supporting it already based on the PR [2], but looks like it was merged in the 3.x branch and idk where that is, release-wise.
there is also native TLS on linux (idk what exactly you call it); but
slightly related, one of the more interesting issues i've faced due to mitm tls by the $job mandated CASB (cloud-access security broker)
is when python 3.13 [1] introduced some stricter validations and the CASB issued certs were not compliant (missing AKI); which broke REQUESTS_CA_BUNDLE/SSL_CERT_FILE for us
we recently moved to a similar approach, inspired by gondolin which does the same: https://earendil-works.github.io/gondolin/secrets/
an 'mitm' tls proxy also gives you much better firewalling capabilities [1], not that firewalls aren't inherently leaky,
codex's a 'wildcard' based one [2]; hence "easy" to bypass [3] github's list is slightly better [4] but ymmv
[1] than a rudimentary "allow based on nslookup $host" we're seeing on new sandboxes popping up, esp. when the backing server may have other hosts.
[2] https://developers.openai.com/codex/cloud/internet-access#co...
[3] https://embracethered.com/blog/posts/2025/chatgpt-codex-remo...
[4] https://docs.github.com/en/copilot/reference/copilot-allowli...
Rewriting the URL sounds like it would also allow hitting a dummy server in tests. But how does the rewrite actually happen? If you have the literal URL in your code, then fine, but what if you don't?
Confused here - setting up certs to MITM https requests to add a header seems like a decently big security risk?
I agree that there are downsides to this approach. NVIDIA OpenShell does the same thing: https://docs.nvidia.com/openshell/latest/sandboxes/manage-pr.... I had wondered how they deal with the fact that client programs sometimes come with their own CA bundles. Turns out OpenShell sets various common environment variables (like REQUESTS_CA_BUNDLE used by Python's requests) to try to convince as many clients as possible that the proxy's certificate is to be trusted :) I would assume exe.dev does something similar.
(I was interested in this because I was actually working on something similar recently: https://github.com/imbue-ai/latchkey. To avoid the certificates issue, this library uses a gateway approach instead of a proxy, i.e. clients call endpoints like "http(s)://gateway.url:port/gateway/https://api.github.com/..." which can be effectively hidden behind the "latchkey curl" invocation.)
thankfully more and more projects are supporting the "standard" SSL_CERT_DIR/SSL_CERT_FILE environment variables [1]
i think requests is a tricky one, as it _should_ be supporting it already based on the PR [2], but looks like it was merged in the 3.x branch and idk where that is, release-wise.
there is also native TLS on linux (idk what exactly you call it); but
all languages also seem to have packages around providing cert bundles which get used directly (e.g., certifi [3]), which does cause some pain[1] https://github.com/rustls/rustls-native-certs/issues/16#issu...
[2] https://github.com/psf/requests/issues/2899
[3] https://pypi.org/project/certifi/
slightly related, one of the more interesting issues i've faced due to mitm tls by the $job mandated CASB (cloud-access security broker)
is when python 3.13 [1] introduced some stricter validations and the CASB issued certs were not compliant (missing AKI); which broke REQUESTS_CA_BUNDLE/SSL_CERT_FILE for us
[1] https://discuss.python.org/t/python-3-13-x-ssl-security-chan...
Things aren't just "good" or "bad". There are tradeoffs to consider.