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.