fix(ssh): restore TLS-to-backend in web endpoint proxy

[gustavosbarreto]

Closes #6316.

What

Reintroduces the TLS-to-backend block in ssh/http/handlers.go::HandleHTTPProxy that was silently lost when ssh/pkg/tunnel/tunnel.go was deleted during the agent V2 multistream refactor. Until this lands, the tls.enabled / tls.verify / tls.domain fields captured by the UI and persisted by the API have no effect at runtime.

Behavior change

• When endpoint.TLS.Enabled is true, the proxy now wraps the raw tunnel net.Conn returned by Dialer.DialTo with tls.Client. SNI and the outgoing Host header are set to endpoint.TLS.Domain. endpoint.TLS.Verify toggles RootCAs = SystemCertPool() vs InsecureSkipVerify.
• req.URL is now reconstructed as http://<host>:<port>/<path> so req.Write produces a complete request line. Scheme stays http:// because tls.Client wraps the conn; the wire is TLS regardless of the URL scheme.
• Backend-side TLS minimum is tls.VersionTLS13.
• When TLS is disabled, behavior is unchanged: Host stays as <address>.<endpoints_domain>, no TLS wrap.

Verification

Reproduced and validated end-to-end against a local stack with a Python backend serving HTTP on 9080 and HTTPS on 9443. Both backends respond 200 only when Host: app.local, otherwise 302 Location: https://app.local/....

Endpoint	Target	TLS Domain	Before this PR	After this PR
A	127.0.0.1:9080 (HTTP)	n/a	302 -> https://app.local (canonical redirect, expected)	unchanged: 302 -> https://app.local
B	127.0.0.1:9443 (HTTPS), tls.enabled=true, tls.domain=app.local	app.local	504 Gateway Time-out (proxy wrote cleartext to TLS socket)	200 OK, backend logs Host: app.local

Backend log after the fix on scenario B:

[HTTPS:9443] GET /foo (Host='app.local')
    Host: app.local
    ...
-> 200 (Host matched 'app.local')

Out of scope (separate issues)

• Web endpoint: allow Host override independent of TLS to support backends that validate canonical hostname #6319 (allow Host override independent of TLS so HTTP-plain backends that validate canonical hostname also work)
• shellhub-io/cloud#2368 (web endpoint routes only registered in cloud branch, not enterprise-only)
• shellhub-io/cloud#2369 (SHELLHUB_WEB_ENDPOINTS not propagated to containers in dev mode)

[github-actions]

Claude finished @gustavosbarreto's task in 2m 29s —— View job

---

Code Review Complete

Reviewed 1 file across code quality, security, testing, Go patterns, and architecture — no issues found. The code looks good as-is.

The TLS-to-backend restoration is clean: correct use of tls.Client wrapping, proper MinVersion floor at TLS 1.3, system CA pool for verified connections, intentional InsecureSkipVerify gated behind the user-controlled TLS.Verify toggle, and consistent use of transportConn throughout the bidirectional copy. The error constant fix (ErrDeviceTunnelReadResponse → ErrDeviceTunnelParsePath) is also appropriate.

To request another review round, comment /review.

---

[gustavosbarreto]

/review

[github-actions]

Claude finished @gustavosbarreto's task in 6m 12s —— View job

---

Code Review Complete

Reviewed 1 file across code quality, security, testing, Go patterns, and architecture — no issues found. The code looks good as-is.

The TLS-to-backend restoration is clean: correct use of tls.Client wrapping, proper MinVersion floor at TLS 1.3, system CA pool for verified connections, intentional InsecureSkipVerify gated behind the user-controlled TLS.Verify toggle, and consistent use of transportConn throughout the bidirectional copy. The error constant fix (ErrDeviceTunnelReadResponse → ErrDeviceTunnelParsePath) is also appropriate. Cross-repo check confirmed no impact on cloud — the WebEndpointTLS JSON contract is unchanged.

To request another review round, comment /review.

---