Worldlex Wiki En mars 2020, la version Linux du logiciel a atteint une version stable de production et a été intégrée au noyau Linux 5.6, puis rétroportée vers des noyaux Linux antérieurs dans certaines distributions Linux . Les composants du noyau Linux sont distribués sous licence GNU GPL v2 ; les autres implémentations sont distribuées sous licence GPLv2 ou d’autres licences libres/open source.
du framework Noise ProtocolIK . L' échange de clés , ou établissement de liaison, combine des valeurs Diffie-Hellman à long terme et éphémères à l'aide de Curve25519 . Chaque paire génère un ensemble de paires de clés publiques et privées à l'aide de Curve25519. Les clés publiques sont échangées, et chaque paire se voit attribuer une adresse IP (généralement conforme à la RFC 1918 ) à utiliser avec le tunnel WireGuard. Une fois les clés confirmées par les deux pairs, le protocole Noise est utilisé pour générer une clé de session ChaCha20 partagée pour le chiffrement symétrique authentifié avec Poly1305 . SipHash24 est utilisé pour les clés de hachage, tandis que les fonctions de hachage cryptographiques de BLAKE2 , une version plus rapide et plus compacte de SHA-3 , sont intégrées. Les fonctions de dérivation de clés sont gérées à l'aide de HKDF et de clés privées, publiques et pré-partagées encodées en Base64 . La preuve de WireGuard commence par modéliser son protocole d'authentification à deux messages basé sur le bruit (avec une clé pré-partagée optionnelle) à l'aide du calcul des jeux cryptographiques de CryptoVerif . Ce calcul abstrait ChaCha20 - Poly1305 , Curve25519 , HKDF , la chaîne de hachage et les primitives associées, sous les hypothèses standard IND-CPA /INT-CTXT et d'oracle aléatoire. À partir de ce modèle, les simulations automatisées de CryptoVerif montrent, sur un nombre illimité de sessions parallèles, que le protocole garantit l'authentification mutuelle, la confidentialité des clés de session IND-CCA , la confidentialité persistante et la sécurité post-compromission, même en cas de fuite ultérieure des clés à long terme et d'effacement de l'état. En mai 2019, des chercheurs de l'INRIA ont publié une preuve du protocole WireGuard vérifiée par machine, produite à l'aide de l' assistant de preuve de CryptoVerif .
Mode de clé symétrique pré-partagée optionnel
WireGuard prend en charge le mode de clé symétrique pré-partagée , qui offre une couche supplémentaire de chiffrement symétrique pour atténuer les risques liés aux progrès futurs de l'informatique quantique. Ceci permet de pallier le risque que le trafic soit stocké jusqu'à ce que les ordinateurs quantiques soient capables de casser Curve25519 , auquel cas il pourrait être déchiffré. Les clés pré-partagées sont « généralement problématiques en termes de gestion des clés et présentent un risque accru de vol », mais à court terme, si la clé symétrique est compromise, les clés Curve25519 offrent une protection largement suffisante.
Réseautage
WireGuard utilise uniquement UDP [ en raison des inconvénients potentiels du TCP sur TCP. Le tunnelage TCP sur une connexion basée sur TCP peut induire une perte importante de performances de transmission en raison du de fusion TCP .
Son port serveur par défaut est UDP 51820.
WireGuard prend entièrement en charge IPv6, à l'intérieur comme à l'extérieur du tunnel. Il ne prend en charge que la couche 3 pour IPv4 et IPv6 et peut encapsuler IPv4 dans IPv6 et vice versa.
En-tête MTU
La surcharge de WireGuard se décompose comme suit :
- En-tête IPv4 de 20 octets ou en-tête IPv6 de 40 octets
- En-tête UDP de 8 octets
- type 4 octets
- Index de clé de 4 octets
- nonce de 8 octets
- données chiffrées de n octets
- Étiquette d'authentification de 16 octets
Considérations opérationnelles de l'unité de traitement des métaux
En supposant que le réseau sous-jacent transportant les paquets WireGuard maintienne une MTU de 1 500 octets, la configuration de l’interface WireGuard avec une MTU de 1 420 octets pour tous les pairs impliqués est idéale pour un transport sur IPv6 + IPv4. Cependant, lors de l’utilisation exclusive du transport IPv4 traditionnel, une MTU plus élevée de 1 440 octets pour l’interface WireGuard est suffisante.
Du point de vue opérationnel et pour garantir l'uniformité de la configuration réseau, il serait avantageux de conserver la MTU par défaut de 1 420 octets pour l'ensemble des interfaces WireGuard. Cette approche assure la cohérence et facilite la transition vers l'activation d'IPv6 pour les homologues et interfaces WireGuard à l'avenir.
Toutefois, pour les clients mobiles présentant différents types de connectivité réseau et des MTU variables selon les connexions, une MTU de 1280 peut s'avérer avantageuse, permettant le transport IPv6 au sein du tunnel (car il s'agit de sa MTU minimale autorisée) et assurant le fonctionnement du tunnel WireGuard sur la plupart des types de connectivité. Les hôtes évitent généralement d'envoyer des paquets de taille supérieure à 1280 en raison de la fiabilité du PMTUD .
L'unité de transmission maximale (MTU) d'une interface WireGuard est déterminée par le protocole IP d'encapsulation (ou externe ), et non par la version IP utilisée dans le tunnel. Lorsque les paquets WireGuard transitent via IPv4, la surcharge de l'en-tête externe est de 60 octets (20 octets pour l'en-tête IPv4, 8 octets pour l'en-tête UDP et 32 octets pour l'en-tête WireGuard). Lorsqu'ils transitent via IPv6, cette surcharge passe à 80 octets. Cette distinction implique que même si un pair n'est accessible que via IPv4, d'autres pairs du même réseau maillé peuvent se connecter via IPv6 ou par le biais de mécanismes de traduction. La traduction augmente la taille de l'en-tête et impose la MTU minimale de 1 280 octets pour le chemin IPv6, ce qui oblige les développeurs à prendre en compte la surcharge de 80 octets liée à IPv6 lors de la définition d'une MTU d'interface cohérente.
Extensibilité
WireGuard est conçu pour être étendu par des programmes et des scripts tiers. Ceci a permis d'enrichir WireGuard de diverses fonctionnalités, notamment des interfaces de gestion plus conviviales (avec une configuration simplifiée des clés), la journalisation, les mises à jour dynamiques du pare-feu, l'attribution dynamique d'adresses IP et l'intégration LDAP . Il est pris en charge nativement et par plusieurs services VPN commerciaux tels que NordVPN , IPVanish , Mullvad et TunnelBear . AmneziaWG, un fork de WireGuard, ajoute des mécanismes d'obfuscation du trafic destinés à rendre le trafic WireGuard moins identifiable par les systèmes d'inspection approfondie des paquets .
L'exclusion de ces fonctionnalités complexes du code source minimal améliore sa stabilité et sa sécurité. Pour garantir la sécurité, WireGuard restreint les options d'implémentation des contrôles cryptographiques, limite les choix des processus d'échange de clés et associe les algorithmes à un petit sous-ensemble de primitives cryptographiques modernes . Si une faille est découverte dans l'une de ces primitives, une nouvelle version corrective peut être publiée.
Réception
Une analyse d' Ars Technica a conclu que WireGuard était facile à installer et à utiliser, employait des algorithmes de chiffrement robustes et possédait un code source minimal, réduisant ainsi la surface d'attaque. Cette analyse comprenait une citation de Linus Torvalds :
« Puis-je réaffirmer mon amour pour [WireGuard] et espérer qu'il soit bientôt intégré ? Le code n'est peut-être pas parfait, mais je l'ai parcouru rapidement et, comparé aux horreurs que sont OpenVPN et IPSec , c'est une œuvre d'art. »
Un rapport de 2024 concluait que WireGuard avait du potentiel en tant que solution légère et robuste pour la sécurité de l'Internet des objets .
WireGuard a reçu un financement de l' Open Technology Fund et des dons de Jump Trading , Mullvad , Tailscale , Fly.io et de la NLnet Foundation .
Le sénateur de l'Oregon, Ron Wyden, a recommandé au National Institute of Standards and Technology (NIST) d'évaluer WireGuard comme solution de remplacement pour les technologies existantes.
Disponibilité
Mises en œuvre
Les implémentations du protocole WireGuard comprennent :
- L'implémentation initiale de Donenfeld, écrite en C et Go.
- BoringTun de Cloudflare , une implémentation en espace utilisateur écrite en Rust .
- L'implémentation de Matt Dunwoodie pour OpenBSD, écrite en C.
- Implémentation wg(4) de Ryota Ozaki pour NetBSD, écrite en C.
- L'implémentation FreeBSD est écrite en C et partage la majeure partie du chemin de données avec l'implémentation OpenBSD.
- Implémentation native du noyau Windows nommée « wireguard-nt », depuis août 2021.
- Les modems-routeurs AVM Fritz!Box compatibles avec Fritz!OS version 7.39 et ultérieures. Permettent les connexions WireGuard de site à site à partir de la version 7.50.
- Implémentation en espace utilisateur du traitement de paquets vectoriels écrite en C.
Histoire
Des versions préliminaires du code source existent depuis le 30 juin 2016. Le logo est inspiré d'une gravure sur pierre du python mythologique que Jason Donenfeld a vue lors d'une visite dans un musée à Delphes .
Le 9 décembre 2019, David Miller – principal responsable de la maintenance de la pile réseau Linux – a accepté les correctifs WireGuard dans l’arbre de maintenance « net-next », en vue de leur inclusion dans un prochain noyau.
Le 28 janvier 2020, Linus Torvalds a fusionné l'arbre net-next de David Miller, et WireGuard est entré dans l'arbre du noyau Linux principal.
Le 20 mars 2020, les développeurs de Debian ont activé les options de compilation du module WireGuard dans la configuration du noyau pour la version Debian 11 (test).
Le 29 mars 2020, WireGuard a été intégré à la branche 5.6 de Linux. La version Windows du logiciel reste en version bêta. Cela a conduit les développeurs Android à ajouter la prise en charge native de WireGuard au niveau du noyau dans leur image de noyau générique le 30 mars 2020.
Le 22 avril 2020, Beniamino Galvani, développeur de NetworkManager, a intégré la prise en charge de l'interface graphique pour WireGuard dans GNOME .
Le 12 mai 2020, Matt Dunwoodie a proposé des correctifs pour la prise en charge native de WireGuard dans le noyau d'OpenBSD . Le 22 juin 2020, après le travail de Matt Dunwoodie et Jason A. Donenfeld, la prise en charge de WireGuard a été importée dans OpenBSD.
Le 23 novembre 2020, Jason A. Donenfeld a publié une mise à jour du package Windows améliorant l'installation, la stabilité, la prise en charge ARM et les fonctionnalités d'entreprise .
Le 29 novembre 2020, la prise en charge de WireGuard a été importée dans le noyau FreeBSD 13.
Le 19 janvier 2021, la prise en charge de WireGuard a été ajoutée en avant-première dans les versions de développement de pfSense Community Edition (CE) 2.5.0.
En mars 2021, la prise en charge de WireGuard en mode noyau a été supprimée de FreeBSD 13.0, alors encore en phase de test, car un nettoyage urgent du code de WireGuard dans FreeBSD n'a pas pu être mené à terme rapidement. Les versions pfSense Community Edition (CE) 2.5.0 et pfSense Plus 21.02, basées sur FreeBSD, ont également supprimé WireGuard au niveau du noyau.
En mai 2021, la prise en charge de WireGuard a été réintroduite dans les versions de développement de pfSense CE et pfSense Plus sous la forme d'un paquet expérimental développé par Christian McDonald, membre de la communauté pfSense. Ce paquet WireGuard pour pfSense intègre les travaux de développement en cours sur WireGuard en mode noyau menés par Jason A. Donenfeld et initialement financés par Netgate.
En juin 2021, les dépôts de paquets officiels pour pfSense CE 2.5.2 et pfSense Plus 21.05 incluaient le paquet WireGuard.
En 2023, WireGuard a reçu un soutien de plus de 209 000 € du Fonds souverain technologique allemand .
En juin 2025, IPFire a ajouté la prise en charge de WireGuard en utilisant l'implémentation du noyau Linux.
En janvier 2026, Iran International a rapporté que WireGuard était utilisé en Iran à la suite des manifestations iraniennes de 2026 , bien qu'avec un succès limité.