WarrenGuard

Pourquoi un protocole ?

Les protocoles VPN classiques chiffrent, c'est très bien. Mais ils ont un vilain défaut : on les reconnaît. Sur un réseau, une connexion WireGuard ou OpenVPN a une signature identifiable dès les premiers paquets. Or ce qu'on peut reconnaître, on peut le bloquer. Et je n'aime pas la captivité numérique, que ce soit celle des hôtels, des aéroports, des trains, des cafés, des entreprises de contrôle, voire de pays entiers.

WarrenGuard prend le problème à l'envers. Au lieu de chiffrer puis d'essayer de se cacher, il est construit dès le départ sur QUIC, le protocole qui transporte déjà une énorme partie du web moderne. Pour un observateur extérieur, une connexion Warren ressemble à du HTTP/3 ordinaire : le même trafic que produit ton navigateur quand tu regardes une vidéo.

L'obfuscation, c'est donc le protocole lui-même : il n'y a aucun mode furtif à activer dans les réglages.

Ce que ça change pour toi

• Là où les VPN classiques sont bloqués, Warren continue de passer : ton trafic ne présente rien qui le distingue de la navigation de tous les jours.
• Un chiffrement moderne de bout en bout du tunnel : TLS 1.3, le standard qui protège déjà ta banque et ta messagerie.
• Chaque serveur de sortie s'identifie par une clé cryptographique que ton app vérifie directement, sans autorité de certification ni tiers de confiance.

Sous le capot

Voici les choix techniques qui déterminent WarrenGuard. Ils sont détaillés dans le Livre blanc.

• Transport QUIC : les paquets voyagent un pour un dans des trames DATAGRAM, et un paquet perdu ne retarde jamais les suivants. Les échanges fiables ne servent qu'à la poignée de main.
• Poignée de main TLS 1.3 uniquement : l'identité d'un serveur est sa clé Ed25519, que ton app vérifie directement. Aucune autorité de certification, donc aucune à compromettre.
• SNI-split actif par défaut : le ClientHello est coupé en deux paquets, ce qui empêche un observateur passif d'en extraire le nom de domaine. Et aucun certificat client n'est demandé : rien à repérer par sondage actif.
• Mode cover domain optionnel : le serveur présente un certificat ordinaire (type Let's Encrypt) pour un domaine plausible ; l'identité Warren se prouve à l'intérieur du tunnel.
• Multi-hop scellé : ton trafic est chiffré pour le serveur de sortie avant de traverser un relais qui ne peut pas le lire. La sortie voit le relais, jamais ton IP. Intégré au moteur, déployé progressivement sur le réseau.
• DAITA disponible : une défense qui brouille la forme du trafic pour tromper l'analyse par IA, négociée par session.
• Migration de connexion QUIC côté relais : tu passes du Wi-Fi à la 4G sans coupure. Désactivée côté sortie, pour ne pas offrir un moyen de corréler tes changements de réseau.
• Le code est public : n'importe qui peut lire, auditer et compiler le moteur.

Le code est public

WarrenGuard est publié sous licence AGPL-3.0. Des vecteurs de test partagés (les golden vectors) garantissent que chaque implémentation produit exactement les mêmes octets.

• warrenBrowse/warrenguard Le moteur du protocole : tunnel, obfuscation, multi-hop, DAITA.
• warrenBrowse/warren-quinn Notre fork de quinn (QUIC) : fragmentation du ClientHello, optimisations d'envoi.
• warrenBrowse/warren-vectors Les golden vectors : les octets de référence que chaque implémentation doit reproduire exactement.