Récemment WireGuard elle attire beaucoup l'attention, en fait c'est une nouvelle « star » parmi VPNMais est-ce aussi bien qu'il n'y paraît ? J'aimerais discuter de certaines observations et examiner la mise en œuvre. WireGuard, pour expliquer pourquoi ce n'est pas une solution qui remplacera IPsec ou OpenVPN.
Dans cet article, j'aimerais démystifier certains mythes [autour de WireGuardOui, c'est un long texte, alors si vous n'avez pas encore préparé une tasse de thé ou de café, c'est le moment. Je tiens également à remercier Peter d'avoir relu mes idées décousues.
Mon objectif n'est pas de discréditer les développeurs. WireGuard, dévaloriser leurs efforts ou leurs idées. Leur produit fonctionne, mais je crois personnellement qu'il est présenté comme quelque chose de complètement différent de ce qu'il est réellement : présenté comme un remplacement pour IPsec et OpenVPN, qui en réalité n'existe tout simplement plus aujourd'hui.
À titre de précision, je tiens à ajouter que la responsabilité d'un tel positionnement WireGuard sont relayées par les médias qui en ont parlé, et non par le projet lui-même ou ses créateurs.
Récemment, au sujet du noyau Linux Il n'y avait pas grand-chose de bon. On nous a parlé de failles monstrueuses dans les processeurs, corrigées par logiciel, mais le récit de Linus Torvalds était trop grossier et ennuyeux, dans le langage utilitaire d'un développeur. Le planificateur ou la pile réseau de niveau 0 ne sont pas vraiment des sujets de prédilection pour les magazines spécialisés. Et puis arrive… WireGuard.
Sur le papier, tout cela sonne bien : une nouvelle technologie passionnante.
Mais regardons ça d'un peu plus près.
Documentation technique WireGuard
Cet article est basé sur documents officiels WireGuard, écrit par Jason Donenfeld, où il explique le concept, le but et la mise en œuvre technique [WireGuard] dans le noyau Linux.
La première phrase se lit comme suit :
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 que OpenVPN, tout en étant plus sûr, plus productif et plus facile à utiliser [outil].
Bien sûr, le principal avantage de toutes les nouvelles technologies est leur la simplicité [par rapport aux prédécesseurs]. Mais un VPN doit aussi être efficace et sécuritaire.
Et quelle est la prochaine?
Si vous dites que ce n'est pas ce dont vous avez besoin [d'un VPN], vous pouvez terminer la lecture ici. Cependant, je noterai que de telles tâches sont définies pour toute autre technologie de tunnellisation.
La plus intéressante de la citation ci-dessus réside dans les mots "dans la plupart des cas", qui, bien sûr, ont été ignorés par la presse. Et donc, nous en sommes là où nous nous sommes retrouvés à cause du chaos créé par cette négligence - dans cet article.
Cela va-t-il se produire ? WireGuard remplacer mon VPN site à site [IPsec] ?
Non. Il n'y a tout simplement aucune chance que de grands fournisseurs comme Cisco, Juniper et autres l'acquièrent pour leurs produits. WireGuardIls ne profitent pas des opportunités qui se présentent à eux, sauf en cas d'urgence. J'aborderai plus tard les raisons pour lesquelles il leur sera probablement impossible d'installer leurs produits à bord. WireGuard, même s'ils le voulaient.
Survivra-t-il ? WireGuard Mon RoadWarrior, d'un ordinateur portable à un centre de données ?
Non. En ce moment, WireGuard De nombreuses fonctionnalités essentielles font défaut pour permettre une telle utilisation. Par exemple, l'impossibilité d'utiliser des adresses IP dynamiques côté serveur de tunnel rend ce produit inutilisable.
IPFire est souvent utilisé pour les liaisons Internet bon marché, telles que les connexions DSL ou par câble. Cela a du sens pour les petites ou moyennes entreprises qui n'ont pas besoin de fibre rapide. [Note du traducteur : n'oubliez pas qu'en termes de communications, la Russie et certains pays de la CEI sont loin devant l'Europe et les États-Unis, car nous avons commencé à construire nos réseaux beaucoup plus tard et avec l'avènement des réseaux Ethernet et de la fibre optique en tant que standard, il nous était plus facile de reconstruire. Dans les mêmes pays de l'UE ou des États-Unis, l'accès haut débit xDSL à une vitesse de 3 à 5 Mbps est toujours la norme générale, et une connexion à fibre optique coûte de l'argent irréaliste selon nos normes. Par conséquent, l'auteur de l'article parle de connexion DSL ou par câble comme la norme, et non des temps anciens.] Cependant, DSL, câble, LTE (et autres méthodes d'accès sans fil) ont des adresses IP dynamiques. Bien sûr, parfois ils ne changent pas souvent, mais ils changent.
Il existe un sous-projet appelé "wg-dynamique", qui ajoute un démon d'espace utilisateur pour pallier cette lacune. Un énorme problème avec le scénario utilisateur décrit ci-dessus est l'aggravation de l'adressage IPv6 dynamique.
Du point de vue du distributeur, tout cela n'a pas l'air très bon non plus. L'un des objectifs de conception était de garder le protocole simple et propre.
Malheureusement, tout cela est en fait devenu trop simple et primitif, de sorte que nous devons utiliser des logiciels supplémentaires pour que toute cette conception soit viable en utilisation réelle.
WireGuard Est-ce si facile à utiliser ?
Pas encore. Je ne dis pas ça. WireGuard Ce ne sera jamais une bonne alternative pour créer des tunnels entre deux points, mais pour l'instant, il ne s'agit que d'une version alpha du produit qu'il est censé devenir.
Mais alors que fait-il concrètement ? IPsec est-il vraiment plus difficile à maintenir ?
Évidemment pas. Le fournisseur IPsec a pensé à cela et livre son produit avec une interface, comme avec IPFire.
Pour configurer un tunnel VPN sur IPsec, vous aurez besoin de cinq ensembles de données que vous devrez entrer dans la configuration : votre propre adresse IP publique, l'adresse IP publique de la partie destinataire, les sous-réseaux que vous souhaitez rendre publics via cette connexion VPN et cette clé pré-partagée. Ainsi, le VPN est configuré en quelques minutes et est compatible avec n'importe quel fournisseur.
Malheureusement, il y a quelques exceptions à cette histoire. Quiconque a essayé de tunnel sur IPsec vers une machine OpenBSD sait de quoi je parle. Il existe quelques exemples plus douloureux, mais en fait, il existe de nombreuses autres bonnes pratiques pour utiliser IPsec.
À propos de la complexité du protocole
L'utilisateur final n'a pas à se soucier de la complexité du protocole.
Si nous vivions dans un monde où cela était une réelle préoccupation de l'utilisateur, nous nous serions débarrassés depuis longtemps de SIP, H.323, FTP et d'autres protocoles créés il y a plus de dix ans qui ne fonctionnent pas bien avec NAT.
Il existe des raisons pour lesquelles IPsec est plus complexe que WireGuardIl offre bien plus de fonctionnalités. Par exemple, il authentifie les utilisateurs par identifiant et mot de passe ou par carte SIM avec EAP. Il permet également d'ajouter de nouveaux utilisateurs. primitives cryptographiques.
Et à WireGuard ça ne l'est pas.
Et cela signifie que WireGuard À un moment donné, le système échouera car l'une des primitives cryptographiques sera affaiblie ou totalement compromise. L'auteur de la documentation technique l'explique ainsi :
Il convient de noter que WireGuard Un excès de confiance en matière de cryptographie. Ce système manque volontairement de flexibilité dans ses algorithmes et protocoles de chiffrement. Si des failles importantes sont découvertes dans les primitives sous-jacentes, tous les points de terminaison devront être mis à jour. Comme le démontre la multiplication actuelle des vulnérabilités SSL/TLS, la flexibilité du chiffrement a considérablement augmenté.
La dernière phrase est tout à fait correcte.
Parvenir à un consensus sur le cryptage à utiliser rend les protocoles comme IKE et TLS plus complexe. Trop compliqué? Oui, les vulnérabilités sont assez courantes dans TLS/SSL, et il n'y a pas d'alternative à celles-ci.
En ignorant les vrais problèmes
Imaginez un serveur VPN avec 200 clients de production répartis dans le monde entier. C'est un cas d'utilisation assez courant. Si vous devez modifier le chiffrement, vous devez déployer la mise à jour sur tous les serveurs. WireGuard sur ces ordinateurs portables, smartphones, etc. En même temps livrer. C'est littéralement impossible. Les administrateurs qui tentent de le faire mettront des mois à déployer les configurations requises, et il faudra littéralement des années à une entreprise de taille moyenne pour réussir un tel événement.
IPsec et OpenVPN Nous proposons une fonctionnalité de négociation de chiffrement. Ainsi, pendant une courte période après l'activation du nouveau chiffrement, l'ancien restera fonctionnel. Cela permet aux clients actuels de passer à la nouvelle version. Une fois la mise à jour déployée, il vous suffit de désactiver le chiffrement vulnérable. Et voilà ! C'est fait ! Bravo ! Vos clients n'y verront que du feu.
C'est en fait un cas très courant pour les déploiements à grande échelle, et même OpenVPN Il y a quelques difficultés à ce sujet. La rétrocompatibilité est importante, et même si un chiffrement plus faible est utilisé, pour beaucoup, ce n'est pas une raison pour interrompre leur activité. En effet, cela paralyserait des centaines de clients, les empêchant de travailler.
Équipe WireGuard Le protocole a été simplifié, mais il est totalement inadapté aux personnes qui ne contrôlent pas en permanence les deux pairs de leur tunnel. D'après mon expérience, c'est le cas le plus fréquent.
Cryptographie !
Mais en quoi consiste ce nouveau chiffrement intéressant utilisé ? WireGuard?
WireGuard Il utilise Curve25519 pour l'échange de clés, ChaCha20 pour le chiffrement et Poly1305 pour l'authentification des données. Il prend également en charge SipHash pour le hachage des clés et BLAKE2 pour le hachage.
ChaCha20-Poly1305 est normalisé pour IPsec et OpenVPN (via TLS).
Il est évident que le développement de Daniel Bernstein est très souvent utilisé. BLAKE2 est le successeur de BLAKE, un finaliste SHA-3 qui n'a pas gagné en raison de sa similitude avec SHA-2. Si SHA-2 devait être brisé, il y avait de fortes chances que BLAKE soit également compromis.
IPsec et OpenVPN De par sa conception, SipHash n'est pas requis. Par conséquent, seul BLAKE2 ne peut pas être utilisé actuellement, et ce jusqu'à sa normalisation. Cela ne constitue pas un inconvénient majeur, car les VPN utilisent HMAC pour l'intégrité, une solution considérée comme robuste même associée à MD5.
J'en suis donc arrivé à la conclusion que tous les VPN utilisent quasiment le même ensemble d'outils cryptographiques. WireGuard En matière de chiffrement ou d'intégrité des données transmises, il n'est ni plus ni moins sûr que n'importe quel autre produit actuel.
Mais même ce n'est pas la chose la plus importante, à laquelle il convient de prêter attention selon la documentation officielle du projet. Après tout, l'essentiel est la vitesse.
WireGuard plus rapide que les autres solutions VPN ?
En bref : non, pas plus rapide.
ChaCha20 est un chiffrement de flux plus facile à implémenter dans un logiciel. Il crypte un bit à la fois. Les protocoles de blocs comme AES chiffrent un bloc de 128 bits à la fois. Beaucoup plus de transistors sont nécessaires pour implémenter le support matériel, donc les processeurs plus gros sont livrés avec AES-NI, une extension de jeu d'instructions qui exécute certaines des tâches du processus de cryptage pour l'accélérer.
On s'attendait à ce qu'AES-NI n'entre jamais dans les smartphones [mais c'est le cas - env. par.]. Pour cela, le ChaCha20 a été développé comme une alternative légère et économe en batterie. Par conséquent, il se peut que vous sachiez que chaque smartphone que vous pouvez acheter aujourd'hui possède une sorte d'accélération AES et fonctionne plus rapidement et avec une consommation d'énergie inférieure avec ce cryptage qu'avec ChaCha20.
Évidemment, à peu près tous les processeurs de bureau/serveur achetés au cours des deux dernières années ont AES-NI.
Par conséquent, je m'attends à ce que l'AES surpasse le ChaCha20 dans tous les cas de figure. Dans la documentation officielle WireGuard Il est mentionné que grâce à AVX512, ChaCha20-Poly1305 sera plus performant qu'AES-NI, mais cette extension du jeu d'instructions ne sera disponible que sur les processeurs plus grands, ce qui ne sera d'aucune utilité pour le matériel plus petit et mobile, qui sera toujours plus rapide avec AES-NI.
Je ne sais pas si cela aurait pu être prévu lors du développement. WireGuardmais aujourd'hui, le fait qu'il soit limité à un seul système de chiffrement constitue déjà un désavantage qui risque de nuire à son fonctionnement.
IPsec vous permet de choisir librement le cryptage le mieux adapté à votre cas. Et bien sûr, cela est nécessaire si, par exemple, vous souhaitez transférer 10 gigaoctets ou plus de données via une connexion VPN.
Problèmes d'intégration dans Linux
Bien que WireGuard J'ai choisi un protocole de chiffrement moderne, ce qui cause déjà de nombreux problèmes. Par conséquent, au lieu d'utiliser les fonctionnalités natives du noyau, l'intégration WireGuard a été reporté pendant des années en raison du manque de ces éléments primitifs dans Linux.
Je ne suis pas tout à fait sûr de la situation sur les autres systèmes d'exploitation, mais elle ne doit pas être très différente de celle-ci. Linux.
A quoi ressemble la réalité ?
Malheureusement, chaque fois qu'un client me demande de configurer une connexion VPN pour lui, je rencontre le problème qu'il utilise des informations d'identification et un cryptage obsolètes. 3DES en conjonction avec MD5 est encore une pratique courante, tout comme AES-256 et SHA1. Et bien que ce dernier soit légèrement meilleur, ce n'est pas quelque chose qui devrait être utilisé en 2020.
Pour l'échange de clés toujours RSA est utilisé - un outil lent mais assez sûr.
Mes clients sont associés aux autorités douanières et à d'autres organisations et institutions gouvernementales, ainsi qu'à de grandes entreprises dont les noms sont connus dans le monde entier. Ils utilisent tous un formulaire de demande créé il y a des décennies, et la possibilité d'utiliser SHA-512 n'a tout simplement jamais été ajoutée. Je ne peux pas dire que cela affecte clairement le progrès technologique, mais évidemment cela ralentit le processus de l'entreprise.
Cela me fait mal de voir cela, car IPsec prend en charge les courbes elliptiques depuis 2005. Curve25519 est également plus récent et disponible. Il existe également des alternatives à AES comme Camellia et ChaCha20, mais elles ne sont évidemment pas toutes prises en charge par les principaux fournisseurs comme Cisco et d'autres.
Et les gens en profitent. Il existe de nombreux kits Cisco, il existe de nombreux kits conçus pour fonctionner avec Cisco. Ils sont leaders du marché dans ce segment et ne sont pas très intéressés par l'innovation, quelle qu'elle soit.
Oui, la situation [dans le secteur des entreprises] est terrible, mais nous ne constaterons aucun changement à cause de WireGuardLes fabricants ne découvriront probablement jamais de problèmes de performance avec les outils et le chiffrement qu'ils utilisent déjà, ni aucun problème avec IKEv2 ; c'est pourquoi ils ne recherchent pas d'alternatives.
En général, avez-vous déjà pensé à abandonner Cisco ?
Repères
Passons maintenant aux points de référence issus de la documentation. WireGuardBien que cette documentation ne soit pas un article scientifique, j'attendais des développeurs une approche plus rigoureuse, ou du moins qu'ils s'appuient sur une méthodologie scientifique. Les tests de performance sont inutiles s'ils ne sont pas reproductibles, et encore plus lorsqu'ils sont réalisés en laboratoire.
En assemblage WireGuard pour Linux L'utilisation de GSO (Generic Segmentation Offloading) présente un avantage certain. Elle permet au client de créer un paquet de 64 kilo-octets et de le chiffrer/déchiffrer en une seule opération. Cela réduit le coût des opérations et appels cryptographiques. Si vous souhaitez optimiser le débit de votre connexion VPN, cette solution est particulièrement intéressante.
Mais, comme d'habitude, la réalité n'est pas si simple. L'envoi d'un paquet aussi volumineux à une carte réseau nécessite qu'il soit découpé en plusieurs paquets plus petits. La taille d'envoi normale est de 1500 octets. Autrement dit, 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 travail de la carte réseau, car ils doivent être envoyés ensemble et en même temps. En conséquence, cela entraînera un saut de priorité et des paquets tels que VoIP, par exemple, seront mis en file d'attente.
Ainsi, le débit élevé si hardiment revendiqué WireGuard, est réalisé en ralentissant les performances réseau des autres applications. Et l'équipe WireGuard déjà confirmé c'est ma conclusion.
Mais passons à autre chose.
Selon les repères de la documentation technique, la connexion affiche un débit de 1011 Mbps.
Impressionnant.
C'est d'autant plus impressionnant que le débit théorique maximal d'une seule connexion Gigabit Ethernet est de 966 Mbps 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 lui-même. WireGuardIl y a un autre en-tête IP dans le paquet encapsulé et un autre dans TCP, d'une longueur de 20 octets. D'où provient donc cette bande passante supplémentaire ?
Avec des trames énormes et les avantages de GSO dont nous avons parlé ci-dessus, le maximum théorique pour une taille de trame de 9000 octets serait de 1014 Mbps. Habituellement, un tel débit est inaccessible dans la réalité, car il est associé à de grandes difficultés. Ainsi, je ne peux que supposer que le test a été effectué en utilisant des trames surdimensionnées encore plus grosses de 64 kilo-octets avec un maximum théorique de 1023 Mbps, qui n'est pris en charge que par certaines cartes réseau. Mais ceci est absolument inapplicable en conditions réelles, ou ne peut être utilisé qu'entre deux stations directement connectées, exclusivement au sein du banc d'essai.
Mais comme le tunnel VPN est transmis entre deux hôtes utilisant une connexion Internet qui ne supporte pas du tout les trames jumbo, le résultat obtenu sur le banc ne peut pas être considéré comme une référence. Il s'agit simplement d'une réalisation de laboratoire irréaliste, impossible et inapplicable dans des conditions de combat réelles.
Même assis dans le centre de données, je ne pouvais pas transférer de trames supérieures à 9000 XNUMX octets.
Le critère d'applicabilité dans la vie réelle est absolument violé et, comme je le pense, l'auteur de la "mesure" effectuée s'est sérieusement discrédité pour des raisons évidentes.
Dernière lueur d'espoir
Le site WireGuard On parle beaucoup de conteneurs et on comprend mieux à quoi ils sont réellement destinés.
Un VPN simple et rapide qui ne nécessite aucune configuration et peut être déployé et configuré avec des outils d'orchestration massifs comme Amazon a dans leur cloud. Plus précisément, Amazon utilise les dernières fonctionnalités matérielles que j'ai mentionnées précédemment, telles que l'AVX512. Ceci est fait afin d'accélérer le travail et de ne pas être lié à x86 ou à toute autre architecture.
Ils optimisent le débit et la taille des paquets au-delà de 9 000 octets, ce qui permet de créer des trames encapsulées de grande taille pour la communication entre conteneurs, les opérations de sauvegarde, la création d'instantanés ou le déploiement de conteneurs. Même les adresses IP dynamiques n'ont aucun impact sur les performances. WireGuard dans le cas du scénario que j'ai décrit.
Bien joué. Mise en œuvre brillante et protocole très fin, presque de référence.
Mais ce n'est tout simplement pas adapté au monde extérieur à un centre de données que vous contrôlez entièrement. Si vous prenez le risque et commencez à l'utiliser WireGuardVous devrez faire des compromis constants lors de la conception et de la mise en œuvre d'un protocole de chiffrement.
conclusion
Il ne m'est pas difficile de conclure que WireGuard Pas encore prêt.
Il était conçu comme une solution légère et rapide à plusieurs problèmes des solutions existantes. Malheureusement, pour y parvenir, il a sacrifié de nombreuses fonctionnalités utiles à la plupart des utilisateurs. C'est pourquoi il ne peut pas remplacer IPsec ou OpenVPN.
Afin de WireGuard Pour devenir compétitive, cette solution doit au moins intégrer la configuration des adresses IP, le routage et la configuration DNS. Des canaux chiffrés sont donc indispensables.
La sécurité est ma priorité absolue, et pour le moment je n'ai aucune raison de croire qu'IKE ou TLS sont en quelque sorte compromis ou cassés. Le cryptage moderne est pris en charge dans les deux, et ils ont été prouvés par des décennies de fonctionnement. Ce n'est pas parce que quelque chose est nouveau qu'il est meilleur.
L'interopérabilité est cruciale pour communiquer avec des tiers dont vous ne contrôlez pas les stations. IPsec est la norme de facto et est pris en charge presque partout. Et cela fonctionne. Et quelle que soit son apparence, en théorie, WireGuard À l'avenir, il pourrait même être incompatible avec différentes versions d'il-même.
Toute protection cryptographique est rompue tôt ou tard et, par conséquent, doit être remplacée ou mise à jour.
Le déni de tous ces faits et un désir aveugle d'utiliser WireGuard pour connecter votre iPhone Aménager un poste de travail à domicile est une leçon magistrale d'autruche.
Source: habr.com
