La surface d'attaque comme métrique de comparaison

Comparer des protocoles VPN par les benchmarks de performance seule est insuffisant. La métrique la plus importante pour la sécurité est la surface d'attaque : la quantité de code qui doit fonctionner correctement pour que la sécurité soit garantie. Un protocole avec 70 000 lignes de code et un protocole avec 4 000 lignes ne présentent pas le même risque — même si leurs performances sont comparables.

Cette asymétrie est le principal argument de WireGuard face à OpenVPN. Elle explique aussi pourquoi IPsec, malgré sa maturité et son ubiquité, reste difficile à déployer correctement — la complexité de sa spécification laisse de la place aux erreurs d'implémentation.

WireGuard — minimalisme cryptographique

Architecture

WireGuard est un protocole de tunnel réseau implémenté dans le kernel Linux (depuis 5.6), avec des ports pour Windows, macOS, Android et iOS. Son design repose sur un ensemble d'algorithmes cryptographiques fixe et moderne : Curve25519 pour l'échange de clés Diffie-Hellman, ChaCha20 pour le chiffrement symétrique, Poly1305 pour l'authentification des messages (AEAD), BLAKE2s pour le hachage, et SipHash24 pour les tables de hachage. Il n'y a pas de négociation de suites cryptographiques — les algorithmes sont câblés dans le protocole.

Cette absence de négociation est un choix délibéré qui élimine toute une classe d'attaques par downgrade — les attaques qui forcent deux parties à utiliser une suite cryptographique faible en interférant avec la négociation. C'est le même principe que le choix d'algorithmes fixes dans Signal Protocol.

Stack cryptographique WireGuard
# Handshake initial (basé sur Noise Protocol Framework)
Initiator → Responder:
  ephemeral_pub_key   # Curve25519 clé publique éphémère
  encrypted_static    # clé statique chiffrée via ChaCha20-Poly1305
  encrypted_timestamp # anti-replay

Responder → Initiator:
  ephemeral_pub_key
  encrypted_empty     # confirmation

# Transport : ChaCha20-Poly1305, nonce 64-bit, clés dérivées via HKDF
# Key rotation automatique toutes les 3 min ou 2^60 paquets

# Taille totale du codebase kernel : ~4000 lignes

Limitation : persistance des IPs dans le kernel

WireGuard identifie les pairs par clé publique et maintient une table de routage dans le kernel qui associe chaque pair à sa dernière IP source. Cette table est consultable via /proc/net/dev et les outils de diagnostic réseau standard. Pour un VPN auto-hébergé avec des pairs connus, c'est acceptable. Pour un service commercial qui veut implémenter une politique no-logs, c'est un problème — les IPs des clients sont visibles dans le kernel tant que la session est active.

Les implémentations commerciales sérieuses contournent ce problème en régénérant les paires de clés et les IPs assignées à intervalles réguliers (toutes les 10 minutes pour ProtonVPN, par exemple), et en routant le trafic à travers des namespaces réseau supplémentaires qui isolent les IPs clients. Ce n'est plus du WireGuard standard — c'est WireGuard avec une couche d'anonymisation par-dessus. La comparaison détaillée WireGuard vs OpenVPN développe ce point.

OpenVPN — flexibilité et auditabilité

Architecture

OpenVPN est un daemon en espace utilisateur qui crée des interfaces TUN ou TAP et encapsule le trafic réseau dans des paquets TLS/SSL. Il utilise la bibliothèque OpenSSL (ou mbedTLS dans les versions récentes) pour le chiffrement, ce qui donne accès à l'ensemble des suites cryptographiques supportées par OpenSSL. Cette flexibilité est une arme à double tranchant : elle permet des configurations très solides, mais aussi des configurations faibles si le déploiement n'est pas soigneux.

La configuration recommandée en 2026 : tls-version-min 1.3, cipher AES-256-GCM, auth SHA512, certificats ECDSA P-384 ou RSA 4096. Les configurations par défaut d'installations anciennes peuvent inclure des suites dépréciées — TLS 1.0, RC4, DES — qu'il faut explicitement désactiver.

Configuration OpenVPN sécurisée — paramètres clés
# Serveur
tls-version-min 1.3
cipher          AES-256-GCM
auth            SHA512
tls-auth        ta.key 0        # protection DoS/replay
dh              dh4096.pem     # ou ECDH
tls-cipher      TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384

# Réduction surface d'attaque
user            nobody
group           nogroup
chroot          /etc/openvpn/jail
persist-key
persist-tun

Avantages pour le contournement de filtres

OpenVPN peut tourner sur le port 443 en TCP, ce qui le rend indiscernable du trafic HTTPS standard pour un filtre réseau basique. Des bibliothèques d'obfuscation comme obfs4 ou Shadowsocks peuvent être superposées pour contourner l'inspection profonde de paquets (DPI). WireGuard sur UDP est plus facile à détecter et à bloquer pour un opérateur réseau déterminé.

IPsec / IKEv2 — le standard enterprise

IPsec n'est pas un protocole unique — c'est un framework de sécurité réseau défini par une série de RFC (4301, 4302, 4303, 4306). Il comprend AH (Authentication Header), ESP (Encapsulating Security Payload), et IKE (Internet Key Exchange) pour la négociation des associations de sécurité. IKEv2 est la version actuelle du protocole d'échange de clés.

La complexité de la spécification IPsec est à la fois sa force et sa faiblesse. Sa force : il est intégré nativement dans tous les systèmes d'exploitation modernes sans logiciel tiers. Sa faiblesse : l'étendue de la spécification laisse de la latitude aux implémentations, et plusieurs CVE historiques ont touché des implémentations spécifiques (Cisco, strongSwan, Openswan). La robustesse d'une installation IPsec dépend beaucoup de la qualité de l'implémentation utilisée.

IKEv2 est particulièrement adapté aux connexions mobiles grâce au protocole MOBIKE (RFC 4555) qui permet de maintenir une session VPN à travers les changements d'adresse IP — utile quand un smartphone bascule entre Wi-Fi et 4G.

Schéma comparatif des handshakes

WIREGUARD OPENVPN (TLS 1.3) IKEV2 Initiator Responder Handshake Init ephem + static enc Handshake Resp Transport chiffré ChaCha20-Poly1305 2 messages — 1 RTT ~4000 lignes kernel Client Serveur ClientHello ServerHello + Cert Finished Finished Transport chiffré AES-256-GCM (TLS 1.3) 4 messages — 2 RTT min Suite crypto négociée — ~70k lignes Initiateur Répondeur IKE_SA_INIT IKE_SA_INIT resp IKE_AUTH IKE_AUTH resp ESP tunnel chiffré AES-256-GCM + HMAC 4 messages — 2 RTT Natif OS — MOBIKE (RFC 4555) RTT = Round-Trip Time — chaque aller-retour ajoute de la latence au handshake initial

Choix pratique selon le cas d'usage

Pour un déploiement sur un VPS Linux auto-hébergé : WireGuard est le choix par défaut en 2026 — simple à configurer, rapide, surface d'attaque minimale. Pour un déploiement qui doit contourner des filtres réseau ou des systèmes DPI : OpenVPN sur TCP/443 avec obfuscation. Pour une intégration dans un environnement enterprise avec des équipements réseau existants (Cisco, Juniper) : IPsec/IKEv2. Pour un service commercial qui doit supporter le changement de réseau mobile sans déconnexion : IKEv2 avec MOBIKE.

Ces choix ne sont pas mutuellement exclusifs — les clients VPN commerciaux modernes supportent généralement WireGuard, OpenVPN et IKEv2, et basculent automatiquement selon le contexte réseau. La comparaison détaillée WireGuard vs OpenVPN explore les différences de performance et de sécurité en profondeur.