Face à OpenVPN, WireGuard veut devenir le Signal des connexions chiffrées

Face à OpenVPN, WireGuard veut devenir le Signal des connexions chiffrées

Chiffrement et stickers

Avatar de l'auteur
Guénaël Pépin

Publié dans

Internet

05/09/2017 10 minutes
90

Face à OpenVPN, WireGuard veut devenir le Signal des connexions chiffrées

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.

Écrit par Guénaël Pépin

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

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

next n'a pas de brief le week-end

Le Brief ne travaille pas le week-end.
C'est dur, mais c'est comme ça.
Allez donc dans une forêt lointaine,
Éloignez-vous de ce clavier pour une fois !

Fermer

Commentaires (90)


Je regarderai ça plus en détail une fois que ce sera porté sur openbsd.


SoftEther FTW!


Merci pour ce super article !


<img data-src=" />



Mais bon, en sécurité, la confiance se construit lentement. Il va devoir être patient…








Nargas a écrit :



Merci pour ce super article !





+1



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.


OpenVPN, conçu il y a plus de 15 ans



&nbsp;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.








euclide816 a écrit :



Après, une solution de vpn linux only c’est bien joli, mais ca ne sert pas à grand chose.&nbsp;





&nbsp;Dans la news :

&nbsp;

Client :

“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…”



Serveur :

“Une implémentation Windows (via un pilote réseau) est&nbsp;notamment envisagée, même si rien n’est prévu dans l’immédiat.”





Sinon intéressant ce VPN, à surveiller. Je me fie à l’avis de&nbsp;Jean-Philippe Aumasson.



Miam, hâte de voir ce que ça va donner!


Amusant qu’une dénommée Alice bosse dans une boite utilisant la crypto. <img data-src=" />


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. :)


<img data-src=" />








Jonath a écrit :



SoftEther FTW!





C’est clair mais c’est pas le sujet <img data-src=" /> <img data-src=" />



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 !


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


Si on pouvait avoir l’intégration dans le kernel Android ce serait top.








PtiDidi a écrit :



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)





Nan ça ne permet pas de s’affranchir du souci. Ça permet, vu que ce sont les routeurs qui sont IPSec, d’effectuer les bonnes règles de translation d’adresse pour gérer le-dit souci. Ça reste une belle merde comme cas.



C’est intéressant.&nbsp;

Mais je trouve la communication un peu agressive quand même.&nbsp;

C’est facile de critiquer un projet de 15 en vantant la simplicité d’un nouveau projet.&nbsp;

Mais je suis quand même curieux de voir ce que vont donner les 4000 lignes actuelles après quelques années.&nbsp;

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.&nbsp;



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.&nbsp;


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.



&nbsp;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


Super article, avec pas mal de références !

Bon travail, merci.


+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.


Faire un installeur plus simple/clé-en-main de OpenVPN résoudrait une grosse partie du problème.


Article tres interessant, merci !








Poppu78 a écrit :



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.





pas sûr non plus…









KP2 a écrit :



<img data-src=" />



Mais bon, en sécurité, la confiance se construit lentement. Il va devoir être patient…







Mouais… Quand tu vois à la vitesse ou le trou de sécurité géant qu’est Systemd à été adopté, j’ai comme un doute.

Mais d’expérience, plus un système est simple, plus il est solide et fiable. Sinon je suis d’accord avec toi, d’ici un ou deux ans on y verra plus clair.









euclide816 a écrit :



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.







+1. Openvpn est trop sécurisé pour Google et AWS.<img data-src=" />



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 :)


IPSEC tourne bien dans le noyau depuis la version 2.6, pourquoi pas celui-ci ?


“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.”


Ç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é.

&nbsp;


+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.








neves a écrit :



Ç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é.



Et il se configure tout seul magiquement?









sdesbure a écrit :



alors que pour openVPN, c’est “forcément” un client openVPN en face d’un serveur openVPN.







Perdu, mon accès de secours à la maison, c’est d’utiliser le protocole d’OpenVPN avec SoftEther sur une zone SmartOS (j’aime me faire chier <img data-src=" />) et Pritunl sur mon Mac (mon accès principal étant un serveur SoftEther avec IPSec sur une RPi).



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”.


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é.








Patch a écrit :



Et il se configure tout seul magiquement?





<img data-src=" />



Tu connais quelque chose qui se configure tout seul magiquement ?

&nbsp;

On parle de la facilité d’utilisation pour un utilisateur lambda (ici le ““client”” openVPN), bien sûr qu’il y aura toujours derrière le travail d’un administrateur pour installer le serveur et générer les certificats… qu’il mettra dans le fichier .ovpn pour que l’utilisateur n’ai plus qu’à cliquer dessus, magiquement.



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.


…C’est exactement à ça que sert le fichier .ovpn.








sebp a écrit :



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.











Poppu78 a écrit :



+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.







Merci pour vos retours.



<img data-src=" /><img data-src=" /><img data-src=" /><img data-src=" /><img data-src=" />



C’est aussi mon avis, à la réflexion. En 2/3/5/plus d’années d’utilisation, il risque fort de se retrouver bloaté, ce code.



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.








neves a écrit :



Ç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é.







Je n’en sais rien mais c’est un des arguments du développeur en faveur de son bébé: “Il est difficile de mal configurer wireguard et impossible de choisir des algos de crypto faibles”.



Donc, en créant un installeur qui facilite (ou impose) la configuration de openVPN, ca supprime un des arguments du développeur.



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 ? <img data-src=" />


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.


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 &gt;_&lt;”

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.


Android utilise le kernel Linux, donc si c’est intégré dans le noyau Linux, c’est intégrable dans le noyau Android ;)








fred42 a écrit :



Amusant qu’une dénommée Alice bosse dans une boite utilisant la crypto. <img data-src=" />





Je m’étais fait la remarque aussi :-) .







Gnppn a écrit :



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. :)





J’ai un gros doute sur cette phrase de l’article : “moins de 4 000 lignes, contre plusieurs millions pour OpenVPN”

Pour le chiffre de “plusieurs millions”, il n’y a pas d’erreur ? Ça me paraît gigantesque.



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.


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 <img data-src=" />. 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.


C’est parce qu’IPsec est NSA compliant qu’il est proposé en 1er choix <img data-src=" />








sebp a écrit :



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.





Je me demande si le chiffre de “millions” est exact, ça me paraît gigantesque pour un tel projet. Ou alors ça doit crouler sous du code conditionnel, au moins. Il est vrai qu’un nettoyage de grande ampleur est une tâche ardue et peu gratifiante dans un tel cas.



Je suis d’accord que le code va grossir un peu, mais je pense que tu loupes un point : il s’agit justement de faire simple et robuste, sans plein d’options, pour que le code rester maîtrisé et maîtrisable. Il y aura peut-être des corrections pour améliorer la sécurité, mais de la à dire que le code va forcément beaucoup changer parce que la sécurité évolue, je n’en suis pas aussi sûr : est-ce que le code de SSH a tant changé depuis 15 ans ? Il ne me semble pas, en tous cas les principes restent les mêmes.



[màj] le code de qmail (de Bernstein) consiste en un coeur de 500 à 1000 lignes qui n’a quasiment jamais changé depuis sa création, il y a bien une quinzaine d’années.







Poppu78 a écrit :



+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





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.







Sheepux a écrit :



+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.











Commentaire_supprime a écrit :



Merci pour vos retours.

C’est aussi mon avis, à la réflexion. En 2/3/5/plus d’années d’utilisation, il risque fort de se retrouver bloaté enflé/obèse, ce code.





<img data-src=" />

Pourquoi il se retrouverait enflé ? Heureusement, tout code issu d’une conception saine et bien rédigé n’est pas condamné à devenir énorme et peu compréhensible.

NB : j’ai fait du développement pendant des années, et un peu de maintenance aussi.









fred42 a écrit :



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.





Je pense que c’est une bonne idée de ne pas compter la bibliothèque de cryptographie, d’ailleurs c’est la partie facile et déjà connue du système (je parle des algorithmes de chiffrement), et pas la plus grosse puisqu’il ne s’agit pas d’algorithme compliqués.

La difficulté de développer une bonne alternative à OpenVPN est dans tout ce qui est autour, il me semble.



Quant aux millions de lignes de code pour OpenVPN, je me demande comment ils arrivent à un nombre aussi énorme, c’est la taille d’un noyau Linux d’il y a quelques années (surtout si on met de côté les autres archis que x86 et les drivers en pagaille), ou de X11/Xorg.



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.



&nbsp;L’article a été corrigé, désolé pour la confusion.


Un peu relou cet amalgame vpn / proxy…








Gnppn a écrit :



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.





<img data-src=" />

Merci pour la correction et aussi pour ce commentaire me la signalant. <img data-src=" />

(ce chiffre me paraissait énorme donc :-) ).



Comment ça ?








sebp a écrit :



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.









Poppu78 a écrit :



+1000.

Je me suis dit exactement la meme chose, 4000 lignes de code sur un soft neuf c’est une chose, mais









Sheepux a écrit :



+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









Commentaire_supprime a écrit :



C’est aussi mon avis, à la réflexion. En 2/3/5/plus d’années d’utilisation, il risque fort de se retrouver bloaté, ce code.





Simplement pour vous signaler le commentaire de Guénaël en #52, qui a corrigé l’article suite à un retour de l’auteur du logiciel, il n’y a plus les “millions” de lignes.



NB : j’ai fait des recherches via Google, mais j’ai l’impression qu’il faudrait télécharger le code source et faire un “wc” dessus pour avoir la réponse du nombre de lignes de code.



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.&nbsp;<img data-src=" />








OlivierJ a écrit :



Je me demande si le chiffre de “millions” est exact, ça me paraît gigantesque pour un tel projet. Ou alors ça doit crouler sous du code conditionnel, au moins. Il est vrai qu’un nettoyage de grande ampleur est une tâche ardue et peu gratifiante dans un tel cas.



Je suis d’accord que le code va grossir un peu, mais je pense que tu loupes un point : il s’agit justement de faire simple et robuste, sans plein d’options, pour que le code rester maîtrisé et maîtrisable. Il y aura peut-être des corrections pour améliorer la sécurité, mais de la à dire que le code va forcément beaucoup changer parce que la sécurité évolue, je n’en suis pas aussi sûr : est-ce que le code de SSH a tant changé depuis 15 ans ? Il ne me semble pas, en tous cas les principes restent les mêmes.



[màj] le code de qmail (de Bernstein) consiste en un coeur de 500 à 1000 lignes qui n’a quasiment jamais changé depuis sa création, il y a bien une quinzaine d’années.





Pas de soucis pour que l’outil soit simple dans son design. mais je doute quand même qu’openvpn ait été compliqué par volonté. je pense que cette complexité est surtout le fruit de son évolution qui a vu ajouter fonctionnalités et corrections diverses, qui multiplient par l’ajout de plateformes et de volonté de retrocompatibilité.&nbsp;



Même si&nbsp;WireGuard est simple par design, le cycle de vie de son développement va devoir prendre en compte beaucoup de choses pour que cette simplicité soit maintenue à long terme. Dans la comparaison avec Qmail, tu oublies que qmail est une “simple” implémentation côté serveur d’un protocole qui n’a que très peu bougé depuis les 20 dernières années.&nbsp;

Wireguard va devoir prendre en compte le serveur certes, mais aussi d’éventuelles failles dans le protocole même et surtout l’effervescence du côté client et son inévitable fragmentation.&nbsp;



Alors certes les choses peuvent se limiter par la non prolifération des options et des bonnes pratiques, mais j’ai du mal à croire que le projet sera toujours aussi propre dans 15 ans.&nbsp;



Maintenant que les choses soient claires, je n’ai rien contre le projet et je pense que un nouvel acteur est excellent pour la concurrence, au même titre que les meilleures améliorations de Firefox ces dernières années sont issues de la concurrence avec Chrome.&nbsp;

Simplement je trouve la communication de Wireguard un peu trop aggressive, et trop basée sur la comparaison dénigrante, ce que je trouve assez malsain.&nbsp;









&nbsp;









Gnppn a écrit :



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.





Ha ok merci. Des millions, ça me parraissait beaucoup aussi, mais j’allais pas vérifier non plus.



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”.








sebp a écrit :



Maintenant que les choses soient claires, je n’ai rien contre le projet et je pense que un nouvel acteur est excellent pour la concurrence, au même titre que les meilleures améliorations de Firefox ces dernières années sont issues de la concurrence avec Chrome.





Idem avec Nginx qui a mis un gros coup de pied aux fesses d’Apache.<img data-src=" />



Merci pour le travail fourni. Cet article est super !



“j’ai pu constater que plus de 100&nbsp;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 ?

&nbsp;

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.









Patch a écrit :



Et il se configure tout seul magiquement?&nbsp;





&nbsp;Oui.



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 <img data-src=" />)








Sheepux a écrit :



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”.





Moi ce qui m’a fait sourire, c’est ces fameuses 4000 lignes écrites en 1 journée. Le type à dû être touché par la grace divine.<img data-src=" />









Sheepux a écrit :



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”.





C’est peut être une mauvaise interprétation de ma part :)

C’est le sentiment que j’ai eu en lisant l’article, mais effectivement ce n’est peut être pas si agressif que je ne l’ai ressenti en première lecture.&nbsp;









sebp a écrit :



Simplement je trouve la communication de Wireguard un peu trop aggressive, et trop basée sur la comparaison dénigrante, ce que je trouve assez malsain.





Ça ne me pose aucun problème de lire la critique d’OpenVPN qui a été faite.

Tu vas pouvoir bondir en lisant l’autre article (plus récent) de Guénaël sur la question des VPN <img data-src=" />





« Historiquement, les tentatives de tunnels sécurisés ont été nombreuses, comme OpenVPN et IPsec, qui sont deux désastres, chacun à sa manière » tacle Jason Donenfeld. IPsec, dont la conception remonte au milieu des années 90, pâtirait notamment du manque de mises à jour des terminaux, laissant des vulnérabilités dans la nature, selon le créateur de WireGuard.



« Un problème commun à ces deux projets est leur taille massive. Ce sont des milliers de lignes de code, extrêmement complexes, illisibles, et impossibles à appréhender dans leur totalité » estime-t-il. Pour lui, même si un chercheur passe des semaines à lire le code, il ne trouvera pas toutes les vulnérabilités.




J’ai déja tapé 4000 lignes en une journée, mais c’était parce que je m’étais endormis sur mon clavier <img data-src=" />



Puis bon, de nos jours les développeurs google-copier-coller, cela pond vite une encyclopédie (obvious troll is obvious)









sebp a écrit :



C’est peut être une mauvaise interprétation de ma part :)

C’est le sentiment que j’ai eu en lisant l’article, mais effectivement ce n’est peut être pas si agressif que je ne l’ai ressenti en première lecture.





J’ai eu la même impression. Il faut que l’on arrête la lecture en diagonale :)









OlivierJ a écrit :



Ça ne me pose aucun problème de lire la critique d’OpenVPN qui a été faite.

Tu vas pouvoir bondir en lisant l’autre article (plus récent) de Guénaël sur la question des VPN <img data-src=" />





<img data-src=" />

&nbsp;Je maintiens quand même que je ne suis pas fan de la forme.&nbsp;

Sur le fond il est évident que les solutions historiques ont leurs défauts. Mais utiliser les défauts des autres pour montrer que sa propre solution est mieux n’est pas le meilleur moyen de me convaincre pour ma part ;)









Sheepux a écrit :



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 <img data-src=" />)





A part que Nginx n’est plus bien jeune à l’échelle informatique :-) , à quels problèmes tu penses ?



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 <img data-src=" />








Sheepux a écrit :



quand quelqu’un se vente de n’avoir que 4000 lignes de code <img data-src=" />





Tu veux dire qu’il a dit n’avoir que 4000 lignes tout en utilisant un éventail ?

<img data-src=" />



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)




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…


Merci :)








neves a écrit :



Ç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é.





<img data-src=" /> Trois clic plus le double, ça fait cinq clic et s’est bien trop pour certains. <img data-src=" />









Poppu78 a écrit :



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…





Effectivement, le cas d’un seul algo est un plus (AMHA), pour la rétrocompatibilité, il n’y a malheureusement pas trop le choix, mais implanter un nouvel algo sera toujours plus simple que d’en maintenir certains complètements dépassés et troués depuis 10 ans. On peut imaginer garder un algo un peu vieux tant qu’il n’est pas troué le temps que le nouveau soit massivement adopté.

Dans le cas de TLS 1.0 et 1.1, c’est aux admins sys de les enlever de leurs sites. Les navigateurs ne font que les maintenir parce qu’ils sont un moindre mal. D’ailleurs Google va les virer de Chrome bientôt il me semble ?



OMG il y a des gens qui se souviennent de l’existence de l’ASN1 ! <img data-src=" />


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 &nbsp;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.


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…








lateo a écrit :



OMG il y a des gens qui se souviennent de l’existence de l’ASN1 ! <img data-src=" />







Moi aussi je m’en souviens, mais il y a du mieux: je ne me réveille plus la nuit en sueur en y pensant.

+1 pour le <img data-src=" />



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.








Poppu78 a écrit :



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)





En fait, un algorithme de chiffrement c’est la partie facile, c’est essentiellement quelques fonctions (chiffrer, déchiffrer) qui implémentent l’algorithme. C’est très facile d’ajouter un ou plusieurs algorithmes, tout comme on ajouterait un algorithme de compression.

Ce n’est pas ça qui fait qu’OpenVPN serait complètement enflé.







Poppu78 a écrit :



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…





Mais là il s’agit de protocoles, c’est plus compliqué à mettre au point (y compris sans failles dans le code) et à changer il me semble qu’un simple algo de chiffrement.









lateo a écrit :



OMG il y a des gens qui se souviennent de l’existence de l’ASN1 ! <img data-src=" />









levhieu a écrit :



Moi aussi je m’en souviens, mais il y a du mieux: je ne me réveille plus la nuit en sueur en y pensant.

+1 pour le <img data-src=" />





Idem, j’ai vu ça lors de prototype de piles de communication pour l’aéronautique vers 1999.

Avec le codage binaire c’était beau, et j’avais une collègue qui savait quasiment le déchiffrer à vue (chapeau).









Minikea a écrit :



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.





Merci pour cette recherche.

Effectivement, on est loin des millions, mais ça commence à faire pour du VPN.



pour info, SoftEther est à 330572 lignes de code.


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.




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.









OlivierJ a écrit :



Idem, j’ai vu ça lors de prototype de piles de communication pour l’aéronautique vers 1999.

Avec le codage binaire c’était beau, et j’avais une collègue qui savait quasiment le déchiffrer à vue (chapeau).







T’as fréquenté des Aliens toi aussi ? <img data-src=" />









Minikea a écrit :



pour info, SoftEther est à 330572 lignes de code.





Ca ne rigole pas…

Bon j’ai vu que ça faisait pas mal de choses, sur pas mal d’OS, ça ne doit pas aider ; et ces 330 kloc doivent aussi inclure les interfaces graphiques je suppose.



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.









l’archive a écrit :



% ls v4.22-9634/src

bin BuildUtil configure hamcorebuilder Neo See THIRD_PARTY.TXT vpnbridge vpncmgr vpnsetup Wfp

BuildAll.cmd BUILD_WINDOWS.TXT CurrentBuild.txt LICENSE.TXT Neo6 SeeDll VGate vpnclient vpndrvinst vpnsmgr

BuildFiles Cedar GlobalConst.h makefiles PenCore SeLow vpn16 vpncmd vpninstall vpnweb

BUILD_UNIX.TXT ChangeLog.txt Ham Mayaqua README.TXT SEVPN.sln vpnbrand vpncmdsys vpnserver WARNING.TXT







si on devait comparer, je dirais que ça correspond à openvpn sans le GUI mais avec les dépendances optionnelles