bug(network): port-80 plaintext rest endpoints stall behind CONNECT-only upstream proxy (no deny, no relay) #4278

Summary

On a network where the only egress is an explicit corporate proxy that supports CONNECT/TLS only, any protocol: rest endpoint on port 80 (plain HTTP) is unusable: the sandbox L4 layer accepts the connection (synthetic IP), the supervisor dials upstream through the forward proxy, and the relay then stalls indefinitely — 0 bytes relayed, no HTTP:* audit event, workload-side curl eventually times out. The same host on port 443 works in the same sandbox with the same policy, so the failure is specific to plaintext HTTP through the CONNECT-only proxy chain.

Two things could be improved here, either one would unblock us:

1. relay plaintext HTTP through the upstream proxy chain (plain HTTP inside a CONNECT tunnel, or absolute-form forward-proxy requests if the proxy supports them), or
2. fail fast: reject/deny a port: 80 external endpoint at policy validation (sandbox create) with a distinct reason code, instead of stalling at connect time.

Environment

• OpenShell CLI/gateway/supervisor 0.1.2 (deb, Linux amd64), Docker driver
• Gateway driver config sets https_proxy to the corporate explicit proxy (port 3128) — the proxy chain accepts CONNECT/TLS and does not complete plaintext HTTP dials; no_proxy covers internal hosts
• On this network direct egress dials are impossible by design (the explicit proxy is the only egress path), so "skip the proxy for port 80" is not an option
• Sandbox workload image: NVIDIA ubuntu 24.04 base + curl; sandbox network is none (all egress via supervisor relay, as designed)

Repro

Task policy (task-policy-port80.yaml, minimal — same host on both ports):

version: 1
filesystem_policy:
  read_only: [/usr, /lib, /lib64, /etc, /bin, /sbin, /sandbox]
  read_write: [/tmp]
landlock:
  compatibility: hard_requirement
process:
  run_as_user: "1000"
network_policies:
  port80:
    name: port80-rest-readonly
    endpoints:
      - host: example.com
        port: 80
        protocol: rest
        access: read-only
        enforcement: enforce
    binaries:
      - path: /usr/bin/curl
  port443:
    name: port443-rest-readonly
    endpoints:
      - host: example.com
        port: 443
        protocol: rest
        access: read-only
        enforcement: enforce
    binaries:
      - path: /usr/bin/curl

Command:

$ openshell sandbox create --policy task-policy-port80.yaml -- bash -c \
    'curl --max-time 60 -v -sS -o /dev/null http://example.com/; echo $?; \
     curl --max-time 60 -v -sS -o /dev/null https://example.com/; echo $?'

Observed — port 80 (synthetic IP resolves and connects at L4, then nothing arrives):

* Host example.com:80 was resolved.
* IPv4: 198.18.0.2
* Trying 198.18.0.2:80...
* Connected to example.com (198.18.0.2) port 80
> GET / HTTP/1.1
* Operation timed out after 60002 milliseconds with 0 bytes received
curl: (28) Operation timed out

Observed — port 443, same sandbox, same policy, same host, immediately after: full TLS 1.3 handshake, HTTP/1.1 200 OK, curl exit 0.

OCSF audit log (openshell logs <name>) shows the asymmetry — no ALLOW event for the 80 leg, only the failure; the 443 leg gets the normal NET:OPEN + HTTP:GET pair:

[sandbox] [OCSF] NET:FAIL [LOW] 198.18.0.2:80
...
[sandbox] [OCSF] NET:OPEN [INFO] ALLOWED /usr/bin/curl(0) -> example.com:443 [policy:port443 engine:opa]
[sandbox] [OCSF] HTTP:GET [INFO] ALLOWED GET http://example.com:443/ [policy:port443 engine:l7]

Expected

Either plaintext HTTP to policy-approved port-80 endpoints relays through the CONNECT-only upstream proxy (HTTP-in-tunnel), or the endpoint is rejected up front:

• at sandbox create / policy validation, with a distinct deny reason code (e.g. "plaintext endpoint unreachable through CONNECT-only proxy"), or
• at the very least a fast, clearly-reasoned NET:FAIL/deny at connect instead of an open-ended stall with zero feedback to the workload (it looks like a hung network, not a policy/topology incompatibility).

Impact

• All http:// :80 endpoints — still common for package mirrors and internal/legacy services — are unusable on CONNECT-only-proxy networks.
• The failure is silent and looks like a network hang, so it costs real debugging time (we initially suspected our own DNS/proxy config; the audit log has no policy event at all for the allowed endpoint).

Notes / related issues

• feat(network): enable policy DNS and transparent TCP egress #2712 (transparent TCP egress) is adjacent but distinct: that one is about native TCP sockets and policy DNS for protocol: tcp; this one is protocol: rest through the configured upstream proxy.
• [Bug] Intermittent external egress failure: allowed request is followed by NET:FAIL #2514 covers intermittent NET:FAIL after successful requests; ours is deterministic and port-80-specific.
• feat: support plain HTTP forward proxy for private IP endpoints #155 (closed) added plain-HTTP forward-proxy support in the sandbox-side proxy for private IP endpoints; this report is about the supervisor's upstream dial through a corporate CONNECT-only proxy for external rest endpoints.