Skip to content

fix: always verify TLS on aibridgeproxyd upstream transport#26131

Merged
ssncferreira merged 2 commits into
mainfrom
ssncf/aibridgeproxyd-verify-tls
Jun 9, 2026
Merged

fix: always verify TLS on aibridgeproxyd upstream transport#26131
ssncferreira merged 2 commits into
mainfrom
ssncf/aibridgeproxyd-verify-tls

Conversation

@ssncferreira

@ssncferreira ssncferreira commented Jun 8, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

Problem

aibridgeproxyd's HTTP transport (proxy.Tr) was configured with secure TLS defaults only when an upstream proxy was set. Without one, it fell back to goproxy's default transport, which has InsecureSkipVerify: true, leaving the connection between the proxy and aibridge vulnerable to MITM on HTTPS deployments.

This PR moves the secure transport assignment outside the upstream proxy branch so it applies unconditionally.

Changes

  • Apply secure TLS defaults to proxy.Tr unconditionally (verified RootCAs, MinVersion: TLS 1.2).
  • Add TestProxy_AIBridgeTLSVerification to cover the verification path between the proxy and aibridge.

Notes

  • Behavior change for HTTPS_PROXY env var: previously, when UpstreamProxy was unset, proxy.Tr honored HTTP_PROXY and HTTPS_PROXY env vars. After this PR it does not, since MITM'd requests now always go directly to aibridge. This matches the behavior when UpstreamProxy is configured, which already ignored env vars.
  • HTTPS deployments with a private CA: when CoderAccessURL is HTTPS and its TLS certificate (or the load balancer's certificate fronting it) is signed by a CA not in the system trust store, the proxy will now fail with x509: certificate signed by unknown authority.

Closes https://linear.app/codercom/issue/AIGOV-386/ai-bridge-proxy-uses-goproxy-default-with-tls-verification-disabled

Note

Initially generated by Claude Opus 4.7, modified and reviewed by @ssncferreira

@ssncferreira Graphite App

ssncferreira commented Jun 8, 2026

Copy link
Copy Markdown
Contributor Author

This stack of pull requests is managed by Graphite. Learn more about stacking.

@linear-code

linear-code Bot commented Jun 8, 2026

Copy link
Copy Markdown

AIGOV-386

@ssncferreira ssncferreira marked this pull request as ready for review June 8, 2026 09:49
@jdomeracki-coder

jdomeracki-coder commented Jun 8, 2026

Copy link
Copy Markdown
Contributor

Are we worried that this might cause issues in real world deployments?

HTTPS deployments with a private CA: when CoderAccessURL is HTTPS and its TLS certificate (or the load balancer's certificate fronting it) is signed by a CA not in the system trust store, the proxy will now fail with x509: certificate signed by unknown authority.

If so, should we perhaps adjust the docs to mention that explicitly?

dannykopping
dannykopping approved these changes Jun 8, 2026
View reviewed changes

@dannykopping dannykopping left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

jdomeracki-coder
jdomeracki-coder approved these changes Jun 8, 2026
View reviewed changes

@jdomeracki-coder jdomeracki-coder left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approving setting potential doc adjustments aside

@ssncferreira ssncferreira force-pushed the ssncf/aibridgeproxyd-verify-tls branch from aaae0b6 to 71062aa Compare June 8, 2026 19:05
@github-actions

github-actions Bot commented Jun 8, 2026

Copy link
Copy Markdown

Docs preview

📖 View docs preview for docs/ai-coder/ai-gateway/ai-gateway-proxy/setup.md

@ssncferreira ssncferreira changed the title fix(enterprise/aibridgeproxyd): always verify TLS on upstream transport fix: always verify TLS on aibridgeproxyd upstream transport Jun 8, 2026
@ssncferreira

ssncferreira commented Jun 8, 2026

Copy link
Copy Markdown
Contributor Author

Are we worried that this might cause issues in real world deployments?

HTTPS deployments with a private CA: when CoderAccessURL is HTTPS and its TLS certificate (or the load balancer's certificate fronting it) is signed by a CA not in the system trust store, the proxy will now fail with x509: certificate signed by unknown authority.

If so, should we perhaps adjust the docs to mention that explicitly?

AFAIK, we don't have data on how AI Gateway Proxy is typically deployed, but this shouldn't affect most deployments. It only happens when the Coder access URL is HTTPS and its TLS certificate is signed by a self-signed or internal CA not in the system trust store.
That said, it's a good point and worth documenting. I added a troubleshooting section to the AI Gateway Proxy setup docs: 71062aa
Let me know what you think @jdomeracki-coder

@ssncferreira ssncferreira merged commit a9fb261 into main Jun 9, 2026
35 of 36 checks passed
@ssncferreira ssncferreira deleted the ssncf/aibridgeproxyd-verify-tls branch June 9, 2026 10:53
@github-actions github-actions Bot locked and limited conversation to collaborators Jun 9, 2026
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Reviewers

@dannykopping dannykopping dannykopping approved these changes

@jdomeracki-coder jdomeracki-coder jdomeracki-coder approved these changes

Assignees

@ssncferreira ssncferreira

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

@ssncferreira @jdomeracki-coder @dannykopping