WireGuard, IPsec/IKEv2, OpenVPN — chaque protocole repose sur des primitives cryptographiques et des mécanismes de négociation différents avec des implications concrètes sur la sécurité, les performances, la conformité et la surface d'attaque.
| Protocole | Statut | Chiffrement symétrique | Échange de clés | Surface de code | Note |
|---|---|---|---|---|---|
| WireGuard | Recommandé | ChaCha20-Poly1305 |
Curve25519 |
~4 000 lignes | Modèle fixe — incompatible FIPS |
| IPsec / IKEv2 | Recommandé ANSSI | AES-256-GCM |
ECDH P-384 |
Noyau OS | PFS à activer, suites à verrouiller |
| OpenVPN | Acceptable | AES-256-GCM |
ECDHE |
~400 000 lignes | Espace utilisateur, TCP/443 utile |
| L2TP / IPsec | Legacy | AES-256 |
Variable | Variable | Double encapsulation inutile |
| PPTP | Déprécié | MPPE/RC4 |
MS-CHAPv2 |
— | Cassable — ne pas déployer |
WireGuard est intégré au noyau Linux depuis la version 5.6 (mars 2020) et disponible en espace utilisateur sur macOS, Windows, iOS et Android via des implémentations portées. Audité par Cure53 en 2020. Sa surface de code réduite (~4 000 lignes) est son argument technique principal : plus facile à auditer formellement, à vérifier par des outils de preuve, et à corriger rapidement en cas de vulnérabilité.
WireGuard utilise le Noise Protocol Framework (NoisePP_25519_ChaChaPoly_BLAKE2s) — un modèle entièrement fixe sans négociation d'algorithmes. Les primitives :
Curve25519 — échange de clés Diffie-Hellman sur courbe elliptique. Clés de 256 bits, résistant aux attaques par timing grâce à l'implémentation à temps constant.ChaCha20-Poly1305 — chiffrement AEAD (Authenticated Encryption with Associated Data). Chiffrement et authentification du message en une seule opération. Performant sur CPU sans accélération AES-NI.BLAKE2s — fonction de hachage. Dérivation de clés et hachage interne.SipHash-2-4 — hachage des tables de routage. Résistant aux attaques par collision délibérée.WireGuard implémente la PFS par conception. Chaque session génère une paire de clés éphémères (ephemeral Diffie-Hellman) distinctes des clés d'identité statiques. Les sessions sont renouvelées toutes les 3 minutes (180 secondes) ou après 2^64 octets transférés. La compromission d'une clé statique ne compromet pas les sessions passées.
La conformité FIPS 140-2/140-3 exige l'utilisation d'algorithmes validés par le NIST — dont AES obligatoirement. WireGuard utilise ChaCha20, non listé FIPS. Les organisations soumises à des exigences FIPS (secteur public américain, défense, certaines certifications sectorielles) ne peuvent pas utiliser WireGuard vanilla. Des variantes comme BoringTun ajoutent la compatibilité AES mais sortent de l'implémentation de référence auditée.
Chaque pair WireGuard est identifié par une clé publique et une adresse IP interne fixe. Cette association persistante permet d'identifier quel utilisateur était connecté à quel moment dans les journaux du serveur. Pour les déploiements où la minimisation des logs est un prérequis, des implémentations comme Headscale permettent d'assigner des adresses dynamiques.
WireGuard ne nécessite pas de fichier de configuration complexe. Une interface réseau, une clé privée, une liste de pairs avec leur clé publique et leurs adresses IP autorisées. La configuration complète d'un serveur tient en moins de 20 lignes.
IPsec (RFC 4301-4309) est une suite de protocoles — pas un protocole unique. IKEv2 (RFC 7296) gère la négociation et le renouvellement des Security Associations. ESP (Encapsulating Security Payload) assure le chiffrement et l'intégrité des données en mode tunnel. AH (Authentication Header) assure l'intégrité seul — rarement utilisé en pratique.
Une SA IPsec a une durée de vie limitée : en temps (secondes) et en volume (kilooctets). Deux SA par tunnel (une par direction). Le renouvellement est géré par IKEv2 via CREATE_CHILD_SA. Si le renouvellement échoue silencieusement, le tunnel expire sans alerte côté utilisateur — point de surveillance opérationnel critique.
| Phase | Chiffrement | Intégrité | DH |
|---|---|---|---|
| IKEv2 Phase 1 | AES-256-GCM | SHA-384 | Groupe 20 (ecp384) |
| IPsec Phase 2 | AES-256-GCM | AEAD intégré | Groupe 20 (PFS) |
| Minimum admissible | AES-128-GCM | SHA-256 | Groupe 14 (modp2048) |
Exclure explicitement les groupes DH 1, 2 et 5 (768/1024/1536 bits), les algorithmes 3DES et DES, et HMAC-MD5. En StrongSwan : ike=aes256gcm16-sha384-ecp384! — le ! final refuse toute suite non listée et empêche tout downgrade.
MOBIKE (RFC 4555) permet à un client IKEv2 de maintenir son tunnel lors d'un changement d'adresse IP — passage Wi-Fi / 4G, changement de réseau. À activer explicitement côté client et serveur. Indispensable pour les équipes mobiles utilisant IPsec sur smartphones.
OpenVPN fonctionne en espace utilisateur — overhead CPU plus élevé que WireGuard ou IPsec natif, mais portabilité maximale. Canal de contrôle TLS pour la négociation, canal de données séparé pour le trafic chiffré.
--cipher AES-256-GCM (AEAD — authentification intégrée, pas besoin de --auth séparé)--tls-version-min 1.3--ecdh-curve prime256v1 ou secp384r1--cipher BF-CBC (Blowfish, déprécié) et --auth SHA1 encore présents dans des configs héritéesOpenVPN sur TCP port 443 produit un trafic indistinguable de HTTPS pour un équipement d'inspection de surface (pare-feu applicatif, proxy qui n'inspecte pas le TLS). Utile dans les environnements hôteliers ou clients qui bloquent les ports UDP, et dans certains pays qui filtrent les protocoles VPN identifiables. C'est l'avantage distinctif d'OpenVPN que WireGuard et IPsec ne couvrent pas.
En 2024, le NIST a finalisé ses premiers standards de cryptographie post-quantique : ML-KEM (FIPS 203, anciennement Kyber) pour l'encapsulation de clés, ML-DSA (FIPS 204, anciennement Dilithium) pour les signatures. Ces algorithmes résistent à l'algorithme de Shor exécuté sur un ordinateur quantique suffisamment puissant — contrairement à ECDH et RSA.
Un adversaire bien doté peut capturer du trafic chiffré aujourd'hui pour le déchiffrer dans 10 ans lorsque les ordinateurs quantiques seront suffisamment puissants. Pour les données avec une durée de vie de confidentialité longue (secrets industriels, données de santé, données gouvernementales), ce vecteur est réel et actuel — même si l'ordinateur quantique capable de casser ECDH-256 n'existe pas encore.
Les implémentations hybrides combinent un échange de clés classique (ECDH) avec un mécanisme post-quantique (ML-KEM) — le secret dérivé dépend des deux, de sorte qu'un attaquant doit casser les deux simultanément. WireGuard dispose de patches expérimentaux (post-quantum WireGuard). Certaines implémentations IPsec modernes supportent ML-KEM dans les suites IKEv2. OpenVPN 2.7+ expérimente également le support hybride.
Pour la majorité des organisations en 2026, la migration post-quantique n'est pas encore une exigence opérationnelle immédiate — mais c'est un critère de sélection pertinent pour les déploiements à horizon 5+ ans. La page Audit couvre comment évaluer la roadmap post-quantique des fournisseurs.