sec(server): unauthenticated WebSocket tunnel bypasses mTLS #576

Summary

The /_ws_tunnel endpoint in crates/openshell-server/src/ws_tunnel.rs (lines 42–51) accepts WebSocket upgrades without any authentication. The handler immediately upgrades the connection and pipes raw TCP bytes into the MultiplexService, granting the WebSocket client the same access as a direct mTLS client — full gRPC and HTTP access.

This completely bypasses mTLS client certificate verification. Any client that can reach the /_ws_tunnel endpoint can establish a WebSocket connection and send arbitrary gRPC/HTTP requests through it.

Impact

• Severity: High
• In practice, this endpoint is designed to sit behind a Cloudflare edge proxy that handles authentication. However, if the server is directly exposed (or the edge proxy is misconfigured), this is a full authentication bypass.
• An attacker could create sandboxes, execute commands, delete resources, and access credentials.

Reproduction

1. Start a gateway with --disable-gateway-auth or with the WS tunnel exposed
2. Connect to ws://<host>:<port>/_ws_tunnel with no credentials
3. Send gRPC frames through the WebSocket — all RPCs are accessible

Proposed Fix

Add bearer token or JWT validation in the WebSocket upgrade handler before accepting the connection. At minimum, require and validate the cf-access-jwt-assertion header on the upgrade request.

sequenceDiagram
    participant Attacker
    participant Server as Gateway Server
    participant WS as /_ws_tunnel
    participant Multiplex as MultiplexService

    Attacker->>Server: WebSocket upgrade (no creds)
    Server->>WS: ws_tunnel_handler()
    Note over WS: No auth check ❌
    WS->>Multiplex: duplex stream
    Attacker->>Multiplex: gRPC CreateSandbox
    Multiplex->>Attacker: Sandbox created