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
Read next
- 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.