Aller au contenu principal

Bridge — Browser-Compatible Zeq-SSL

Browsers can't speak Zeq-SSL natively — a symmetric handshake requires a pre-shared credential, and browsers don't carry one. The bridge at /apps/zeq-ssl-bridge/ (default port :3010) is an HTTPS-terminating proxy that speaks Zeq-SSL inward to your fleet.

Topology​

   browser ──TLS 1.3──▶  bridge :3010  ──Zeq-SSL──▶  destination :3009
                          │
                          ├─ holds its own zsm_key + SSL credential
                          ├─ performs the handshake on the request's behalf
                          └─ writes SSL-HANDSHAKE audit row for forensics

What the bridge does​

  • Terminates ordinary TLS 1.3 on :3010 using whatever cert your deployment configured (HTTPS_CERT_FILE / mkcert dev cert).
  • Performs the Zeq-SSL handshake against the destination state machine.
  • Streams request bytes inward as APP_DATA frames; streams response bytes outward as ordinary HTTPS.
  • Writes one SSL-HANDSHAKE audit row per connection (default-on — flip the per-credential audit_handshakes column off for high-volume sites).

What the bridge does NOT do​

  • End-to-end authentication. Anything the bridge sends inward is attested as the bridge, not as the originating browser principal. The bridge cannot hold per-user keys without becoming a key custodian — which would defeat the symmetric-only PQ posture.
  • Custom protocol handling. The bridge is a byte-level relay. Application semantics (HTTP method, headers, body parsing) ride through unchanged.

Post-quantum posture​

  • Inner Zeq-SSL leg: PQ-safe (AES-256-GCM + HMAC-SHA256 + SHA-256).
  • Outer TLS leg: inherits whatever the configured cert chains to. P-256 / RSA → not PQ-safe; ML-KEM hybrids → PQ-safe to the extent the named hybrid is.

Mode 1 (native) is PQ-safe. Mode 2 (bridge) is PQ-safe at the application layer but inherits the outer TLS's PQ posture.

Backing endpoint​

The bridge uses POST /api/ssl/handshake/verify to validate its handshake envelope server-side, then mirrors the bytes. The endpoint is wired and tested in Phase 2.1; the :3010 reverse-proxy listener lands in Phase 2.2.

Configuration​

The bridge runs as a separate process — apps/zeq-ssl-bridge/server.ts in Phase 2.2 — and pulls its zsm_key from ZSC under ssl_bridge_zsm_key:<bridge_machine_id>. The destination machines are resolved via Host header → state-machine slug lookup.