Zeroserve, eBPF Web Serving, and the mTLS Browser UX Nightmare

Zeroserve, eBPF Web Serving, and the mTLS Browser UX Nightmare

The systems engineering community is continually pushing the boundaries of local hardware performance, resulting in highly specialized runtimes like zeroserve—a high-performance HTTPS server that JIT-compiles Caddyfiles into userspace eBPF and native machine code running in an io_uring event loop.

While zeroserve's benchmarks show a stunning 3x throughput and 70% lower latency compared to Caddy, the project's launch has catalyzed a deep debate on the trade-offs between raw, low-level performance gains and the operational maturity required for production web infrastructure.

Raw Performance vs. Operational Reality

Zeroserve achieves its extreme speed by bypassing traditional user-to-kernel boundaries, leveraging userspace eBPF (via a custom runtime, rather than the Linux kernel's restricted verifier) and compiling configuration rules directly to native x86_64/ARM64 machine code.

However, the developer community remains deeply skeptical of these benchmarks. Critics point out that:

1. The Backend Is the Bottleneck: In almost all real-world applications, the backend application server (database, API, etc.) is slower than the proxy by orders of magnitude, making proxy-level latency micro-optimizations irrelevant.
2. Missing Mission-Critical Features: Zeroserve lacks support for ACME (automatic SSL certificate generation and renewal) and a mature plugin ecosystem—features that make Caddy and Nginx indispensable for modern deployments. Without ACME, a web server is virtually unusable in a standard production environment.

The Genuinely Surprising Side Effect: The mTLS Browser UX Nightmare

A highly surprising and illustrative incident occurred when Hacker News users tried to visit the zeroserve author's technical blog (su3.io) to read the announcement. Visitors using Chrome, Firefox, Arc, and Zen browsers were suddenly hit with a highly intrusive, confusing popup asking them to select a personal client certificate (such as those used for government tax filing or corporate intranets).

This occurred because the author's server was configured to request Mutual TLS (mTLS) client certificates. While client-side certificate authentication is highly secure and common in strict corporate or government intranets, it is virtually non-existent on the public web due to an incredibly broken browser User Experience (UX):

• No Context or Filtering: When a server requests a client certificate, browsers simply list every certificate installed on the user's machine, regardless of its relevance or authority, leading to privacy panics as users worry a site is attempting to "read" their tax IDs or personal credentials.
• Terrible Error Handling: Browsers do not provide a clean way for site owners to handle a failed mTLS handshake, redirect users, or gracefully fall back to alternative authentication methods.

This minor panic highlighted how advanced security primitives (like mTLS) remain locked away from mainstream adoption due to the fossilized, decades-old user interface designs of major web browsers.¹