LMI MAG 2 Mars 2020 - Magazine - Page 56
© Pixabay
FOCUS
WireGuard
fonctionne sur une machine. De plus, la connexion
entre pairs, qui peuvent agir à la fois comme clients et
serveurs, devient silencieuse lorsqu’il n’y a pas d’échange
de données. Le protocole WireGuard a été examiné par
plusieurs équipes de chercheurs en sécurité du secteur
privé et du monde universitaire et il a été officiellement
vérifié dans différents modèles informatiques.
La principale implémentation de WireGuard est destinée à Linux et se présente sous forme d’un module
de kernel. Le code est conçu pour être facilement vérifiable : Jason Donenfeld affirme qu’il peut être lu en
une après-midi. Comparé à OpenVPN qui comporte plus
de 100 000 lignes de code et dépend d’OpenSSL, autre
énorme base de code, le module de kernel de WireGuard
compte environ 4 000 lignes de code, code de cryptage
intégré inclus. Cela signifie qu’il a une plus petite surface d’attaque comparé aux autres projets VPN et que,
puisqu’il ne répond pas aux paquets non authentifiés,
il est beaucoup plus difficile à attaquer.
Avec seulement 4 000 lignes de code, Wireguard
a une plus petite surface d’attaque que les autres VPN.
Les bonnes performances du protocole
Sous Linux, WireGuard fonctionne exclusivement dans
l’espace du kernel. Ses performances sont donc bien
meilleures que celles d’OpenVPN, qui s’exécute dans
l’espace utilisateur et emploie un pilote d’interface de
réseau virtuel. De nombreux benchmarks de WireGuard,
dont certains sont présentés sur le site web du projet, montrent que les performances et les vitesses de
connexion du protocole sont jusqu’à quatre fois plus
élevées que celles d’OpenVPN et que, sur un même
hardware, ses vitesses sont supérieures à celles de
VPN basés sur IPsec. Cependant, les implémentations
de WireGuard pour Android, iOS, macOS, OpenBSD et
Windows sont écrites dans le langage de programmation Go, qui offre une gestion sécurisée de la mémoire.
À part quelques projets de firmware Android, supportés
par la communauté, qui ont intégré le module du noyau
WireGuard, les implémentations WireGuard non-Linux
fonctionnent dans l’espace utilisateur et ne bénéficient
pas des mêmes performances que l’implémentation du
kernel. Cela dit, dans la plupart des cas, elles parviennent
toujours à égaler ou à surpasser OpenVPN.
Un avis favorable de Linus Torvalds
Le module du kernel WireGuard est disponible dans les
référentiels de paquets de toutes les distributions Linux
majeures, et même de certaines distributions spécialisées. Cependant, depuis l’année dernière, Jason Donenfeld prépare une intégration directe au noyau Linux prin56 / Mars 2020
cipal. Ces améliorations ont pris du temps, car la fusion
nécessite des changements significatifs à la fois dans l’API
cryptographique du noyau Linux et dans la pile réseau.
Mais le développeur a reçu un avis favorable de Linus
Torvalds. « Je vois que Jason a fait la demande d’extraction pour que WireGuard soit inclus dans le noyau », avait
déclaré il y a un an le créateur de Linux sur la liste de diffusion du noyau Linux. « Je voudrais dire une fois encore
à quel point ce projet me tient à cœur et j’espère que la fusion aura lieu bientôt. Le code n’est peut-être pas parfait,
mais je l’ai parcouru, et comparé aux horreurs que sont
OpenVPN et IPSec, c’est une œuvre d’art », avait-il ajouté.
Les projets de Jason Donenfeld impliquaient la fusion
d’une API cryptographique plus simple au noyau Linux
qu’il a appelé Zinc. Selon lui, comparée à l’API cryptographique existante du noyau, trop complexe pour la
plupart des cas d’usage, Zinc devait permettre aux développeurs de réaliser plus facilement des opérations
cryptographiques dans leurs applications. Dans une
présentation sur Zinc, il qualifie l’API de cryptage de
Linux d’« API d’entreprise complètement dingue, très
sujette à l’échec et très difficile à utiliser ». Mais ses tentatives de fusion d’une seconde API de crypto ont reçu
des réponses mitigées de la part d’autres développeurs
du kernel. Ces derniers se sont dits préoccupés par
la duplication des fonctionnalités et se sont demandé
si elle était nécessaire, plutôt que de résoudre les problèmes de l’API existante.