feat: support downstream TLS for Web App resources

[clement0010]

Related Tickets & Documents

• Issue: closes Support downstream TLS for Web App resources #420

Changes

• Parse the tls flag in the GAT token's gateway_metadata.downstream; tokens without the flag keep today's plaintext behavior.
• Terminate TLS at the Gateway for Web App connections when the GAT enables it: the connection goes through the same inner TLS upgrade Kubernetes connections use today, presenting the gateway certificate.
• Set X-Forwarded-Proto with the downstream scheme before forwarding the request
• Local dev tooling: the fake Twingate client gains a WithDownstreamTLS() option and tools/local runs an extra Web App client with it, testable via curl --cacert ./test/data/proxy/tls.crt https://<client-address>.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.70%. Comparing base (1d408f8) to head (fb053cf).
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #422      +/-   ##
==========================================
+ Coverage   90.63%   90.70%   +0.07%     
==========================================
  Files          41       41              
  Lines        2903     2915      +12     
==========================================
+ Hits         2631     2644      +13     
+ Misses        180      177       -3     
- Partials       92       94       +2     

Flag	Coverage Δ
integration	57.70% <76.92%> (+0.07%)	⬆️
unit	85.79% <100.00%> (+0.09%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
internal/token/gat_claims.go	100.00% <100.00%> (ø)
internal/webapphandler/handler.go	100.00% <100.00%> (ø)

... and 2 files with indirect coverage changes

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[Copilot]

Pull request overview

Adds support for terminating downstream TLS for Web App resources based on a new gateway_metadata.downstream.tls flag carried in the GAT, aligning Web App handling with the existing “inner TLS upgrade” path used for Kubernetes connections. Also extends local dev tooling to exercise both plaintext and TLS-enforced Web App flows.

Changes:

• Extend GAT claims with gateway_metadata.downstream.tls and include Web App resources in ShouldUpgradeTLS() when the flag is set.
• Add a WithDownstreamTLS() option to the fake client and run an additional local Web App client configured for HTTPS testing.
• Fix local gateway config template to use webApp.requestHeaders (matching the existing config schema).

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.

File	Description
tools/local/main.go	Runs an additional fake Web App client for downstream TLS and updates local config/output instructions accordingly.
test/fake/client.go	Adds a client option to mark downstream TLS in the generated GAT and switch the downstream port to 443.
internal/token/gat_claims.go	Adds Downstream.TLS to GAT claims and updates TLS-upgrade decision logic for Web App resources.
internal/token/gat_claims_test.go	Expands unit tests to cover the new Web App TLS-upgrade behavior and JSON unmarshalling of the new flag.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[github-actions]

This pull request is stale because it has been open 5 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[minhtule]

LGTM 👍

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.

Suppressed comments (1)

internal/token/gat_claims_test.go:48

• These cases only verify the metadata flag and the ShouldUpgradeTLS boolean; they never exercise a Web App connection through the listener and HTTP proxy with the inner TLS handshake. A regression in the actual termination/routing path could therefore pass these tests. Please add an integration (or equivalent end-to-end) case that uses WithDownstreamTLS, trusts tls.crt, and verifies the proxied response and headers.

			name:          "Web app with downstream TLS should upgrade TLS",
			resourceType:  ResourceTypeWebApp,
			downstreamTLS: true,
			expected:      true,

[sghiocel]

It seems that the gateway needs to add X-Forwarded-Proto to solve for this kind of issue:

Without X-Forwarded-Proto:

[1] Browser address bar:  https://grafana.acme.int/
[2] Gateway decrypts TLS, forwards upstream over plain HTTP

[3] App receives, verbatim:
      GET / HTTP/1.1
      Host: grafana.acme.int
      X-Forwarded-Proto: ""      <- the only way it can know
      r.TLS == nil ? true        <- its own leg is plaintext, by design

[4] App concludes scheme="http", replies:
      HTTP/1.1 302 Found
      Location: http://grafana.acme.int/login?redirect_uri=http://grafana.acme.int/callback

[5] Browser receives that Location
[6] Browser obeys it and goes to http://...
[7] That request to the Gateway returns: EOF
    ❌ LOGIN IS DEAD

With:

[3] App receives, verbatim:
      GET / HTTP/1.1
      Host: grafana.acme.int
      X-Forwarded-Proto: "https"    <- now it knows
      r.TLS == nil ? true           <- still plaintext, still by design

[4] App concludes scheme="https", replies:
      HTTP/1.1 302 Found
      Location: https://grafana.acme.int/login?redirect_uri=https://grafana.acme.int/callback

[6] Browser follows over HTTPS -> stays on the working path
    ✅ LOGIN WORKS

[Copilot]

Pull request overview

Copilot reviewed 7 out of 7 changed files in this pull request and generated no new comments.

Suppressed comments (2)

internal/token/gat_claims.go:98

• This branch is what makes the existing listener perform the second TLS handshake, but the added tests only assert the boolean/header and the integration test still exercises a plaintext Web App. Add an end-to-end Web App case with downstream.tls=true that sends an inner TLS request and verifies the proxied response; otherwise the actual TLS termination/routing path can regress while these tests pass.

	case ResourceTypeWebApp:
		return p.Resource.GatewayMetadata.Downstream.TLS

test/integration/web_app_test.go:122

• The new TLS behavior is not exercised by this integration test: it still creates only the plaintext Web App client and only verifies X-Forwarded-Proto: http. A regression in the inner TLS handshake, gateway certificate presentation, or routing of the decrypted request would therefore pass the suite. Add a TLS-enabled fake client and an HTTPS request that trusts test/data/proxy/tls.crt, asserting the response and X-Forwarded-Proto: https.

		// Downstream scheme
		"X-Forwarded-Proto": "http",

[Copilot]

Pull request overview

Copilot reviewed 7 out of 7 changed files in this pull request and generated 1 comment.

Suppressed comments (1)

internal/token/gat_claims.go:98

• The new Web App path is only exercised by the ShouldUpgradeTLS and header-rewrite unit tests; the integration test still sends only http://..., so no test drives the listener's second TLS handshake and HTTP server with a GAT containing downstream.tls: true. Please add an HTTPS Web App integration case and assert the proxied response (including X-Forwarded-Proto) to cover the end-to-end behavior advertised by this change.

		return p.Resource.GatewayMetadata.Downstream.TLS

[clement0010]

@sghiocel I added the X-Forwarded-Proto header in 66f15ac, could you review again?