Our protocol, open source
WarrenGuard
The next-generation VPN protocol that blends into the web. Built on QUIC, designed obfuscation-first, released under the AGPL-3.0 license.
Why a protocol?
Classic VPN protocols encrypt, and that is fine. But they have an ugly flaw: they are recognizable. On a network, a WireGuard or OpenVPN connection has an identifiable signature from the very first packets. And what can be recognized can be blocked. I have no taste for digital captivity, whether it comes from hotels, airports, trains, cafes, surveillance-minded companies, or whole countries.
WarrenGuard turns the problem around. Instead of encrypting and then trying to hide, it is built from the ground up on QUIC, the protocol that already carries a huge share of the modern web. To an outside observer, a Warren connection looks like ordinary HTTP/3: the same traffic your browser produces when you watch a video.
Obfuscation is therefore the protocol itself: there is no stealth mode to switch on in the settings.
What it changes for you
- Where classic VPNs are blocked, Warren keeps going: your traffic shows nothing that sets it apart from everyday browsing.
- Modern encryption across the tunnel: TLS 1.3, the standard that already protects your bank and your email.
- Every exit server identifies itself with a cryptographic key your app verifies directly, with no certificate authority and no trusted third party.
Under the hood
These are the technical choices that determine WarrenGuard. They are detailed in the white paper.
- QUIC transport (RFC 9000): IP packets travel 1:1 in DATAGRAM frames (RFC 9221), unreliable and unordered, hence no head-of-line blocking. Reliable streams are used only for the handshake. BBR congestion control.
- TLS 1.3 only handshake, with Raw Public Keys (RFC 7250): a node identity is an Ed25519 key verified directly, with no certificate authority. No PKI to compromise.
- SNI-split on by default: the ClientHello is fragmented across two padded Initial packets, defeating passive SNI extraction on QUIC (an attack published in 2025). And no client certificate is requested: nothing to spot by active probing.
- Optional cover-domain mode: the node presents an ordinary X.509 certificate (ACME / Let's Encrypt) for a plausible domain; the Warren identity is proven inside the tunnel.
- Sealed multi-hop: HPKE sessions (RFC 9180, X25519 + ChaCha20-Poly1305) through a cryptographically blind relay. The relay carries traffic it cannot read; the exit sees the relay, not your IP. Built into the engine, rolling out across the network.
- DAITA available: defense against AI-guided traffic analysis, based on the maybenot framework (Karlstad University / Mullvad), negotiated per session.
- QUIC connection migration enabled on the relay hop (seamless Wi-Fi / cellular handover) but disabled on the exit: we do not hand out a timing-correlation primitive.
- The code is public: anyone can read, audit and build the engine.
The code is public
WarrenGuard is released under the AGPL-3.0 license. Wire formats are locked by shared test vectors (golden vectors): every implementation is validated against the same bytes.