Skip to main content

Zeq SSL Bridge — browser compatibility

Zeq-SSL is symmetric: a handshake needs a pre-shared credential, and a browser doesn't carry one. The Zeq SSL Bridge is the compatibility layer that squares this — it lets an ordinary browser reach a Zeq-SSL fleet without the browser having to speak the protocol.

What it does

The bridge terminates ordinary HTTPS (TLS 1.3) on the outside and speaks Zeq-SSL inward to your machines:

Browser → bridge

The browser makes a normal HTTPS request and gets a normal HTTPS response. It never knows Zeq-SSL exists.

Bridge → fleet

The bridge holds its own machine key, performs the Zeq-SSL handshake against the destination, and tunnels the cleartext between the two sockets. The destination sees a Zeq-SSL frame stream.

Native peers skip it

Anything that can speak Zeq-SSL directly — an SDK client, another machine — connects to the fleet without ever touching the bridge. Only browser traffic goes through it.

What it honestly does not do

The bridge is careful about a real limit, and says so: it does not manufacture identity. It signs its inward handshakes with its own credential, so anything it forwards is attested as "the bridge," not as the browser's user — and it writes the SSL-HANDSHAKE audit rows on behalf of the requesting principal. If you need end-to-end authentication, you run the SDK directly rather than going through the bridge. That candour is the point: the bridge buys browser reach, and it's explicit about the trust it can and can't carry.

Open it

  • Zeq-SSL — the symmetric credential system the bridge fronts.
  • The lattice — the fleet the bridge speaks inward to.
  • Proofs — why "attested as the bridge" is a meaningful, auditable statement.