Ce que le chiffrement fait — et ne fait pas
Le chiffrement d'un tunnel VPN protège trois propriétés distinctes du canal de communication. La confidentialité : un observateur réseau voit des octets chiffrés, pas leur contenu. L'intégrité : toute modification des données en transit est détectable. L'authenticité : la vérification que le pair distant est bien celui qu'il prétend être.
Ce que le chiffrement ne protège pas : une clé compromise au niveau du système d'exploitation, un certificat frauduleux accepté par le terminal suite à une erreur de configuration PKI, ou un serveur VPN compromis à un niveau inférieur au daemon VPN (firmware, hyperviseur). Ces vecteurs sont orthogonaux au protocole choisi — ils relèvent de la sécurité de l'infrastructure, pas du protocole.
On distingue le protocole de tunnel (WireGuard, IPsec, OpenVPN) qui gère l'encapsulation, l'authentification du canal et le renouvellement des clés, des algorithmes cryptographiques (AES-256-GCM, ChaCha20-Poly1305, Curve25519) qui assurent le chiffrement effectif. Un protocole fort avec des algorithmes dépréciés reste vulnérable — et inversement.
Tableau comparatif
| Protocole | Statut | Performances | Contexte adapté | Contraintes principales |
|---|---|---|---|---|
| WireGuard | Audité / noyau | Excellent — opère au niveau noyau Linux | Nouveaux déploiements Linux, mobile, usage général | Incompatible FIPS (pas d'AES natif) ; IP statique par pair en vanilla |
| IPsec / IKEv2 | Mature / normalisé | Très bon — implémentations noyau disponibles | Entreprise, conformité ANSSI, équipements existants, FIPS | Configuration complexe ; nombreux paramètres laissés à l'intégrateur |
| OpenVPN | Mature / open source | Correct — espace utilisateur, overhead TLS | Traversée NAT/firewall strict, environnements hétérogènes | Moins performant que WireGuard ; codebase volumineuse (~400 000 lignes) |
| L2TP/IPsec | Legacy | Moyen — double encapsulation | Compatibilité avec équipements anciens uniquement | Double encapsulation inutile ; préférer IKEv2 seul sans L2TP |
| PPTP | Déprécié | Rapide (mais sans valeur) | Aucun — à proscrire en production | MS-CHAPv2 cassable ; chiffrement MPPE insuffisant. Ne jamais déployer. |
WireGuard : ce qu'il change réellement
WireGuard est soumis à review publique en 2017, intégré au noyau Linux 5.6 en mars 2020 et audité par Cure53 la même année. Sa conception repose sur un principe d'engineering inhabituel dans la sécurité réseau : réduire la surface de code à l'essentiel. Environ 4 000 lignes de code contre 400 000 pour OpenVPN — une différence qui n'est pas cosmétique. Une surface de code plus petite est plus facile à auditer formellement, à valider par des outils de preuve, et à corriger rapidement en cas de vulnérabilité.
Son modèle cryptographique est entièrement fixe, basé sur le Noise Protocol Framework : Curve25519 pour l'échange de clés (ECDH), ChaCha20-Poly1305 pour le chiffrement symétrique (AEAD), BLAKE2s pour le hachage, SipHash-2-4 pour les tables de routage. L'absence totale de négociation d'algorithmes est à la fois sa force et sa contrainte.
Force : pas de downgrade attack
Les protocoles qui négocient leurs algorithmes (IPsec, TLS, OpenVPN) sont exposés aux attaques de downgrade — forcer la négociation vers des algorithmes plus faibles. WireGuard élimine ce vecteur par conception : il n'y a rien à négocier. Les deux pairs utilisent les mêmes algorithmes ou la connexion échoue.
Contrainte FIPS
La conformité FIPS 140-2/140-3 (Federal Information Processing Standards) exige l'utilisation d'algorithmes validés par le NIST — dont AES obligatoirement pour le chiffrement symétrique. WireGuard utilise ChaCha20, qui n'est pas dans la liste FIPS. Pour les organisations soumises à des exigences FIPS (secteur public américain, défense, certaines certifications sectorielles), WireGuard vanilla n'est pas utilisable. Des variantes comme BoringTun/boringtun de Cloudflare ou des implémentations custom ajoutent la compatibilité AES, mais sortent du WireGuard "vanilla" audité.
IP statiques et implications pour la vie privée
Dans l'architecture WireGuard standard, chaque pair est identifié par sa clé publique et une IP interne fixe. Cette association est persistante : une entrée dans les logs du serveur VPN permet d'identifier quel utilisateur était connecté à quel moment. Dans un VPN d'entreprise où les logs sont sous contrôle de l'organisation, c'est un comportement attendu. Dans un VPN managé par un tiers avec une politique no-logs, cela mérite attention — des implémentations comme WARP de Cloudflare ou Mullvad utilisent des adresses IP dynamiques pour contourner cette limitation.
IPsec / IKEv2 : la recommandation des autorités
L'ANSSI recommande IPsec avec IKEv2 dans son guide sur l'accès distant sécurisé (DAT-NT-003). IPsec est une suite de protocoles (RFC 4301-4309), pas un protocole unique. IKEv2 (RFC 7296) assure la négociation et le renouvellement des Security Associations. ESP (Encapsulating Security Payload) assure le chiffrement et l'intégrité des données. AH (Authentication Header) n'assure que l'intégrité — rarement utilisé seul en entreprise.
Security Associations et renouvellement
Une SA IPsec a une durée de vie limitée, exprimée en temps (secondes) ou en volume de données (kilo-octets). Les deux SA d'un tunnel (une par direction) doivent être renouvelées avant expiration pour maintenir la connexion. Le renouvellement est géré par IKEv2 via le mécanisme CREATE_CHILD_SA. Si le renouvellement échoue silencieusement — bug, timeout réseau — le tunnel expire sans alerte, ce qui est un point de surveillance opérationnel à monitorer explicitement.
Perfect Forward Secrecy : activer explicitement
La PFS garantit que la compromission d'une clé à long terme ne compromet pas les clés de session passées. Elle est implémentée via un nouvel échange Diffie-Hellman à chaque renouvellement de SA. Dans beaucoup de déploiements par défaut, la PFS est désactivée pour des raisons de performance — vérifier et activer explicitement dans la configuration IKEv2. Le paramètre s'appelle pfs dans StrongSwan, pfsgroup dans d'autres implémentations.
MOBIKE : continuité sur changement de réseau
MOBIKE (IKEv2 Mobility and Multihoming Protocol, RFC 4555) permet à un client IKEv2 de maintenir son tunnel VPN lors d'un changement d'adresse IP — passage du Wi-Fi au réseau mobile, changement de réseau. Sans MOBIKE, un changement d'adresse IP force une renégociation complète du tunnel. MOBIKE est particulièrement pertinent pour les postes nomades et les mobiles.
IPsec propose une liste de suites cryptographiques pour maintenir la compatibilité avec des équipements anciens. Une proposition IKE qui inclut 3DES, MD5 ou les groupes DH 1 et 2 (768/1024 bits) sera utilisée si le pair l'accepte. Ces algorithmes sont cassables avec des ressources accessibles. La configuration doit explicitement exclure ces suites et ne lister que les suites recommandées (ANSSI : AES-256, SHA-256 minimum, groupe DH 14 minimum / 2048 bits).
OpenVPN : polyvalence et contreparties
OpenVPN (lancé en 2001, version 2.x toujours maintenue activement) fonctionne entièrement en espace utilisateur — ce qui le rend plus portable que WireGuard et IPsec, mais moins performant. Il utilise TLS pour le canal de contrôle (négociation, authentification) et un canal de données séparé pour le trafic chiffré.
Configuration recommandée en 2026 : canal de données AES-256-GCM (AEAD, évite le besoin d'un HMAC séparé), canal de contrôle TLS 1.3 avec ECDHE pour l'échange de clés. Éviter --cipher BF-CBC (Blowfish, déprécié) et --auth SHA1 (SHA-1, déprécié) qui apparaissent encore dans des configurations héritées.
Traversée de NAT et pare-feu restrictifs
L'avantage distinctif d'OpenVPN est sa capacité à fonctionner sur TCP 443. Pour un équipement d'inspection de surface (pare-feu applicatif, proxy d'entreprise qui n'inspecte pas le TLS), ce trafic est indistinguable de HTTPS standard. C'est le cas d'usage où OpenVPN reste pertinent en 2026, même face à WireGuard : les environnements où les ports UDP sont bloqués, ou où le trafic VPN est activement détecté et bloqué.
Obfuscation et détection
Dans les environnements où le VPN est activement bloqué (certains réseaux d'entreprise, Chine, Iran), des couches d'obfuscation peuvent être ajoutées sur OpenVPN : obfs4 (développé pour le projet Tor), Shadowsocks, ou des tunnels WebSocket. Ces techniques masquent les signatures protocolaires qui permettraient à un DPI (Deep Packet Inspection) de détecter un tunnel VPN. Elles sortent du périmètre d'un VPN d'entreprise standard, mais sont pertinentes pour les déploiements dans des juridictions contraintes.
Les algorithmes cryptographiques : ce qu'il faut vérifier
Chiffrement symétrique
AES-256-GCM est la référence pour les tunnels IPsec et OpenVPN. Le mode GCM (Galois/Counter Mode) est un mode AEAD — il assure simultanément le chiffrement et l'authentification du message, sans besoin d'un HMAC séparé. AES-128-GCM est acceptable (la différence de sécurité entre 128 et 256 bits est théorique dans le contexte actuel). Les modes CBC sans authentification séparée sont à proscrire dans les nouveaux déploiements — ils sont vulnérables aux attaques par oracle de rembourrage.
Échange de clés et groupes Diffie-Hellman
ECDH sur P-256 (secp256r1) ou P-384 est le standard actuel pour les échanges de clés dans IKEv2 et OpenVPN. Les groupes DH modulaires (MODP) de 1024 bits sont cassables — leur présence dans une configuration IKE active est un risque documenté, pas théorique. Les groupes MODP 2048 bits (groupe 14) sont le minimum admissible selon l'ANSSI. Préférer les groupes ECDH (groupes 19, 20, 21 dans IKEv2) pour de meilleures performances à sécurité équivalente.
Résistance post-quantique : où en sommes-nous
En 2024, le NIST a finalisé ses premiers standards de cryptographie post-quantique : ML-KEM (anciennement Kyber, FIPS 203) pour l'encapsulation de clés, et ML-DSA (anciennement Dilithium, FIPS 204) pour les signatures. Ces algorithmes résistent aux attaques d'un ordinateur quantique suffisamment puissant, contrairement à ECDH qui serait cassé par l'algorithme de Shor.
Pour la plupart des organisations en 2026, la migration post-quantique n'est pas encore une exigence opérationnelle immédiate — les ordinateurs quantiques capables de casser ECDH-256 ne sont pas opérationnels. Mais pour les données à durée de vie longue (secrets d'État, propriété industrielle, données de santé), le harvest now, decrypt later est une menace réelle : un adversaire peut capturer du trafic aujourd'hui pour le déchiffrer dans 10 ans. Les déploiements à horizon 5+ ans devraient vérifier si leur solution supporte une migration hybride (classique + post-quantique simultanément), ce que proposent déjà certaines implémentations de WireGuard et IPsec.
La page sur le déploiement couvre comment ces choix de protocoles s'inscrivent dans une infrastructure concrète, notamment la gestion des certificats et des suites IKE. La page sur la conformité détaille les exigences algorithmiques des référentiels NIS2, ISO 27001 et ANSSI.