ereOn a écrit 23 commentaires

Tant que le démon (ou le service) Freelan tourne, il essaye périodiquement de se connecter à tous les hôtes qui figurent dans sa configuration. Si le canal tombe (coupure wifi par exemple, ou autre) et que la coupure dure, la session est invalidée et un ré-établissement se fera automatiquement après un court délai.

Une micro-coupure n'entraîne pas de perte de session (le protocole est tolérant aux pertes).

C'est tout à fait crédible je pense.

Ça mérite évidemment une discussion plus poussée pour spécifier la chose mais c'est une très bonne idée je trouve.

Je vais me renseigner sur les DHT et les bibliothèques utilisables dès que j'en aurai fini avec les tutoriaux de configuration que tout le monde me demande ;)

J'aime assez ton idée ;)

Pour avoir un VPN par application, il faut juste avoir à l'esprit que ça va impliquer que les applications :

1. Tournent avec les droits administrateurs (indispensable pour créer une interface virtuelle)
2. Aient chacune une interface virtuelle (là ça risque d'être un peu plus chaud, parce que je ne suis pas sûr qu'un utilisateur accepte de se retrouver avec plus de dix cartes réseaux (surtout sous Windows), même virtuelles).

Par contre, on peut tout à fait utiliser le protocole freelan sans le lier à une interface virtuelle (comme un simple canal de communication authentifié et chiffré) et ça ce n'est pas sujet aux deux points bloquants que j'ai énoncé plus haut !

Tu as parfaitement raison.

C'est mis à jour :)

Merci !

C'est une excellente idée je trouve.

Ce serait une bonne chose qu'on en discute aussi avec les autres développeurs (genre sur la mailing-list) afin qu'on tire partie de "l'intelligence collective" et qu'on voit comment on peut intégrer ça. N'hésite pas à t'y inscrire (tu peux t'en désinscrire très facilement au besoin, donc pas de craintes d'être spammé à ce niveau là ⁾

En tout cas le fait de ne pas avoir d'alternative à la saisie manuelle des contacts m'a toujours dérangé, et ta solution me semble très intéressante.

Oui, tout à fait.

C'était même un des premiers tests ;)

Le réseau virtuel créé ne peut quasiment pas être distingué d'un réseau réel donc tout ce que tu pourrais faire en "vrai", tu peux le faire au travers d'un réseau freelan.

Je dois admettre que je suis assez partagé moi aussi sur le fait d'installer directement des choses dans /usr/local.

Note par contre que tu souhaites isoles les fichiers de développement de freelan (pour pouvoir par exemple tout virer d'un coup au besoin ;)), tu peux :

1. Installer les build-tools ailleurs et simplement régler ton PYTHONPATH pour qu'il pointe vers cet "ailleurs"
2. Valoriser les différentes variables d'environnement décrites ici pour que les installations des bibliothèques freelan se fassent où tu le souhaites :)
3. Tu n'as plus après qu'à régler ton LIBRARY_PATH et ton LD_LIBRARY_PATH pour que ça fonctionne.

N'hésite pas à t'inscrire sur la mailing list des développeurs si tu rencontres des soucis ou a des questions à propos des bibliothèques !

Nous souhaitions ne pas être tributaires des décisions du créateur d'OpenVPN concernant la conception du protocole : nous avions un objectif de sécurité assez précis et, même si on peut faire confiance à OpenVPN, le protocole que nous avons choisi d'implémenter diffère sur quelques aspects.

De plus, si OpenVPN change son protocole sans nous avertir (ce qui est probable), nous risquons de nous retrouver avec un projet incompatible de toute façon. ;)

Merci :)

D'après ton erreur, tu n'as pas installé les "build tools" sur ton système (il ne trouve donc pas le module Python).

Si tu vas dans le sous-répertoire build-tools, le README devrait expliquer comment procéder.

En gros, il faut, dans l'ordre :

1. Installer les build tools
2. Compiler et installer la libcryptoplus ("scons && scons install")
3. Compiler et installer la libasiotap ("scons && scons install")
4. Compiler et installer la libfscp ("scons && scons install")
5. Compiler et installer la libfreelan ("scons && scons install")
6. Compiler et installer freelan ("scons && scons install")

N'hésite pas à contacter la mailing list des développeurs si tu rencontres d'autres soucis. Les informations pour s'y inscrire sont là : http://www.freelan.org/page/contact

J'ai bien regardé les caractéristiques de n2n, et voici les remarques que j'ai à son sujet:

Nous trouvons sur la page du site n2n, dit très loyalement :

n2n 1.x has been designed to be simple and used in private n2n networks. We’re aware that it has some security limitations such as
Keys on the command line are a problem.

Sous FreeLAN les clefs symétriques, de chiffrement [AES256-CBC] et de scellement [HMAC-SHA256-128], sont générées aléatoirement (tant que faire se peut) puis échangées avec les clefs asymétriques, de chiffrement [RSAES-OAEP] et de signature [RSASSA-PSS], des utilisateurs.

Lack of nonces in encryption makes it relatively easy to perform replay attacks.

FreeLAN utilise le mode d’opération CBC, avec un vecteur d’initialisation imprédictible [NIST SP 800-38A]. Plus que le rejeu, cela prévient surtout de décryptages parfois spectaculaires.

Lack of HMAC makes man in the middle relatively easy. (I don’t think this is a valid criticism as n2n is not trying to attach trust to a connection, just opacity).

Comme dit, avoir une conversion privée c’est bien, mais avec la bonne personne c’est encore mieux, FreeLAN chiffre ET scelle les données transmises. Cette « signature symétrique » permet par ailleurs d’éliminer au plus tôt les cryptogrammes invalides, avant même leur déchiffrement, améliorant notablement la résistance aux attaques par déni de service, par canal auxiliaire, par exploitation de bogue etc.

Difficulty in rolling keys and integrating secure key exchange protocols.

Les clefs symétriques de FreeLAN sont automatiquement renouvelées bien avant que leur usure cryptographique théorique soit atteinte.

Tout ceci a un prix, c'est une plus grande complexité de la configuration. Mais c'est bien d'avoir le choix non ?! :)

Le port d'écoute du service est spécifié grace à l'option listen_on:

# The endpoint to listen on.
#
# The endpoint can be in both numeric and hostname format, and must always
# contain a port specification.
#
# Hostnames are resolved using the method specified by
# network.hostname_resolution_protocol.
#
# Using a numeric value is recommended.
#
# Example values: 0.0.0.0:12000, [::]:12000, localhost:12000, 10.0.0.1:12000
# Default: 0.0.0.0:12000
listen_on=0.0.0.0:12000

Le choix des ports est libre sur chaque noeud, il faut simplement contacter un noeud sur le port (public dans le cas d'un NAT) sur lequel il écoute.

Pour les contacts, on peut spécifier autant d'option contact qu'il y a de contacts:

# The contact list.
#
# The list of hosts to connect to.
#
# You may repeat the contact option to add several hosts.
#
# Default: <none>
contact=alice.example.org:12345
contact=bob.example.org:4545

J'espère avoir bien répondu à tes questions ?

Super ! Merci beaucoup ! :D

Tout à fait : le réseau peut prendre la forme que l'on souhaite et chaque noeud décide avec qui il se connecte et avec qui il ne le fait pas. Les dénominations "client-serveur, pair-à-pair et hybride sont juste des cas particuliers exemple, mais on est vraiment libre à 100%).

Je parlais d'un cas où une même machine devrait se connecter avec beaucoup d'autres hôtes directement.

On peut tout à fait imaginer un gros réseau en "mesh": il faut bien veiller à ce que les noeuds intermédiaires soient en mode "relai" et ça roule :)

Très bonne idée en effet. On m'en a déjà fait part effectivement.

Pour la première release, j'ai voulu vraiment me concentrer sur les performances et surtout la sécurité. Mais ce genre de fonctionnalité ça va etre indispensable aussi donc je compte bien le rajouter.

J'avais déjà à l'époque un prototype fonctionnel d'ouverture de port en UPnP : ce n'est pas compliqué à implémenter, mais un peu long. Mais ça va se faire, j'y tiens également !

Dans tous les cas ICE ne sera pas obligatoire, mais simplement possible.

C'est tout à fait ça.

Dans une infrastructure client-serveur classique, le point critique c'est évidemment le serveur, sans quoi rien n'est possible.

À noter que cette architecture a tout de même l'avantage de faciliter l'administration (on peut mettre en place un mécanisme d'authentification centralisé par exemple).

Si on veut un VPN décentralisé, il faut évidemment accepter qu'on doive configurer indépendament chaque noeud : tout se paye :D

Dans l'exemple cité : si je souhaite mettre en place un réseau entre ma mère, ma soeur et chez moi, j'ai tout l'intérêt de le faire en peer-to-peer :
- Si ma mère, ma soeur ou moi-même coupons notre ordinateur, les deux autres peuvent continuer à communiquer : personne n'a plus d'importance qu'un autre.
- Les transferts réseaux sont directs : surtout dans le cas de connexions entre particuliers, les débits sont souvent faibles, et devoir passer par un point C pour aller de A à B peut-être très couteux, en termes de débit ou de latence.

Justement, OpenVPN n'a pas de problème avec le NAT. Il suffit que le noeud central soit accessible et c'est tout. Les connexions se font des clients vers le serveur.

Disons que si le serveur OpenVPN est situé derrière un NAT, il faudra aussi faire une redirection de port. Mais effectivement, une fois cette redirection faite (si il est bien derrière un NAT), les clients, quelle que soit leur origine peuvent se connecter sans problème. Puisqu'ils ne se connectent jamais directement entre eux donc il n'ont pas ce problème à résoudre.

À noter que Freelan permet aussi d'adopter, si on le souhaite, une architecture clients-serveur(s). On perd un peu d'intérêt (sa spécificité c'est tout de même d'être peer-to-peer ;)) mais c'est parfaitement possible :)

Mais de rien. Je tenais à le faire avec un langage que j'aime et que je maîtrise.

Concernant les limites du nombre de machine, je vais être franc : je n'ai eu l'occasion de tester avec plus de 20 machines.

Maintenant, maintenir une "connexion" (si on peut appeler ça ainsi) avec un autre hôte au sein de freelan est très peu couteux en mémoire et n'a une incidence sur l'occupation processeur que si des données y transitent. J'imagine qu'avec une infrastructure adéquate, on peut donc créer d'assez gros réseaux.

Le projet utilise une boucle d'événements asynchrone ce qui devrait le rendre plutôt "scalable". Il n'y aucune limite codée "en dur" donc j'imagine que la seule limite, c'est celle des performances de la machine et de ses resources (nombre de sockets, etc.).

Les raisons que tu as énoncé sont effectivement les bonnes. De nombreux routeurs permettent en effet de configurer une redirection de port UDP (ou TCP mais ici ça ne nous intéresse pas).

Après, le caractère stateless de UDP le rend plus facile à faire passer au travers d'un NAT (hors NAT symmétriques hélas). Il existe des techniques propres à UDP : je pense notamment au UDP hole punching.

Par ailleurs, un ami à moi travaille actuellement sur l'intégration de ICE au sein de freelan pour faciliter d'autant plus le passage des NAT.

Merci à toi pour ton intérêt !

Et n'hésite pas à me contacter si tu rencontres des difficultés lors de la configuration :)

Je partage ton avis sur le manque de confiance qu'on peut raisonnablement accorder à Hamachi. Je ne compte plus le nombre de fois où le serveur central est passé en maintenance me privant de tout service et ce, sans préavis.

C'est en partie ce qui m'a motivé à commencer ce projet.

Pour l'aspect simplicité, j'ai retourné la question dans tous les sens et il semblerait qu'on ait toujours un choix cornélien à faire pour un VPN peer-to-peer:

• Soit la mise en oeuvre est simple mais ça nuit à la sécurité.
• Soit on se focalise sur la sécurité mais la mise en oeuvre s'en trouve grandement impactée. La faute principalement à la lourdeur qu'imposent les PKI. OpenVPN souffre de la même situation d'ailleurs.

J'espère tout de même pouvoir simplifier un peu les choses à l'avenir. Je vois mal un utilisateur lambda de Windows générer ses propres certificats pour mettre en place son VPN. On ne peut hélas pas dire à l'heure actuelle qu'on vise exactement le même public que Hamachi. Mais nous n'en sommes finalement qu'au début. Et toutes les idées à ce sujet sont les bienvenues !

Le scénario que tu as décrit est tout à fait possible avec freelan, oui. C'est même un des cas les plus probables en fait.

Une nuance cependant : le certificat (autosigné dans ton exemple) contient en fait la clé publique. Il n'y a donc que cet élément à transmettre ;)

De chaque côté, on peut définir les certificats qui font autorité. Le fait de placer un certificat autosigné comme certificat autorité permet effectivement d'autoriser une connexion avec quelqu'un qui présente ce certificat.

Les deux parties s'authentifient donc mutuellement. Si une des parties refuse, il ne peut y avoir d'échange de clé et donc aucun canal de communication sécurisé et authentifié n'est possible.

Une alternative à cette solution qui risque de se retrouver davantage dans une société par exemple, est d'avoir un certificat racine (une CA) qui signe les certificats de chaque pair. Exactement comme ça se fait pour les sites en HTTPS.

On peut par ailleurs mélanger ces deux configurations et autoriser, d'une part tous les certificats émis par une ou plusieurs autorités, et d'autre part accepter (ou refuser) des certificats en particulier.

Pour être franc je ne connaissais pas du tout n2n, c'est très intéressant et assez proche je pense en effet.

Les différences que je crois percevoir :

• Deux notions séparées pour les "supernodes" et les "edge". J'ai cru comprendre que ces premiers étaient nécessaires pour la mise en relation des noeuds (à l'instar d'un tracker pour bittorrent). Nous avons fait le choix pour freelan de ne pas obligatoirement reposer sur une entité centrale pour plus de robustesse (même si dans le cas de n2n j'imagine qu'on peut l'héberger chez soi si on le souhaite).
• J'ai vu qu'il se basait sur un secret partagé entre les noeuds : se pose donc à mon sens la problématique de transfert sécurisé de ce secret. Bon en revanche c'est clairement plus simple et accessible que de générer des certificats, il faut bien l'admettre.

Je n'ai en revanche pas trouvé de description pour leur protocole : j'aurais assez aimé savoir quelle méthode(s) de chiffrement est/sont utilisée(s) et comment les clés sont échangées et renouvellées.

En tout cas, merci pour le lien, c'est toujours bien de voir ce que font les autres.

Les pages sur le site ne sont pas encore écrites (j'y travaille) mais le fichier de configuration est très documenté et devrait déjà aider pas mal. N'hésite pas à me contacter au besoin pour la configuration si jamais.

Concernant les performances, j'ai réalisé plusieurs avec des amis sur plusieurs semaines avec des montées en charge, de la voix sur IP, etc. et j'ai obtenu en moyenne un temps de traitement (latence additionnelle) de 200 microsecondes (0.2 ms) en moyenne pour chaque paquet. Il va de soi que comparé à la gigue qu'on peut observer sur l'Internet, cette latence est imperceptible.

Dans le pire cas (transfert de fichier en FTP au maximum du débit), le processeur est monté à 10% d'occupation au maximum, sur une machine relativement modeste (Debian Squeeze sur un Athlon Dual-Core à 2.5 GHz). Je travaille déjà sur une version où les séquences de chiffrement peuvent-être précalculées (quand le processeur est moins utilisé) et dans laquelle le temps de chiffrement temps-réel se ferait alors en temps constant (un simple XOR), quelle que soit la séquence d'algorithmes de chiffrement utilisés.

En ce qui concerne la stabilité, le démon tourne chez mois depuis plusieurs mois sans interruption ni expansion mémoire notable. Lors du développement, je teste régulièrement chaque composant sous valgrind et gdb pour m'assurer qu'il n'y ait aucune fuite mémoire.

Enfin, concernant le packaging (et openwrt notamment), ça viendra, même s'il est vrai que je manque de temps pour faire tout ce que je souhaiterais. Le packaging Mac OS X est en cours de réalisation et j'ai déjà commencé à m'attaquer au packaging Red-Hat également. Si on me témoigne une forte demande pour d'autres plateformes, il va de soi que je les ferai passer en priorité.

Dans tous les cas, merci pour ton intérêt, et si tu le testes, n'hésite pas à me faire un retour ! (qu'il soit positif ou non)

IPSec est en effet une solution intéressante et souvent parfaitement intégrée, mais qui ne répond pas exactement aux mêmes problématiques.

On critique parfois IPSec pour sa difficulté d'intégration avec des réseaux NATés; Freelan s'affranchit de ce problème en étant basé sur UDP. Il est en ce sens, plus près d'OpenVPN (qui défini d'ailleurs lui aussi son propre protocole, mais qui impose une relation client(s)-serveur). De plus il a été conçu afin de pouvoir être intégrable à une application (le protocole peut servir de canal de transmission sécurisé sans être nécessairement associé à une interface réseau virtuelle).

Freelan ne se pose donc pas en concurrent d'IPSec (ce serait d'ailleurs prétentieux et vain) mais bel et bien en complément, si on le souhaite.

Son principal argument est selon moi sa capacité de modéliser la topologie réseau que l'on souhaite et de pouvoir décentraliser l'administration au besoin. Je ne connais aujourd'hui pas d'alternative libre à Hamachi qui permette une connexion directe entre les pairs et ce, sur plusieurs plateformes et/ou en IPv6. Évidemment, Hamachi propose en plus une interface qui simplifie grandement la configuration, et il n'est pas exclu que ce genre d'outil arrive dans un futur proche.

Le fait de rédiger un nouveau protocole est toujours un risque, c'est vrai. Mais cela permet aussi d'avoir un meilleur contrôle sur ce qu'on l'on souhaite, et grâce à ça, freelan offre par exemple la possibilité de définir deux paires de certificat-clé privée séparées pour l'authentification et le chiffrement, pour une sécurité accrue.

Je ne sais pas si je t'ai convaincu mais j'espère au moins avoir répondu à tes questions. Merci d'avoir pris le temps de regarder en tout cas !