🤲🏿 👩🏾‍🔧 🤰🏼 Pourquoi vous ne devriez pas utiliser WireGuard 🎅🏿 🍠 👨🏿‍🚒

Récemment, WireGuard attire beaucoup l'attention, en fait - c'est une nouvelle "star" parmi les VPN. Mais est-il aussi bon qu'il n'y paraît? Je voudrais discuter de quelques observations et envisager la mise en œuvre de WireGuard pour expliquer pourquoi ce n'est pas une solution qui remplacera IPsec ou OpenVPN.

Dans cet article, je voudrais démystifier certains mythes [autour de WireGuard]. Oui, cela prendra beaucoup de temps à lire, donc si vous n'avez pas fait une tasse de thé ou de café, alors il est temps de le faire. Je voudrais également remercier Peter d'avoir relu mes pensées chaotiques.

Je ne me fixe pas pour objectif de discréditer les développeurs de WireGuard, de dévaluer leurs efforts ou leurs idées. Leur produit fonctionne, mais je pense personnellement qu'il est présenté complètement différent de ce qu'il est réellement - il est présenté comme un remplacement pour IPsec et OpenVPN, qui en réalité n'existe tout simplement plus.

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

Il n'y a pas eu trop de bonnes nouvelles récemment sur le sujet du noyau Linux. Donc, on nous a parlé des vulnérabilités monstrueuses du processeur, qui ont été corrigées par le logiciel, et Linus Torvalds en a parlé trop grossier et ennuyeux, langage utilitaire du développeur. Planificateur ou pile réseau de niveau zéro - aussi des sujets pas trop clairs pour les magazines sur papier glacé. Et puis WireGuard apparaît.

Tout sonne bien sur le papier: une nouvelle technologie passionnante.

Mais regardons-la un peu plus attentivement.

Documentation technique WireGuard

Cet article est basé sur la documentation officielle de WireGuard rédigée par Jason Donenfeld. Il y explique le concept, le but et l'implémentation technique de [WireGuard] dans le noyau Linux.

La première phrase se lit comme suit:

WireGuard [...] IPsec , / TLS, OpenVPN, , [].

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

Alors, quelle est la prochaine étape?

Si vous dites que vous [du VPN] n'en avez pas besoin, vous pouvez terminer la lecture. Cependant, je remarquerai que de telles tâches sont posées avant toute autre technologie de tunneling.

La plus intéressante des citations ci-dessus réside dans les mots «dans la plupart des cas», qui, bien sûr, ont été ignorés par la presse. Et nous y sommes, où nous nous sommes retrouvés à cause du chaos créé par cette négligence - dans cet article.

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

Non. Il n'y a tout simplement aucune chance que de grands fournisseurs tels que Cisco, Juniper et d'autres achètent WireGuard pour leurs produits. Ils ne «sautent pas devant les trains» en déplacement, à moins que cela ne soit vraiment nécessaire. Plus tard, je parlerai de certaines des raisons pour lesquelles ils ne pourraient probablement pas installer les produits WireGuard à bord, même s'ils le voulaient.

WireGuard transférera-t-il mon RoadWarrior d'un ordinateur portable à un centre de données?

Non. WireGuard n'a pas implémenté un grand nombre de fonctions importantes pour le moment afin qu'il puisse faire quelque chose comme ça. Par exemple, il ne peut pas utiliser l'adresse IP dynamique du côté serveur du tunnel, ce qui à lui seul rompt tout le scénario d'une utilisation similaire du produit.

IPFire est souvent utilisé pour les canaux Internet à faible coût, tels que la connexion DSL ou par câble. Cela est logique pour une petite ou moyenne entreprise qui n'a 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 fibre optique en standard, il nous a été plus facile de reconstruire. Dans les mêmes pays de l'UE ou aux États-Unis, l'accès à large bande xDSL à une vitesse de 3 à 5 Mbps est toujours la norme universelle, et la connexion par fibre optique coûte de l'argent irréaliste selon nos normes. Par conséquent, l'auteur de l'article parle de la connexion DSL ou câble comme normale, plutôt que du passé ancien.] 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 changent toujours.

Il existe un sous-projet appelé "wg-dynamic"Le démon de l'espace utilisateur ajoute à surmonter cette lacune. Un énorme problème avec le scénario utilisateur décrit ci-dessus est l'aggravation de la situation par l'adressage IPv6 dynamique.

Du point de vue du distributeur, tout cela ne semble pas très bon non plus. L'un des objectifs de conception était de maintenir le protocole simple et propre.

Malheureusement, tout cela est devenu trop simple et primitif, nous devons donc utiliser des logiciels supplémentaires pour rendre toute cette conception viable dans des conditions réelles.

WireGuard est-il si facile à utiliser?

Pas encore. Je ne dis pas que WireGuard ne sera jamais une bonne alternative pour acheminer un tunnel entre deux points, mais jusqu'à présent, ce n'est qu'une version alpha du produit qu'il devrait devenir.

Mais alors que fait-il vraiment? IPsec est-il vraiment beaucoup plus difficile à utiliser?

Évidemment pas. Le fournisseur IPsec a pris en compte ce point et fournit son produit avec une interface telle que IPFire.

Pour configurer un tunnel VPN via 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 du côté récepteur, les sous-réseaux que vous souhaitez rendre publics via cette connexion VPN et pré-partagés clé. Ainsi, le VPN est configuré en quelques minutes et il est compatible avec n'importe quel fournisseur.

Malheureusement, il y a quelques exceptions à cette histoire. Tous ceux qui ont essayé de transmettre un tunnel VPN via IPsec à une machine sur OpenBSD comprennent de quoi je parle. Il y a quelques exemples plus douloureux, mais en fait, la bonne pratique d'utilisation d'IPsec est beaucoup, beaucoup plus.

À 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ù c'était la vraie préoccupation de l'utilisateur, nous nous serions débarrassés depuis longtemps des protocoles SIP, H.323, FTP et autres créés il y a plus de dix ans qui ne fonctionnent pas bien avec NAT.

Il y a des raisons pour lesquelles IPsec est plus compliqué que WireGuard: il en fait beaucoup plus. Par exemple, l'authentification des utilisateurs à l'aide d'un identifiant / mot de passe ou d'une carte SIM avec EAP. Il a la capacité étendue d'ajouter de nouvelles primitives cryptographiques .

Mais WireGuard ne le fait pas.

Et cela signifie que WireGuard se cassera à un moment donné, car l'une des primitives cryptographiques s'affaiblira ou sera complètement compromise. L'auteur de la documentation technique dit ceci:

Il convient de noter que WireGuard est cryptographiquement sûr de lui. Il n'a pas intentionnellement la flexibilité des chiffres et des protocoles. Si des trous graves sont trouvés dans les primitives sous-jacentes, tous les points de terminaison devront être mis à jour. Comme vous pouvez le voir dans le flux continu de vulnérabilités SLL / TLS, la flexibilité du chiffrement a maintenant considérablement augmenté.

La dernière phrase est absolument vraie.

Construire un consensus sur le chiffrement à utiliser rend les protocoles comme IKE et TLS plus complexes. Trop compliqué? Oui, les vulnérabilités sont assez courantes dans TLS / SSL, et il n'y a pas d'alternative à celles-ci.

Ignorer les vrais problèmes

Imaginez que vous ayez un serveur VPN avec 200 clients de combat, quelque part dans le monde. Il s'agit d'un cas d'utilisation très standard. Si vous devez modifier le cryptage, vous devez fournir la mise à jour à toutes les copies de WireGuard sur ces ordinateurs portables, smartphones, etc. Livrez en même temps . C'est littéralement impossible. Les administrateurs qui essaient de le faire mettront des mois à déployer les configurations nécessaires, et les moyennes entreprises mettront littéralement des années à accueillir un tel événement.

IPsec et OpenVPN offrent la négociation de chiffrement. Par conséquent, un certain temps après lequel vous activez le nouveau cryptage, l'ancien fonctionnera. Grâce à cela, les clients actuels pourront passer à la nouvelle version. Une fois la mise à jour déployée, vous désactivez simplement le chiffrement vulnérable. Et c'est tout! Terminé! tu es magnifique! Et les clients ne le remarqueront même pas.

Il s'agit en fait d'un cas très courant pour les déploiements importants, et même OpenVPN a quelques difficultés. La rétrocompatibilité est importante, et bien que vous utilisiez un cryptage plus faible, pour beaucoup, cela ne provoque pas la fermeture de l'entreprise. Parce que cela entraînera la paralysie de centaines de clients en raison de leur incapacité à faire leur travail.

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

Cryptographie!

Mais quel est ce nouveau cryptage intéressant que WireGuard utilise?

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 normalisé pour IPsec et OpenVPN (via TLS).

Évidemment, le développement de Daniel Bernstein est utilisé très souvent. BLAKE2 est le successeur de BLAKE, le finaliste de SHA-3 qui n'a pas gagné en raison de sa ressemblance avec SHA-2. Si SHA-2 était piraté, il y avait une forte probabilité que BLAKE soit compromis.

IPsec et OpenVPN n'ont pas besoin de SipHash en raison de leur conception. Ainsi, la seule chose qui ne peut pas être utilisée avec eux pour le moment est BLAKE2, et seulement jusqu'à ce qu'elle soit standardisée. Ce n'est pas un gros inconvénient, car les VPN utilisent HMAC pour créer l'intégrité, ce qui est considéré comme une solution solide même en conjonction avec MD5.

Je suis donc arrivé à la conclusion que tous les VPN utilisent presque le même ensemble d'outils cryptographiques. Par conséquent, WireGuard n'est ni plus ni moins sûr que tout autre produit pertinent en ce qui concerne le chiffrement ou l'intégrité des données.

Mais même ce n'est pas la chose la plus importante à laquelle vous devriez faire attention selon la documentation officielle du projet. Après tout, l'essentiel est la vitesse.

WireGuard est-il plus rapide que les autres solutions VPN?

En bref: non, pas plus vite.

ChaCha20 est un chiffrement de flux plus facile à implémenter dans le logiciel. Il crypte un bit à la fois. Les protocoles de bloc, tels que AES, chiffrent un bloc 128 bits à la fois. Pour implémenter le support matériel, beaucoup plus de transistors seront nécessaires, donc les processeurs plus grands sont livrés avec AES-NI, une extension du jeu d'instructions qui effectue certaines tâches du processus de cryptage pour l'accélérer.

On s'attendait à ce que AES-NI ne frappe jamais les smartphones [et il a frappé, - env. trans.]. Pour cela, le ChaCha20 a été développé - comme une alternative simple et économique qui économise l'énergie de la batterie. Par conséquent, il peut être nouveau pour vous que chaque smartphone que vous pouvez acheter aujourd'hui ait une accélération ou une autre pour AES et fonctionne avec ce cryptage plus rapidement et avec moins de consommation d'énergie qu'avec ChaCha20.

De toute évidence, presque 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 AES dépasse ChaCha20 dans chaque scénario. Dans la documentation officielle de WireGuard, il est mentionné que grâce à l'AVX512, le ChaCha20-Poly1305 surpassera AES-NI, mais cette extension du jeu de commandes ne sera disponible que sur les gros processeurs, ce qui n'aidera pas non plus avec les équipements plus petits et mobiles qui fonctionneront toujours plus vite avec AES- NI.

Je ne sais pas si cela aurait pu être prévu lors du développement de WireGuard, mais aujourd'hui le fait qu'il soit cloué sur un cryptage est déjà un inconvénient qui peut ne pas affecter très bien son travail.

IPsec vous permet de choisir librement le cryptage le mieux adapté à votre application. 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 Linux

Bien que WireGuard ait choisi un protocole de cryptage moderne, cela pose déjà beaucoup de problèmes. Et donc, au lieu d'utiliser ce qui est pris en charge par le noyau prêt à l'emploi, l'intégration de WireGuard a été retardée pendant des années en raison du manque de ces primitives sous Linux.

Je ne suis pas pleinement conscient de la situation dans d'autres systèmes d'exploitation, mais ce n'est probablement pas très différent de la situation avec Linux.

À quoi ressemble la réalité?

Malheureusement, chaque fois qu'un client me demande de configurer une connexion VPN pour lui, je tombe sur le fait qu'il utilise des informations d'identification et un cryptage obsolètes. 3DES en conjonction avec MD5 est toujours 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 , RSA est toujours utilisé - un outil lent mais assez sûr.

Mes clients sont en relation avec les autorités douanières et d'autres organisations et institutions étatiques, ainsi qu'avec de grandes sociétés, 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 cela ralentit évidemment le processus d’entreprise.

Cela me fait mal de voir cela, car IPsec prend en charge les courbes elliptiques hors de la courbe depuis l'année 2005. Curve25519 est également plus récent et plus accessible. Il existe encore des alternatives à AES, telles que Camellia et ChaCha20, mais, bien sûr, elles ne sont pas toutes prises en charge par de grands fournisseurs, tels que Cisco et d'autres.

Et les gens l'utilisent. 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 les innovations.

Oui, la situation [dans le segment des entreprises] est terrible, mais nous ne verrons aucun changement dû à WireGuard. Les fabricants sont susceptibles de ne jamais identifier de problèmes de performances avec les outils et le chiffrement déjà utilisés, ils ne verront pas de problèmes lors de l'utilisation d'IKEv2 - et ne recherchent donc pas d'alternatives.

En général, avez-vous déjà pensé à abandonner Cisco?

Repères

Passons maintenant aux benchmarks de la documentation WireGuard. Bien que cette [documentation] ne soit pas un article scientifique, je m'attendais quand même à ce que les développeurs adoptent une approche plus scientifique ou utilisent une approche scientifique comme référence. Les repères sont inutiles s'ils ne peuvent pas être reproduits, et plus encore ils sont inutiles lorsqu'ils sont obtenus en laboratoire.

Dans la version WireGuard pour Linux, il profite du GSO - Generic Segmentation Offloading. Grâce à lui, le client crée un énorme paquet de 64 kilo-octets et le chiffre / le déchiffre en une seule approche. Ainsi, le coût de l'appel et de la mise en œuvre des opérations cryptographiques est réduit. Si vous souhaitez maximiser la bande passante de votre connexion VPN, c'est une bonne idée.

Mais, comme d'habitude, en réalité ce n'est pas si simple. L'envoi d'un si gros paquet à une carte réseau nécessite qu'il soit découpé en plusieurs petits paquets. La taille d'envoi typique est de 1 500 octets. Autrement dit, nos 64 kilo-octets géants seront divisés en 45 paquets (1240 octets d'informations et 20 octets d'en-tête IP). Ensuite, pendant un certain temps, ils bloquent complètement le fonctionnement de la carte réseau, car ils doivent être envoyés ensemble et immédiatement. En conséquence, cela entraînera un saut de priorité et des paquets tels que, par exemple, VoIP, seront mis en file d'attente.

Ainsi, le haut débit, que WireGuard revendique si hardiment, est atteint en ralentissant le fonctionnement du réseau d'autres applications. Et l'équipe WireGuard a déjà confirmé ma conclusion.

Mais passons à autre chose.

Selon les repères de la documentation technique, la connexion affiche une bande passante de 1011 Mbit / s.

Impressionnant.

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

Avec les énormes trames et avantages du GSO, dont nous avons parlé ci-dessus, le maximum théorique avec une taille de trame de 9000 octets sera de 1014 Mbit / s. Habituellement, un tel débit est inaccessible en 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 encore plus audacieuses dépassant la taille de 64 kilo-octets avec un maximum théorique de 1023 Mbit / s, ce qui n'est pris en charge que par certains adaptateurs réseau. Mais cela n'est absolument pas applicable dans des conditions réelles, ou il ne peut être utilisé qu'entre deux stations directement connectées l'une à l'autre, exclusivement à l'intérieur du banc d'essai.

Mais comme le tunnel VPN est transféré entre deux hôtes à l'aide d'une connexion Internet qui ne prend pas du tout en charge les grandes trames, le résultat obtenu sur le stand ne peut pas être pris comme standard. Il s'agit simplement d'une réalisation de laboratoire irréaliste, impossible et non applicable dans des conditions de combat réelles.

Même assis dans le centre de données, je ne serais pas en mesure de transférer des trames supérieures à 9 000 octets.

Le critère d'applicabilité dans la vie réelle est complètement violé et, comme je pense, l'auteur de la "mesure" s'est sérieusement discrédité pour des raisons évidentes.

La dernière lueur d'espoir

Le site Web de WireGuard parle beaucoup de conteneurs et il devient clair à quoi ils sont réellement destinés.

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 Amazon dans leur cloud. Plus précisément, Amazon utilise les dernières fonctionnalités matérielles que j'ai mentionnées plus tôt, par exemple - AVX512. Ceci est fait afin d'accélérer le travail et de ne pas être lié à x86 ou à toute autre architecture.

Ils optimisent la bande passante et les paquets dont la taille dépasse 9000 octets - cela se traduira par d'énormes trames encapsulées pour communiquer les conteneurs entre eux, ou pour les opérations de sauvegarde, créer des instantanés ou déployer ces conteneurs. Même les adresses IP dynamiques n'affecteront pas le fonctionnement de WireGuard dans le cas du scénario que j'ai décrit.

Pas mal joué. Une implémentation brillante et un protocole très mince, presque de référence.

Mais il n'est tout simplement pas adapté au monde extérieur au centre de données que vous contrôlez complètement. Si vous prenez le risque et commencez à utiliser WireGuard, vous devrez constamment faire des compromis dans le développement et la mise en œuvre du protocole de chiffrement.

Conclusion

Il m'est facile 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 avec 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 devienne compétitif, il doit ajouter au moins la configuration d'adresse IP et la configuration de routage et DNS. C'est évidemment pour cela que les canaux cryptés sont nécessaires.

La sécurité est ma priorité absolue, et pour l'instant je n'ai aucune raison de croire que IKE ou TLS est en quelque sorte compromis ou cassé. Le cryptage moderne est pris en charge dans les deux, et ils ont été testés pendant des décennies de fonctionnement. Si quelque chose de plus récent ne signifie pas que c'est quelque chose, c'est mieux.

L'interopérabilité est cruciale lorsque vous contactez des tiers dont vous ne contrôlez pas les stations. IPsec est la norme de facto et est pris en charge presque universellement. Et il fonctionne. Et peu importe à quoi il ressemble, en théorie, WireGuard à l'avenir peut ne pas être compatible, même avec différentes versions de lui-même.

Toute protection cryptographique est piratée tôt ou tard et, en conséquence, doit être remplacée ou mise à jour.

Nier tous ces faits et vouloir aveuglément utiliser WireGuard pour connecter votre iPhone à votre poste de travail à domicile n'est qu'un atelier pour vous mettre la tête dans le sable.

Pourquoi vous ne devriez pas utiliser WireGuard