Application-Layer E2EE for the Web Client (Zero-Trust Deployments)

[Lolozendev]

The built-in web client introduced in v0.43.0 is a highly useful addition, but I'd like to open a discussion regarding its data privacy model—specifically for IT and cybersecurity professionals dealing with sensitive servers and credential management.

Currently, the web client's transit security relies on Transport Layer Security (HTTPS/TLS). The challenge is that in most modern infrastructures, services are deployed behind reverse proxies (Caddy, Nginx) or edge tunnels (Cloudflare). In these setups, TLS is typically terminated at the proxy layer. Because the proxy decrypts the traffic before forwarding it to the backend service via WebSockets, the intermediate infrastructure gains full plaintext visibility into the terminal stream (STDIN and STDOUT).

For environments handling sensitive data, having a middlebox capable of reading the terminal output breaks the zero-trust model. While configuring strict Layer-4 TCP SNI passthrough is a workaround, it forces operators to abandon standard proxy benefits like path-based routing, WAFs, or centralized authentication.

Proposed Architecture
Introducing Application-Layer End-to-End Encryption (E2EE) for the web client's terminal payload would solve this without complicating network routing:

• The browser handles encryption and decryption natively via the Web Crypto API.
• The WebSocket stream carries only encrypted, opaque frames through the proxy layer.
• The Zellij daemon decrypts the payload locally using a pre-shared or exchanged key.

This guarantees that even if a shared ingress controller or proxy is compromised, the attacker only captures encrypted blobs.

Core Feature vs. Plugin API
I read the notes regarding the maintenance overhead of adding core features. Given how deeply integrated the web server is, E2EE might need to live in the core.

However, if there is a way to expose the web client's payload pipeline to the Wasm plugin API—perhaps allowing a plugin to intercept and process the WebSocket byte stream before it reaches the terminal emulator—the community could build and maintain the E2EE logic independently.

I'd appreciate the maintainers' thoughts on whether this fits into Zellij's architecture, either as a core enhancement or an expansion of the plugin API capabilities.

[imsnif]

Thanks for your thoughts, I fully agree. Something similar is being implemented and will ship soon.