ECH/SNI Isolation Through a TLS-in-TLS Tunnel My R&amp;D Proxy...

ECH/SNI Isolation Through a TLS-in-TLS Tunnel My R&D Proxy Attempt

Posted 2025-11-30 20:58:34

681

By Jay Govibe R&D Log Introduction In the past weeks, I’ve been experimenting with a concept that sits between cryptography, reverse proxies, and deep network engineering. The idea was simple on paper but extremely complex in practice: to isolate ECH (Encrypted Client Hello) and SNI (Server Name Indication) by using a TLS-in-TLS triple-handshake encrypted tunnel acting as a web server reverse proxy. This project is not production-ready and not meant to compete with full-scale proxies like Nginx or Caddy. It’s a pure R&D experiment, built to explore what happens when you place a custom encrypted layer before ECH/SNI on port 443. And the results were fascinating. Why ECH and SNI Matter ECH and SNI are both part of the HTTPS/TLS handshake. Normally: SNI reveals the requested domain name in plaintext ECH encrypts that domain name so intermediaries cannot see it But the challenge is this: ECH happens extremely early in the TLS negotiation. To intercept or modify anything before SNI/ECH, a system must sit before the server handshake and must be able to handle the encrypted layers without breaking the flow. That’s where the idea of a TLS-in-TLS tunnel came from. The Concept: A TLS-in-TLS Triple-Handshake Tunnel The architecture I built is essentially: Client (Your Web Browser)   ↓ TLS1.3 (outer tunnel) Proxy     ↓ TLS1.3 (inner handshake) Backend Web Server Reverse Proxy A triple-handshake occurs: Outer TLS handshake between client → tunnel Inner TLS handshake between tunnel → backend A control-handshake used internally to synchronize metadata (experimental) This structure forms an encrypted “tunnel web server” that doubles as a reverse proxy. Its goal: ✔ Protect ECH/SNI ✔ Wrap all traffic in another encryption layer ✔ Explore behavior of early handshake interception ✔ Push low-level TLS research forward Early Results My prototype currently handles about 40 elements loading simultaneously — images, scripts, thumbnails, small videos. After ~40 network requests, the system begins to display: latency spikes buffer stalls freeze conditions load limits on the event loop This was expected, because the initial code is not optimized for concurrency. It’s written in C with a simple blocking model, and TLS handshakes are extremely expensive at scale. But for a first experiment, the results are solid. Where It Breaks Once the load becomes heavy, the proxy struggles with: handshake synchronization multi-stream concurrency buffer reuse socket exhaustion slow round-trip loops inside the tunnel The proxy was not designed for mass parallelism. And that’s the entire point of R&D: Find what breaks. Break it harder. Then rebuild it better. Why Move to QUIC After experimenting with TLS-only tunnels, the next step is clear: QUIC. QUIC has: multiplexed streams no head-of-line blocking integrated TLS 1.3 cleaner parallelism Caddy already uses it extremely well Rewriting the proxy with QUIC-based architecture inspired by Caddy’s internal design should: ✔ eliminate freezes ✔ handle load better ✔ allow parallel asset loading ✔ reduce handshake bottlenecks ✔ improve latency under stress This is not a simple rewrite — it’s a full redesign of the event model. But it’s the right direction. Why This Experiment Matters Most people don’t build reverse proxies. Even fewer build encrypted tunnels. And very, very few experiment with handshake-layer manipulation. This type of work belongs to the R&D side of networking — the same territory occupied by: CDN engineers cryptography researchers protocol developers enterprise proxy architects QUIC implementers This project is simply my contribution to exploring these ideas. What’s Next Here’s the plan moving forward: Rewrite the event loop using QUIC-like patterns Replace blocking sockets with async multiplexed streams Reduce handshake overhead Test concurrent asset loading at scale Benchmark vs Caddy (just for fun) Document the internal architecture Release diagrams and simplified PoC code later This is not about shipping a product. It’s about pushing the limits of what one person can build in C with enough curiosity, patience, and stubbornness. Conclusion This TLS-in-TLS triple-handshake tunnel experiment has already taught me more than I expected about handshake flows, encrypted layers, and the behavior of ECH/SNI under custom proxy conditions. It’s far from perfect, but it’s progressing steadily. If my next tests with QUIC work out, this could evolve into a fast, lightweight, encrypted reverse proxy unlike anything that exists today. For now it remains experimental. It’s not officially standardized it’s a project currently built within the R&D lab.