Pourquoi ne pas utiliser WireGuard

Dernièrement, WireGuard attire beaucoup d'attention, c'est en fait la nouvelle « étoile » parmi VPN. Mais est-il vraiment aussi bon qu'il en a l'air ? Je voudrais discuter de certaines observations et examiner l'implémentation de WireGuard pour expliquer pourquoi il ne constitue pas une solution qui remplace IPsec ou OpenVPN.

Dans cet article, je souhaite démystifier certains mythes [autour de WireGuard]. Oui, cela va demander beaucoup de lecture, donc si vous n'avez pas encore préparé votre tasse de thé ou de café, il est temps de le faire. Je voudrais également remercier Peter pour la révision de mes pensées chaotiques.

Je n'ai pas l'intention de discréditer les développeurs de WireGuard, de dévaluer leurs efforts ou leurs idées. Leur produit fonctionne, mais personnellement, je pense qu'il est présenté d'une manière qui ne reflète pas vraiment sa véritable nature — présenté comme un remplacement d'IPsec et d'OpenVPN, ce qui n'existe tout simplement pas à l'heure actuelle.

À titre de remarque, je tiens à ajouter que la responsabilité de ce positionnement de WireGuard incombe aux médias qui en ont parlé, et non au projet lui-même ou à ses créateurs.

Récemment, il n'y a pas eu beaucoup de bonnes nouvelles concernant le noyau Linux. En effet, nous avons entendu parler de vulnérabilités monstres des processeurs qui ont été atténuées par des méthodes logicielles, et Linus Torvalds en a parlé de manière trop rude et ennuyeuse, dans le langage utilitaire des développeurs. Le planificateur ou la pile réseau de niveau zéro — ce ne sont pas non plus des sujets très compréhensibles pour les magazines de tendance. Et puis arrive WireGuard.

Sur le papier, tout cela sonne bien : une nouvelle technologie qui captive l'imagination.

Mais examinons-la de plus près.

Documentation technique de WireGuard

Cet article est basé sur la documentation officielle de WireGuard, écrite par Jason Donenfeld. Là, il explique le concept, l'objectif et la mise en œuvre technique de [WireGuard] dans le noyau Linux.

La première phrase dit :

WireGuard […] vise à remplacer à la fois IPsec dans la plupart des cas d'utilisation, ainsi que d'autres solutions populaires basées sur l'espace utilisateur et/ou TLS, telles qu'OpenVPN, tout en étant un [outil] plus sécurisé, performant et simple à utiliser.

Bien sûr, le principal atout de toutes les nouvelles technologies est leur simplicité [par rapport à leurs prédécesseurs]. Mais un VPN doit également être efficace et sécurisé..

Et après ?

Si vous dites que vous n'avez pas besoin de cela [de VPN], alors vous pouvez arrêter votre lecture ici. Cependant, je noterai que de telles tâches sont assignées à toute autre technologie de tunneling.

Le plus intéressant dans la citation ci-dessus se trouve dans les mots «dans la plupart des cas», qui, bien sûr, ont été ignorés par la presse. Et nous y sommes, coincés dans le chaos créé par cette négligence — dans cet article.

WireGuard remplacera-t-il ma connexion VPN [IPsec] entre les sites ?

Non. Il n'y a tout simplement aucune chance que de grands fournisseurs comme Cisco, Juniper et d'autres adoptent WireGuard pour leurs produits. Ils ne «montent pas dans des trains en marche» sans une grande nécessité. Plus tard, je discuterai de certaines raisons pour lesquelles ils ne pourront probablement pas intégrer WireGuard dans leurs produits, même s'ils le souhaitaient.

WireGuard transportera-t-il mon RoadWarrior de mon ordinateur portable vers le centre de données ?

Non. Actuellement, WireGuard ne dispose pas d'un grand nombre de fonctionnalités importantes pour pouvoir effectuer une telle tâche. Par exemple, il ne peut pas utiliser des adresses IP dynamiques côté serveur du tunnel, ce qui compromet totalement un tel scénario d'utilisation du produit.

IPFire est souvent utilisé pour des canaux Internet peu coûteux, comme pour une connexion DSL ou par câble. Cela a du sens pour les petites ou moyennes entreprises qui n'ont pas besoin de fibre optique rapide. [Remarque du traducteur : il ne faut pas oublier qu’en matière de communication, la Russie et certains pays de la CEI ont une avance considérable sur l’Europe et les États-Unis, car nous avons commencé à construire nos réseaux beaucoup plus tard et, avec l'arrivée de l'Ethernet et des réseaux à fibre optique comme norme, il a été plus facile de se réajuster. Dans des pays comme ceux de l'UE ou des États-Unis, l'accès haut débit xDSL à des vitesses de 3-5 Mbit/s reste la norme généralisée, tandis que la connexion à la fibre optique coûte des sommes incroyables par rapport à nos standards. C'est pourquoi l'auteur de l'article parle de connexion DSL ou par câble, comme étant la norme, et non une antiquité.] Cependant, les connexions DSL, par câble, LTE (et d'autres méthodes d'accès sans fil) ont des adresses IP dynamiques. Bien sûr, elles ne changent pas très souvent, mais elles changent tout de même.

Il existe un sous-projet appelé «wg-dynamic», qui ajoute une démonstration de l'espace utilisateur pour surmonter ce défaut. Un problème majeur du scénario utilisateur décrit ci-dessus est l'aggravation de la situation par l'adressage dynamique IPv6.

Du point de vue du distributeur, tout cela ne semble pas très prometteur. Un des objectifs de développement était de maintenir la simplicité et la clarté du protocole.

Malheureusement, tout cela est devenu trop simple et primitif, si bien que nous devons utiliser des logiciels supplémentaires pour que l'ensemble de cette construction soit viable dans des conditions d'exploitation réelles.

Est-ce que WireGuard est si simple à utiliser ?

Pas encore. Je ne dis pas que WireGuard ne sera jamais une bonne alternative pour établir un tunnel entre deux points, mais pour l'instant, il n'est qu'une version alpha du produit qu'il devrait devenir.

Mais que fait-il réellement ? Est-ce que IPsec est vraiment si difficile à exploiter ?

Évidemment que non. Le fournisseur de IPsec a pris ce point en compte et fournit son produit avec une interface, par exemple avec IPFire.

Pour configurer un tunnel VPN via IPsec, vous aurez besoin de cinq ensembles de données à entrer dans la configuration : votre propre adresse IP publique, l'adresse IP publique de la partie receveuse, les sous-réseaux que vous souhaitez rendre accessibles via cette connexion VPN et une clé pré-partagée. Ainsi, le VPN peut être configuré en quelques minutes et est compatible avec n'importe quel fournisseur.

Malheureusement, il y a quelques exceptions dans cette histoire. Quiconque a essayé d'établir un tunnel VPN via IPsec vers une machine sous OpenBSD sait de quoi je parle. Il existe d'autres exemples douloureux, mais en réalité, il y a beaucoup plus de pratiques positives concernant l'utilisation de IPsec.

Sur la complexité du protocole

Le consommateur final ne devrait pas s'inquiéter de la complexité du protocole.

Si nous vivions dans un monde où cela préoccupait réellement l'utilisateur, nous nous serions déjà débarrassés de SIP, H.323, FTP et d'autres protocoles, créés il y a plus de dix ans, qui ont du mal à fonctionner avec le NAT.

Il y a des raisons pour lesquelles IPsec est plus complexe que WireGuard : il fait beaucoup plus de choses. Par exemple, l'authentification des utilisateurs avec un identifiant/mot de passe ou une carte SIM avec EAP. Il offre la possibilité élargie d'ajouter de nouveaux primitifs cryptographiques.

WireGuard n'en dispose pas.

Et cela signifie que WireGuard finira par échouer à un moment donné, car l'un des primitives cryptographiques s'affaiblira ou sera complètement compromis. L'auteur de la documentation technique en parle ainsi :

Il convient de noter que WireGuard est cryptographiquement prétentieux. Il lui manque délibérément la flexibilité des chiffrements et des protocoles. Si des vulnérabilités majeures sont découvertes dans les primitives sous-jacentes, il sera nécessaire de mettre à jour tous les points de terminaison. Comme le montre le flux continu de vulnérabilités SSL/TLS, la flexibilité du chiffrement a considérablement augmenté.

La dernière phrase est absolument correcte.

Atteindre un consensus sur le chiffrement à utiliser rend les protocoles comme IKE et TLS plus de compliqués. Trop compliqués ? Oui, les vulnérabilités dans TLS/SSL se produisent assez souvent, et il n'y a pas d'alternatives.

Concernant l'ignorance des problèmes réels

Imaginez que vous avez un serveur VPN avec 200 clients actifs, dispersés dans le monde entier. C'est un scénario d'utilisation plutôt standard. Si vous devez changer de chiffrement, vous devez déployer la mise à jour sur toutes les copies de WireGuard sur ces ordinateurs portables, smartphones, etc. Simultanément au déploiement. C'est littéralement impossible. Les administrateurs qui essaieront de le faire auront besoin de mois pour déployer les configurations nécessaires, et les entreprises moyennes auront littéralement besoin d'années pour mener à bien un tel projet.

IPsec et OpenVPN offrent une fonctionnalité de négociation de chiffrements. Ainsi, pendant un certain temps, après que vous avez activé le nouveau chiffrement, l'ancien continuera à fonctionner. Cela permet aux clients actuels de se mettre à jour vers la nouvelle version. Une fois la mise à jour déployée, vous désactivez simplement le chiffrement vulnérable. Et voilà ! C'est fait ! Vous êtes incroyable ! Et les clients ne s'en apercevront même pas.

C'est en fait un cas très courant pour les grands déploiements, et même OpenVPN rencontre certaines difficultés à cet égard. La compatibilité ascendante est importante, et même si vous utilisez un chiffrement plus faible, cela ne conduit pas à la fermeture de l'entreprise pour beaucoup. Parce que cela provoquerait un paralysie des opérations pour des centaines de clients en raison de leur incapacité à accomplir leur travail.

L'équipe de WireGuard a rendu son protocole plus simple, mais complètement inutilisable pour les personnes qui n'ont pas un contrôle constant sur les deux pairs de leur tunnel. D'après mon expérience, c'est exactement ce scénario qui est le plus courant.

Cryptographie !

Mais quel est ce nouveau chiffrement intéressant utilisé par WireGuard ?

WireGuard utilise Curve25519 pour l'échange de clés, ChaCha20 pour le chiffrement et Poly1305 pour l'authentification des données. Il fonctionne également avec SipHash pour les clés de hachage et BLAKE2 pour le hachage.

ChaCha20-Poly1305 est standardisé pour IPsec et OpenVPN (via TLS).

Il est évident que le développement de Daniel Bernstein est très utilisé. BLAKE2 est le successeur de BLAKE, finaliste de SHA-3, qui n'a pas gagné à cause de sa similitude avec SHA-2. Si SHA-2 était compromis, il y aurait de fortes chances que BLAKE le soit également.

IPsec et OpenVPN n'ont pas besoin de SipHash en raison de leur conception. Ainsi, la seule chose qui ne peut actuellement pas être utilisée avec eux est BLAKE2, et cela uniquement jusqu'à ce qu'il soit standardisé. Ce n'est pas un grand inconvénient, car les VPN utilisent HMAC pour garantir l'intégrité, qui est considérée comme une solution robuste même couplée avec MD5.

J'en suis donc venu à la conclusion que pratiquement tous les VPN utilisent le même ensemble d'outils cryptographiques. Par conséquent, WireGuard n'est pas plus ou moins sécurisé que d'autres produits contemporains en ce qui concerne le chiffrement ou l'intégrité des données transmises.

Mais ce n'est même pas le plus important à noter selon la documentation officielle du projet. En effet, l'essentiel est la vitesse.

WireGuard est-il plus rapide que d'autres solutions VPN ?

En résumé : non, pas plus rapide.

ChaCha20 est un chiffreur de flux qui est plus facile à intégrer dans un logiciel. Il chiffre un bit à la fois. Les protocoles par blocs, comme AES, chiffrent des blocs de 128 bits à la fois. Pour une prise en charge matérielle, il faudra beaucoup plus de transistors, donc des processeurs plus gros sont équipés de l'AES-NI - une extension du jeu d'instructions qui accomplit certaines tâches du processus de chiffrement pour son accélération.

On s'attendait à ce qu'AES-NI ne fasse jamais son apparition dans les smartphones [et pourtant, il l'est devenu — note de la trad.]. Pour cela, ChaCha20 a été développé comme une alternative légère et économique, épargnant la batterie. Ainsi, il pourrait vous surprendre d'apprendre que chaque smartphone que vous pouvez acheter aujourd'hui dispose d'une sorte d'accélération pour AES et fonctionne avec ce chiffrement plus rapidement et avec une consommation d'énergie inférieure à celle de ChaCha20.

Il est évident que presque tous les processeurs de bureau / serveurs achetés ces dernières années disposent d'AES-NI.

Par conséquent, je m'attends à ce qu'AES surpasse ChaCha20 dans chaque scénario donné. La documentation officielle de WireGuard mentionne qu'avec AVX512, ChaCha20-Poly1305 surpassera AES-NI, mais cette extension du jeu d'instructions ne sera disponible que sur de grands processeurs, ce qui ne sera, encore une fois, d'aucune aide pour le matériel plus petit et mobile, qui fonctionnera toujours plus rapidement avec AES-NI.

Je ne suis pas sûr qu'on ait pu prévoir cela lors du développement de WireGuard, mais aujourd'hui, le fait qu'il soit fermement ancré à un seul chiffrement constitue déjà un inconvénient qui peut nuire à son efficacité.

IPsec permet de choisir librement le chiffrement qui convient le mieux à votre situation. Évidemment, c'est nécessaire si vous souhaitez, par exemple, transférer 10 Go ou plus de données via une connexion VPN.

Problèmes d'intégration dans Linux

Bien que WireGuard ait choisi un protocole de chiffrement moderne, cela pose déjà de nombreux problèmes. Au lieu d'utiliser ce qui est pris en charge par le noyau par défaut, l'intégration de WireGuard a été retardée pendant des années en raison de l'absence de ces primitives dans Linux.

Je ne suis pas totalement au fait de la situation dans d'autres systèmes d'exploitation, mais il est probable qu'elle ne soit pas très différente de celle sur Linux.

À quoi ressemble la réalité ?

Malheureusement, chaque fois qu'un client me demande de configurer une connexion VPN, je fais face à la question de l'utilisation de données d'identification et de chiffrement obsolètes. Le 3DES associé à MD5 est encore une pratique courante, tout comme AES-256 et SHA1. Et bien que ce dernier soit un peu mieux, ce n'est pas ce qu'il faut utiliser en 2020.

Pour l'échange de clés ont toujours on utilise RSA — un outil lent mais suffisamment sécurisé.

Mes clients sont liés aux autorités douanières et à d'autres organismes publics, ainsi qu'à de grandes entreprises dont les noms sont connus dans le monde entier. Tous utilisent un formulaire de demande qui a été créé des décennies auparavant, et la possibilité d'utiliser SHA-512 n'a tout simplement jamais été ajoutée. Je ne peux pas dire que cela affecte explicitement le progrès technologique, mais il est évident que cela ralentit les processus d'entreprise.

Cela me fait mal de le voir, car IPsec prend en charge les courbes elliptiques depuis 2005. Curve25519 est également plus récent et disponible à l'utilisation. Il existe aussi des alternatives à AES, comme Camellia et ChaCha20, mais, clairement, toutes ne sont pas prises en charge par de grands fournisseurs comme Cisco et d'autres.

Et les gens s'en servent. Il existe de nombreux kits Cisco, plusieurs ensembles conçus pour travailler avec Cisco. Ils sont des leaders du marché dans ce segment et ne sont pas très intéressés par des innovations.

Oui, la situation [dans le segment d'entreprise] est terrible, mais nous ne verrons pas de changements à cause de WireGuard. Les fabricants ne révéleront probablement jamais de problèmes de performance avec les outils et le cryptage déjà utilisés, et ne verront pas de problèmes avec IKEv2 - c'est pourquoi ils ne recherchent pas d'alternatives.

En fait, vous êtes-vous déjà demandé à abandonner Cisco ?

Benchmarks

Passons maintenant aux benchmarks de la documentation WireGuard. Bien que cette [documentation] ne soit pas un article scientifique, je m'attendais néanmoins à une approche plus scientifique de la part des développeurs, ou à l'utilisation d'une approche scientifique comme référence. Tous les benchmarks sont inutiles s'ils ne peuvent pas être reproduits, et encore plus inutiles s'ils sont obtenus dans des conditions de laboratoire.

Dans la version de WireGuard pour Linux, il obtient un avantage en utilisant GSO — Generic Segmentation Offloading. Grâce à cela, le client crée un énorme paquet de 64 kilobytes et le crypte/décrypte en une seule opération. Ainsi, les coûts d'appel et de mise en œuvre des opérations cryptographiques sont réduits. Si vous voulez maximiser la bande passante de votre connexion VPN — c'est une bonne idée.

Cependant, comme c'est souvent le cas, la réalité est plus complexe. L'envoi d'un paquet aussi volumineux vers un adaptateur réseau nécessite qu'il soit découpé en plusieurs paquets plus petits. La taille d'envoi standard est de 1500 octets. Cela signifie que notre géant de 64 kilo-octets sera divisé en 45 paquets (1240 octets d'informations et 20 octets d'en-tête IP). Ensuite, pendant un certain temps, ils bloqueront complètement le fonctionnement de l'adaptateur réseau, car ils doivent être envoyés ensemble et simultanément. Cela entraînera finalement un saut de priorité, et des paquets tels que, par exemple, VoIP, seront mis en file d'attente.

Ainsi, la bande passante élevée dont WireGuard se vante est obtenue au détriment du ralentissement des travaux réseau d'autres applications. Et l'équipe de WireGuard a déjà confirmé ceci est ma conclusion.

Mais continuons.

Selon les benchmarks dans la documentation technique, la connexion affiche une bande passante de 1011 Mbit/s.

Impressionnant.

C'est particulièrement impressionnant étant donné que la bande passante théorique maximale d'une connexion Ethernet gigabit est de 966 Mbit/s avec une taille de paquet de 1500 octets moins 20 octets pour l'en-tête IP, 8 octets pour l'en-tête UDP et 16 octets pour l'en-tête de WireGuard lui-même. Il y a également un autre en-tête IP dans le paquet encapsulé et un autre de 20 octets dans TCP. D'où vient donc cette bande passante supplémentaire ?

Avec des trames grandes et les avantages du GSO dont nous avons parlé plus haut, le maximum théorique avec une taille de trame de 9000 octets sera de 1014 Mbit/s. En réalité, une telle bande passante est généralement inatteignable, car elle entraîne d'importantes difficultés. Je ne peux donc que supposer que le test a été effectué en utilisant des trames encore plus volumineuses dépassant la taille de 64 kilo-octets avec un maximum théorique de 1023 Mbit/s, qui n'est pris en charge que par certains adaptateurs réseau. Mais cela est totalement inapplicable dans des conditions réelles, ou ne peut être utilisé que entre deux stations directement connectées, exclusivement dans le cadre d'un banc d'essai.

Cependant, étant donné que le tunnel VPN est établi entre deux hôtes via une connexion Internet qui ne supporte pas de grands trames, le résultat obtenu dans le banc d'essai ne peut pas être considéré comme une référence. C'est simplement une réalisation de laboratoire irréaliste, impossible et inapplicable dans des conditions réelles.

Même en étant dans un data center, je ne pourrais pas transférer des trames de plus de 9000 octets.

Le critère d'applicabilité dans la vie réelle est totalement violé et, je pense, l'auteur de cette « mesure » s'est gravement discrédité pour des raisons évidentes.

Un dernier éclair d'espoir

Le site de WireGuard parle beaucoup de conteneurs et il devient clair à quoi il est réellement destiné.

Un VPN simple et rapide qui ne nécessite pas de configuration et peut être déployé et configuré avec des outils d'orchestration massifs, comme ceux d'Amazon dans leur cloud. En particulier, Amazon utilise les dernières fonctionnalités matérielles que j'ai mentionnées précédemment, comme l'AVX512. Cela se fait pour accélérer le fonctionnement et ne pas s'attacher à x86 ou à toute autre architecture.

Ils optimisent la bande passante et les paquets qui dépassent 9000 octets — cela se traduit par d'énormes trames encapsulées pour la communication entre les conteneurs, ou pour des opérations de sauvegarde, de création de snapshots ou de déploiement de ces mêmes conteneurs. Même les adresses IP dynamiques n'affecteront en rien le fonctionnement de WireGuard dans le scénario que j'ai décrit.

Bien joué. Une mise en œuvre brillante et un protocole très fin, presque référentiel.

Mais il ne convient tout simplement pas au monde en dehors d'un data center complètement contrôlé par vos soins. Si vous osez utiliser WireGuard, vous devrez accepter des compromis constants lors du développement et de la mise en œuvre du protocole de chiffrement.

Sortie

Je ne peux pas m'empêcher de conclure que WireGuard n'est pas encore prêt.

Il a été conçu comme une solution légère et rapide à un certain nombre de problèmes présents dans les solutions existantes. Malheureusement, pour ces solutions, il a sacrifié de nombreuses fonctionnalités qui seront pertinentes pour la plupart des utilisateurs. C'est pourquoi il ne peut pas remplacer IPsec ou OpenVPN.

Pour que WireGuard soit compétitif, il doit ajouter au moins une configuration d'adresse IP, ainsi qu'une configuration de routage et de DNS. Il est évident que des canaux chiffrés sont nécessaires pour cela.

La sécurité est ma priorité absolue, et je n'ai actuellement aucune raison de penser qu'IKE ou TLS sont compromis ou cassés. Le chiffrement moderne est pris en charge par les deux, et ils ont été éprouvés par des décennies d'exploitation. Le fait qu'il y ait quelque chose de plus récent ne signifie pas que c'est nécessairement meilleur.

La compatibilité fonctionnelle est extrêmement importante lorsque vous vous connectez à des tiers dont vous ne contrôlez pas les stations. IPsec est de facto la norme et est pris en charge quasiment partout. Et cela fonctionne. Et même si cela semble théoriquement possible, WireGuard pourrait être incompatible à l'avenir avec différentes versions de lui-même.

Toute protection cryptographique est un jour ou l'autre compromise et doit donc être remplacée ou mise à jour.

Nier tous ces faits et désirer aveuglément utiliser WireGuard pour connecter votre iPhone à votre station de travail à domicile, c'est tout simplement un masterclass de l'autruche.

Source : habr.com