Face à OpenVPN, WireGuard veut devenir le Signal des connexions chiffrées
Chiffrement et stickers
Le 05 septembre 2017 à 09h37
10 min
Internet
Internet
Depuis deux ans, Jason Donenfeld conçoit WireGuard, un protocole VPN censé mettre au rebut les outils classiques de sécurisation de connexions. Avec un code minuscule et de meilleures performances, il doit convaincre les internautes de se débarrasser d'OpenVPN, conçu il y a plus de 15 ans.
Pour sécuriser une connexion sur un réseau Wi-Fi public ou accéder à des contenus indisponibles dans un pays, les réseaux privés virtuels (VPN) sont devenus des outils quasi-incontournables. L'ensemble des données sont chiffrées dans le tunnel qui relie le client (un ordinateur, un smartphone...) et le serveur, qui dialogue lui-même avec le reste d'Internet. Les bases les plus utilisées s'appellent IPsec (conceptualisé en 1995) et OpenVPN (d'abord sorti en 2001).
Ce sont ces deux protocoles que WireGuard veut déloger des serveurs VPN. Pour Jason Donenfeld, guitariste de jazz et chercheur en sécurité installé en France depuis cinq ans, la complexité de ces deux outils historiques est un danger pour les utilisateurs. Si des failles sont corrigées et trouvées, il serait impossible de s'assurer qu'aucune des larges parties d'OpenVPN ne contient de problème (voir notre analyse).
« WireGuard a l’approche opposée : voir à quel point un design peut être minimal, tout en étant fondé sur de bons concepts et utilisable comme le bloc fondateur d’autres projets » nous explique son concepteur, d'abord rencontré lors de la dernière Nuit du Hack fin juin.
La simplicité avant tout, du code à la configuration
Le principal argument de WireGuard est la simplicité de son code, moins de 4 000 lignes, contre bien plus pour OpenVPN, la première cible de Jason Donenfeld. « C’est très court. C’est si peu qu’une personne peut tout lire en une après-midi » affirme-t-il. « Bien sûr, ce n’est pas la panacée contre toutes les failles de sécurité, mais cette taille et cette simplicité placent WireGuard dans une toute autre catégorie qu’OpenVPN et IPsec. »
WireGuard est la brique centrale sur laquelle doivent s'appuyer des serveurs VPN. « Pour l’utilisateur final, il est important de noter que WireGuard est un bloc central, à utiliser pour construire d’autres projets. Donc il y a le noyau, WireGuard, sur lequel toutes sortes d’interfaces graphiques et d’outils de gestion peuvent être créés » résume son créateur.
Pour le spécialiste de la cryptographie Jean-Philippe Aumasson, « WireGuard est plus fiable qu'OpenVPN ». D'une part, par la taille du code. D'autre part, par « le choix des composants cryptographiques, réduisant le risque d'erreur de la part des utilisateurs (on ne peut pas choisir des algorithmes crypto faibles) ».
« Il est même difficile de mal le configurer. Il n’y a pas de certificats X509 ou ASN.1. Le modèle d’authentification est similaire à SSH, donc toute personne avec des bases rudimentaires d’administration système comprend facilement les concepts de WireGuard. Il y a souvent une manière évidente d’aller d’un point A à un point B, qui se trouve aussi être sûre » appuie Jason Donenfeld. C'est aussi le point de vue de Fredrik Strömberg, cofondateur du service VPN suédois Mullvad, l'un des premiers à financer et essayer le nouveau protocole.
« [WireGuard] est dogmatique cryptographiquement. Il supporte une suite et c'est tout. Ça peut sembler être une mauvaise idée, mais l'expérience nous dit le contraire. L'agilité dans le chiffrement introduit souvent une complexité inutile, qui mène inévitablement à des failles de sécurité » nous explique ce dernier. L'outil « fait partie d’une tendance plus large qui vise à rendre la cryptographie facile et utilisable, sans sacrifice en matière de sécurité ou de performances », comme Signal, ajoute Jason Donenfeld.
Un VPN dans votre noyau Linux
Un autre choix fondamental est celui d'exécuter la brique centrale de WireGuard directement dans le noyau du système, pour le moment sur Linux. De quoi assurer de meilleures performances que le vénérable OpenVPN, qui se lance dans l'espace utilisateur. Le nouvel outil promet des débits quatre fois supérieurs, pour une latence divisée par quatre.
Ce choix n'a pas que des avantages : un outil intégré au noyau peut bien plus facilement compromettre un système par rapport à une application classique, limitée aux droits utilisateur. « Le projet est écrit en C, et est potentiellement vulnérable aux mêmes failles qu'OpenVPN. Le fonctionnement dans le kernel rend n'importe quelle faille autrement plus dramatique. Ça peut améliorer les performances, mais reste très inquiétant d'un point de vue sécurité » explique ainsi Alice du service français CCrypto (qui s'appuie aujourd'hui sur OpenVPN).
« Le noyau Linux est connu pour ses failles de sécurité fréquentes. Ce n'est pas dû à un manque d'efforts ou d'audit. La sécurité du noyau est simplement difficile. Il sera toujours plus sûr d'exécuter un logiciel en espace utilisateur, mais ça ne veut pas dire qu'il est impossible d'être sûr dans le noyau » abonde Andy Yen de ProtonVPN (aussi fondé sur OpenVPN).
Réponse du concepteur de WireGuard : « La surface d’attaque de WireGuard est faible. Je préfère avoir quelque chose de court comme WireGuard dans le kernel, plutôt qu’OpenVPN qui est massif en espace utilisateur ». D'autant que l'exécution en espace utilisateur n'empêche pas l'élévation de privilèges.
Il est une nouvelle fois rejoint par Fredrik Strömberg de Mullvad : « Si quelqu'un a accès au processus de votre serveur VPN, peu importe qu'il soit en plus entré dans le noyau du système. L'attaquant peut déjà voir le trafic de vos utilisateurs. Pour cette raison, optimiser un logiciel VPN au code simple et auditable a du sens, plutôt que de s'inquiéter de le voir tourner dans le noyau ».
Du chiffrement rempli de Bruit
Pour son chiffrement, WireGuard s'appuie aussi sur une base « moderne » : Noise, notamment derrière l'application de messagerie Signal. « WireGuard reprend certaines idées des protocoles SIGMA, KEA+, Signal, et TLS 1.3 en les simplifiant » explique Jason Donenfeld, aidé de Trevor Perrin (qui dirige le projet Noise). « Nous utilisons une construction et des primitives cryptographiques modernes, restant conservatrices et stables. Ce n’est pas de la cryptographie des années 90. Les propriétés de sécurité sont plus efficaces que l’existant en tout point » appuie-t-il.
« Noise a une plus petite surface d'attaque que TLS, par exemple, mais c'est un nouveau protocole qui n'a pas encore passé l'épreuve du feu » pointe pour sa part Andy Yen de ProtonVPN. En l'utilisant comme fondation, WireGuard propose des fonctions comme l'itinérance (le maintien de la connexion en changeant d'adresse IP), la confidentialité persistante (forward secrecy), la dissimulation d'identité ou la compatibilité native avec les conteneurs.
Pour le moment, la sécurité du nouveau protocole n'a pas été auditée, même si Jason Donenfeld s'attend à pouvoir en lancer plusieurs. La cryptographie a subi une vérification formelle, pour en assurer certaines propriétés, ce que n'auraient pas connu les plus anciens protocoles. Autrement dit, le protocole est vérifié en théorie, pas encore en pratique.
Vers une distribution via la branche principale du noyau Linux
Les 4 000 lignes de code de WireGuard ont d'abord été écrites en 2015, en une journée. « J’ai attendu avant de le publier, pour m’assurer qu’il n’y avait pas d’erreur fondamentale. [...] Écrire 4 000 lignes de code n’a rien d’impressionnant. Le vrai travail a commencé avec un processus sans relâche d’écriture, de réécriture, de mise un cause, d’itération, etc. » nous déclare son concepteur.
Il reste le principal contributeur du projet, qui compte sur l'apport de quatre à cinq autres personnes. Pour le moment, l'outil supporte les noyaux Linux de 3.10 à 4.13, avec des paquets pour 15 distributions différentes, en plus d'une intégration aux firmwares de routeurs libres OpenWRT/LEDE. Cet été, deux étudiants ont participé au développement, via le Google Summer of Code et le soutien de la fondation Linux ; notamment sur une implémentation de WireGuard en espace utilisateurs écrite en Go.
Ce soutien n'est pas innocent. Le prochain jalon est l'intégration du protocole VPN à la branche « mainline » du noyau Linux, celle maintenue par Linus Torvalds, d'ici la fin de l'année. Cette validation a demandé un important travail en amont. « Quelques fonctions pratiques utilisées par WireGuard n’étaient pas dans le kernel à l’origine, telles que SipHash. L’an passé, j’ai donc ajouté petit à petit des fonctions au kernel afin de faciliter l’intégration de WireGuard par la suite » détaille Donenfeld.
D'ici la validation par l'équipe de Torvalds, WireGuard est toujours estampillé « expérimental » et publie des « snapshots », plutôt que des versions. « Dans les faits, la plupart des gens ont trouvé les snapshots extrêmement stables, et il y a déjà des déploiements massifs ; j’ai pu constater que plus de 100 000 machines étaient connectées via WireGuard » rassure son créateur. Il s'attend à une adoption massive par les services VPN une fois le tampon du « dictateur bienveillant » de Linux apposé.
Un travail à plein temps
Les ambitions sont hautes pour Donenfeld. Les services VPN interrogés se veulent plus prudents, même s'ils pointent tous la supériorité de WireGuard sur le papier. Andy Yen de ProtonVPN insiste sur le besoin d'éprouver l'outil « par le plus dur des tests : le temps », quand Alice de CCrypto estime qu'OpenVPN restera sûrement longtemps encore leur protocole principal, compatible avec les principales plateformes.
« WireGuard est pour l'instant seulement accessible aux personnes avec un minimum de compétences techniques » note ainsi Jean-Philippe Aumasson. « Il faut des logiciels clients stables et simples d'utilisation disponibles pour chaque OS que l'on veut supporter : Windows, Linux, Android, iOS, les nombreux routeurs différents... » ajoute Alice de CCrypto.
Pour y arriver, Jason Donenfeld compte faire de ce projet un travail à plein temps, notamment grâce aux dons. « Aujourd’hui, je vis de mon travail de consultant en sécurité pour différentes entreprises, de la PME à la grande entreprise internationale. À présent, j’organise mon travail afin d’avoir du temps pour le concentrer sur la cryptographie et WireGuard » répond-il. Une implémentation Windows (via un pilote réseau) est notamment envisagée, même si rien n'est prévu dans l'immédiat.
La communauté doit aussi se développer, une tâche importante pour le créateur de WireGuard. Toujours prêt à envoyer des stickers et à communiquer sur son projet, il arpentait la dernière Nuit du Hack avec le pitch de son logiciel pour convaincre de futurs utilisateurs. Même si des développeurs s'impliquent aujourd'hui, le plus dur semble encore devant l'équipe, pour convaincre les services VPN et leurs clients de passer au nouveau protocole, face à un OpenVPN devenu un standard de fait.
Face à OpenVPN, WireGuard veut devenir le Signal des connexions chiffrées
-
La simplicité avant tout, du code à la configuration
-
Un VPN dans votre noyau Linux
-
Du chiffrement rempli de Bruit
-
Vers une distribution via la branche principale du noyau Linux
-
Un travail à plein temps
Commentaires (90)
Vous devez être abonné pour pouvoir commenter.
Déjà abonné ? Se connecter
Abonnez-vousLe 05/09/2017 à 11h52
Super article, avec pas mal de références !
Bon travail, merci.
Le 05/09/2017 à 11h52
+1000.
Je me suis dit exactement la meme chose, 4000 lignes de code sur un soft neuf c’est une chose, mais d’ci 10 ans il lui faudra se mettre à niveau. Donc à moment donner il devra choisir, soit maintenir la compatibilité entre les versions, et donc augmenter la complexité et la vulnérabilité, soit casser la compatibilité et avoir simultanément des versions “neuves” fiables et des versions “anciennes” qui ne sont plus à jour qui traîneront sur le net, au risque de perdre les utilisateurs qui ne comprendront pas pourquoi leur client 4.0 tout juste téléchargée ne peut pas se connecter au serveur 3.0 de leur fournisseur. Qui lui même ne passe pas en 4.0 car ça bloquerait tous ses utilisateurs avec le client 3.0…
Et je suis assez curieux de voir si Torvald va accepter de faire tourner ça en espace noyau sur la branche principale, je n’ai pas l’impression que ça passe la balance bénéfices / risques.
Le 05/09/2017 à 12h03
Faire un installeur plus simple/clé-en-main de OpenVPN résoudrait une grosse partie du problème.
Le 05/09/2017 à 12h08
Article tres interessant, merci !
Le 05/09/2017 à 12h16
Le 05/09/2017 à 12h23
Le 05/09/2017 à 12h24
Le 05/09/2017 à 12h35
Merci pour les infos supplémentaires, ca fait un paquet d’années que j’ai plus touché à IPSec, j’étais plus très sûr :)
Le 05/09/2017 à 12h44
IPSEC tourne bien dans le noyau depuis la version 2.6, pourquoi pas celui-ci ?
Le 05/09/2017 à 12h45
“Installation
Warning: WireGuard is currently under heavy development, and therefore any installation steps here should be considered as experimental. Please do not rely on WireGuard at this stage. We are rapidly working toward a first release that we will consider secure and ready for widespread usage, but that time has not yet come.
With that said, we are very excited to have people testing, experimenting, and reporting feedback. There are two ways to install WireGuard: from the source, or, if your distribution supports it yet, from distribution packages.
The latest snapshot is v0.0.20170810.”
ça contredit un peu la phrase:
“« Dans les faits, la plupart des gens ont trouvé les snapshots extrêmement stables, et il y a déjà des déploiements massifs ; j’ai pu constater que plus de 100 000 machines étaient connectées via WireGuard » rassure son créateur.”
Le 05/09/2017 à 12h55
Ça fait très longtemps que j’ai pas installé un client openVPN sous Windows mais il y a quoi de compliqué ? de mémoire c’est un setup.exe, click click click, ok c’est installé, double click sur le fichier .ovpn, ok c’est connecté.
Le 05/09/2017 à 12h55
+1 et encore plus quand on commence à avoir des outils. La base grossi forcément. Le développeur semble un peut cracher sur l’existant et donne une impression de ne pas voir les implication que posent une généralisation d’un algorithme en solution complete. Sa base de code va grossir.
Le 05/09/2017 à 12h58
Le 05/09/2017 à 13h01
Le 05/09/2017 à 13h03
un “problème” aussi, c’est que ça passe par UDP, donc un peu compliqué de le faire passer à travers un firewall ou un proxy.
actuellement, un OpenVPN en TCP sur le port 443, passe très bien ce genre de “blocages”.
Le 05/09/2017 à 13h07
c’est un des reproches fait à IPSec, d’être dans le noyau. les mentalités en terme de crypto ont changées depuis 1995. pas sûr que Linus accepte comme ça, mais il peut aussi sauter sur l’occasion de virer IPSec pour mettre enfin un truc moderne et sécurisé.
Le 05/09/2017 à 13h09
Le 05/09/2017 à 13h16
C’est pas mutuellement exclusif : le mec couvre son derrière dans la doc pour pas se bouffer un retour de manivelle s’il arrive un pépin à qui que ce soit. C’était exactement la même chose avec les versions pré-1.0 de Firefox.
Après, les gens font ce qu’ils veulent, ça n’empêche en rien que les personnes qui l’utilisent le trouvent stable et l’aient déployé quand même - à leurs risques et périls.
Le 05/09/2017 à 13h18
…C’est exactement à ça que sert le fichier .ovpn.
Le 05/09/2017 à 13h25
Le 05/09/2017 à 13h32
J’ai installé ce we 5 fichiers .ovpn (free) de ProtonVPN sur mon RT68U. Effectivement, la config se charge, reste à valider quelques options et ça roule. Il a fallu que j’adapte leur tuto sur dd-wrt pour asuswrt-merlin. Très content de ProtonVPN free, pas de perte de débit.
Le 05/09/2017 à 13h54
Le 05/09/2017 à 14h02
derrière l’install façon fusée “click click click” en laissant tous les choix par défaut, il y a des choix, non ? " />
Le 05/09/2017 à 14h05
Parce que IPsec il y avait des années de recul qui permettaient de garantir un risque contrôlé.
Et comme le dit Minikea, les mentalités ont évolué, la tendance est désormais à mettre de moins en moins de choses dans le noyau pour favoriser la stabilité et la sécurité quitte à perdre un peu en performances, les machines d’aujourd’hui n’ayant pas de difficultés à gérer ce genre d’opérations.
Le 05/09/2017 à 14h06
OpenVPN, il faut tout de même de bonnes bases d’admin pour arriver à avoir quelque chose de fonctionnel. je me rappelle avoir galéré avec Android et la Freeboite v6, pour me rendre compte en définitive que…l’application android que j’avais installé n’était pas compatible avec l’implémentation openVPN de la Freebox >_<”
C’est exactement le genre de cas frustrant qui n’aide pas. Pour le moment, j’utilise l’outil VPN de Synology, avec leur protocole à eux dont on ne sait pas grand chose, mais à l’utilisation c’est le rêve. On installe l’appli sur son téléphone ou son PC, on se log avec les ID du routeur et en avant Guigamp.
Le 05/09/2017 à 14h24
Android utilise le kernel Linux, donc si c’est intégré dans le noyau Linux, c’est intégrable dans le noyau Android ;)
Le 05/09/2017 à 14h59
Le 05/09/2017 à 15h03
Quand on va sur leur site, on voit que les 4000 lignes sont hors primitives de crypto. J’ai vu ça dans leur doc technique.
C’est un discours commercial. Je suis sûr que l’on ne compare pas la même chose.
Le 05/09/2017 à 15h04
Je vois des coms où les gens sont content de leur service VPN. Avez-vous
fait des captures de packets voir si tout était encapsulé dans le vpn ?
j’ai testé plusieurs service où il y avait du trafic DNS hors tunnel
par exemple. Ça fait moyen " />. OpenVPN(ou le poste client) mal configuré (geoloc detection, webrtc detection, dnsleak, torrent detection etc) ça peut être bien de la merde. OpenVPN n’est pas si simple que cela les amis.
Le 05/09/2017 à 15h06
C’est parce qu’IPsec est NSA compliant qu’il est proposé en 1er choix " />
Le 05/09/2017 à 15h08
Le 05/09/2017 à 15h14
Le 05/09/2017 à 15h23
J’ai repris le texte de mon entretien avec Jason : il parlait bien de millions de lignes de code pour OpenVPN dans notre entretien original, avant de corriger lui-même pour “milliers” dans un retour postérieur.
L’article a été corrigé, désolé pour la confusion.
Le 05/09/2017 à 15h24
Un peu relou cet amalgame vpn / proxy…
Le 05/09/2017 à 15h38
Le 05/09/2017 à 15h41
Comment ça ?
Le 05/09/2017 à 15h46
Le 05/09/2017 à 15h47
Le retour (sur la traduction de notre entretien) date d’avant l’article pour être précis, l’erreur est bien la mienne sur ce coup. " />
Le 05/09/2017 à 16h00
Le 05/09/2017 à 16h06
Le 05/09/2017 à 16h07
Bien résumé.
Mais à la relecture il n’y a rien de si aggressif dans son propos à en être outré.
Je pense que le seul truc qui nous a fait tous lever un sourcil c’est le “mon code ne fait que 4000 lignes il mérite plus d’être inclus dans le noyaux”.
Le 05/09/2017 à 16h08
Le 05/09/2017 à 16h10
Merci pour le travail fourni. Cet article est super !
“j’ai pu constater que plus de 100 000 machines étaient connectées via WireGuard”
Je me demande comment il peut savoir combien de gens l’utilise ? Si je l’installe, il le sait ? Comment ? Il y a un mouchard ?
En tout cas j’ai hâte d’une solution aussi fonctionnelle (à l’usage) qu’OpenVPN mais sans les galères de configuration coté serveur.
Le 05/09/2017 à 16h10
Yep je confirme, en loadbalancing Nginx est devenue l’autorité mais souffre encore de quelques problématiques de jeunesse pour l’exploit prod (mais bon apache a bien d’autres défauts " />)
Le 05/09/2017 à 16h11
Le 05/09/2017 à 16h13
Le 05/09/2017 à 16h13
Le 05/09/2017 à 16h15
J’ai déja tapé 4000 lignes en une journée, mais c’était parce que je m’étais endormis sur mon clavier " />
Puis bon, de nos jours les développeurs google-copier-coller, cela pond vite une encyclopédie (obvious troll is obvious)
Le 05/09/2017 à 16h21
YouTubeRhooooo ! " />
Le 05/09/2017 à 16h21
Le 05/09/2017 à 16h34
Le 05/09/2017 à 16h43
Un exemple parmi plusieurs: la relation avec PHP est (était?) pointue à configurer pour avoir quelque chose de stable (HTTP 502 Bad Gateway ) dans quelques situations là où un simple apache mod_php faisait son taff sans rien demander. Ou encore quelques options de rewrite qui demandaient des tricks pour être efficaces ET maintenables.
Mais on compare en effet des projets avec une maturité complètement différente, mais c’est bien notre commentaire quand quelqu’un se vente de n’avoir que 4000 lignes de code " />
Le 05/09/2017 à 16h54
Le 05/09/2017 à 16h58
Nan c’est qu’il ventile pour ne rien dire. C’est comme ca que l’on créé la clim dans nos bureaux: tu met d’un coté ceux qui te pompent l’air et de l’autre ceux qui brassent. Ca ventile bien en été.
(oui oui, complète faute sans relecture, je blame mes lunettes elles étaient à l’envers juste pour ce caractère)
Le 05/09/2017 à 17h04
Mais quelle compatibilité ? Pourquoi on introduirait des incompatibilités ? La démarche de simplicité ici devrait l’éviter, en choisissant dès le début une conception solide.
Simple. Le système décrit ici ne propose qu’un seul algorithme de chiffrement. Au fur et à mesure que le temps passe, la probabilité que celui-ci soit considéré comme non sûr (soit parce que des attaques sont trouvées, soit parce que la puissance des machines augmentant il devient cassable en un temps raisonnable) se rapproche de 1.
Donc à moment donné il faudra passer sur un nouvel algorithme. Dans ce cas soit on impose la mise à jour pour tous, avec les problèmes que j’ai cités plus haut, soit on conserve une option de rétrocompatibilité avec l’ancien algorithme, ce qui du coup complexifie le code (2 algos à gérer) et permet à l’utilisateur de rester sur une version moins robuste du chiffrement (mais qui suffit pour 98% des utilisateurs vu le ratio investissement / gain pour casser les algos pendant de nombreuses années après qu’ils soient considérés comme désuet). C’est le second choix qui a toujours été fait par les solutions largement diffusées (il n’y a qu’à voir la durée de vie de TLS 1.0 et 1.1 dans les navigateurs…). Du coup les anciens protocoles coexistent généralement plusieurs années avec les nouveaux le temps que tout soit mis à jour tant côté client que serveur, le protocole commun le plus sécurisé entre le client et le serveur étant alors utilisé pour les communications…
Le 05/09/2017 à 17h05
Merci :)
Le 05/09/2017 à 17h14
Le 05/09/2017 à 17h22
Le 05/09/2017 à 19h54
OMG il y a des gens qui se souviennent de l’existence de l’ASN1 ! " />
Le 05/09/2017 à 21h48
Il a dit qu’il était reparti de code existant (dont il est l’auteur) pour pondre ces 4000 lignes. En gros il a modifié un exploit de son cru pour transformer ça en VPN. Donc la possibilité de pondre le PoC en un aprèm est clairement plausible.
C’est le même gars qui a pondu photofloat (gallerie web photo sympatoche) et password-store (gestionnaire de mots de passe). Il a sa propre boîte de consulting en sécurité donc c’est pas non plus un ptit jeune qui sort de l’école qui réinvent la roue pour le faire.
Sa démarche est plutôt bonne et pour l’instant dans le milieu globalement tout le monde s’accorde à dire qu’à première wireguard est bien conçu. Et surtout il évite la connerie d’inventer sa crypto.
Il faut bien voir qu’openvpn est aussi massif car il se repose sur x509 qui est une monstruosité pas possible. Dans son cas, autant que possible il utilise ce qui existe déjà ailleurs dans le kernel ou au pire pousse l’implémentation de ce qu’il manque. Du coup la partie réellement spécifique à wireguard reste concise. C’est pour cela qu’il y a de fortes chances que la wireguard persiste à avoir une codebase assez peu étendue.
Le 06/09/2017 à 06h11
Depuis quelque années, dès qu’on parle de VPN, on parle de leur utilisation comme proxy d’accès internet. Alors que ce n’est qu’un usage détourné.
C’est d’autant plus relou quand on cherche des infos sur la création d’un VPN, et qu’on trouve que des threads sur cet usage alternatif…
Le 06/09/2017 à 07h37
Le 06/09/2017 à 08h10
selon clock sur le git actuel:
openvpn : 82642
openvpn-gui : 14417
il y a d’autres dépendances mais qui ne semblent pas spécifiques à openvpn donc je les ajoute pas.
Le 06/09/2017 à 10h22
Le 05/09/2017 à 09h48
Je regarderai ça plus en détail une fois que ce sera porté sur openbsd.
Le 05/09/2017 à 09h49
SoftEther FTW!
Le 05/09/2017 à 09h51
Merci pour ce super article !
Le 05/09/2017 à 09h52
" />
Mais bon, en sécurité, la confiance se construit lentement. Il va devoir être patient…
Le 05/09/2017 à 09h53
Le 05/09/2017 à 09h54
Wait and see. Pour l’instant il va falloir que des chercheurs se penchent dessus pour trouver des vulnérabilités. Après on pourra commencer à songer envisager la possibilité de sa mise en place en production.
Le 05/09/2017 à 10h10
OpenVPN, conçu il y a plus de 15 ans
C’est bien l’interet d’openvpn : c’est un “vieux” protocole qui a fait ses preuves.
Après, une solution de vpn linux only c’est bien joli, mais ca ne sert pas à grand chose.
Et dans le monde pro, de toutes facons, ca utilise (malheureusement) pratiquement qu’IPSec, openvpn ne perçant pas vraiment.
Simple exemple : si vous voulez monter un vpn avec AWS ou Google Cloud, c’est IPsec qui est proposé, pas openvpn.
Le 05/09/2017 à 10h17
Le 05/09/2017 à 10h24
Miam, hâte de voir ce que ça va donner!
Le 05/09/2017 à 10h29
Amusant qu’une dénommée Alice bosse dans une boite utilisant la crypto. " />
Le 05/09/2017 à 10h29
J’ai demandé un nom complet, il m’a été répété, donc je prends (aussi) ce nom/pseudo pour une référence. :)
Le 05/09/2017 à 10h30
" />
Le 05/09/2017 à 10h50
Le 05/09/2017 à 10h52
Intéressant.
Les bases me paraissent saines (du code simple et pas long, par exemple) et la démarche n’a rien de farfelu. Potentiellement, un outil qui a de bonnes chances de devenir une référence en la matière.
Après, j’attends de voir ce que ça va donner sur le terrain, car c’est là que se fera la différence au final. À suivre !
Le 05/09/2017 à 11h30
Pour se connecter chez un gros provider, c’est IPSec qui est utilisé parce que ca permet entre autre de s’affranchir de soucis tel que l’adressage réseau qui serait le même aux deux bouts. (J’ai pas relu mes notes, j’espère ne pas dire de bétises)
Mais OpenVPN est encore largement utilisé pour sa simplicité de configuration et d’utilisation, notamment pour les employés en remote
Le 05/09/2017 à 11h36
Si on pouvait avoir l’intégration dans le kernel Android ce serait top.
Le 05/09/2017 à 11h38
Le 05/09/2017 à 11h45
C’est intéressant.
Mais je trouve la communication un peu agressive quand même.
C’est facile de critiquer un projet de 15 en vantant la simplicité d’un nouveau projet.
Mais je suis quand même curieux de voir ce que vont donner les 4000 lignes actuelles après quelques années.
La sécurité en informatique est un sujet en perpétuel mouvement, il va falloir s’adapter. Dans cette adaptation il va falloir faire des choix entre le maintien de la compatibilité avec les anciennes versions et la mise à jour à tout prix, dans un cas le code en prend un coup, dans l’autre cas c’est la simplicité pour les utilisateurs. ce qui est sur c’est que la ligne de simplicité maximale n’est pas tenable à long terme. je suis convaincu que les millions de lignes d’openvpn ne sont pas là par le simple plaisir des développeurs.
Le gros avantage que je vois à ce type d’initiatives, c’est que ça peut aider des projets historiques à se remettre en question, et du coup ça fait bouger tout le monde dans une direction valorisante.
Le 05/09/2017 à 11h49
c’est surtout qu’IPSec est un “standard” et donc on peut avoir un client d’une marque A en face d’un client d’une marque B (bon il y a des incompatibilités mais pas tant que ça) alors que pour openVPN, c’est “forcément” un client openVPN en face d’un serveur openVPN.
En plus sur les routeurs, il n’y a jamais openVPN donc je pense que c’est la raison pour laquelle les accès aux clouds en crypté se font derrière IPSec (qui marchera pour les routeurs et les serveurs) et non openVPN / Wireguard (serveur only).
Après je trouve WireGuard intéressant et je vais garder un oeil dessus
Le 06/09/2017 à 10h25
Le 06/09/2017 à 10h25
Le 06/09/2017 à 10h28
pour info, SoftEther est à 330572 lignes de code.
Le 06/09/2017 à 11h26
Oui pardon, j’ai simplifié, je parle des deux (le chiffrement + le protocole d’échange). Mais ça revient au même. D’ailleurs on peut même séparer aussi les protcoles / chiffrements utilizes pour l’authentification de ceux utilisés pour l’échange des données.
Le 06/09/2017 à 11h48
Blague à part, on en trouve encore un peu partout 30 ans après, c’est loin d’être un truc moribond. Et pourtant la dernière fois que je m’étais penché sur la question il y avait bien peu d’outils libres permettant de le décoder sans trop galérer.
Le 06/09/2017 à 11h51
Le 06/09/2017 à 12h08
la totalité du code source tel qu’ils le délivrent : serveur, client, librairies, manager… je suis pas sûr qu’il y ai une GUI dedans, juste les outils en ligne de commande.