Pour résumer, si on te force à choisir entre une glace au citron et une glace à la bouse de vache, toi tu réponds "Je n'aime pas le citron, du coup je ne sais pas…".
Intéressant, merci, ça valait le coup de nous éclairer avec ce journal lumineux.
Elle n'est déployée, justement, qu'entre serveurs SMTP. Les messages transitent en clair dans les serveurs, ce qui offre des garanties de confidentialité assez limitées. Pire, en pratique elle ne fonctionne que contre les attaques purement passives.
En effet, elle est très souvent opportuniste, et on peut forcer deux serveurs à ne pas activer la couche TLS. C'est malheureusement ce que recommande la RFC 3207: "A publicly-referenced SMTP server MUST NOT require use of the STARTTLS extension in order to deliver mail locally.".
En plus, aujourd'hui, les MTA ne vérifient en général pas que le certificat présenté correspond bien au serveur distant, car en général, ce n'est pas le cas. Il suffit alors d'avoir un certificat valide pour n'importe quel domaine sous la main pour faire un MIM.
Merci pour tes tests exhaustifs et tes retours très instructifs. Je suis effectivement à l'origine du projet même si maintenant on est deux.
entre deux utilisateurs NATés, je n'ai jamais pu obtenir de connexion directe. J'ignore les paramètres de leurs NAT, mais c'est un peu rebutant. Heureusement, le fait de rajouter un troisième larron (à chacun des deux) non-NATé a réglé le problème.
En fait il faut au moins que l'un des deux noeuds ait un ami non NATé. Ce sera étendu quand on pourra faire des requêtes aux amis d'amis.
par contre, la mise en relation est leeeenntte. Compter plusieurs minutes (jusqu'à une petite dizaine, je dirais) avant de voir tout le monde comme Online (le "Found" est quasi instantané par contre, mais c'est d'autant plus frustrant). C'est d'autant plus incompréhensible s'il n'y a pas > de passage de NAT.
C'est bizarre, je ne sais pas trop d'où ça vient. En tout cas c'est un bug, ça devrait aller raisonnablement vite (quelques dizaines de secondes tout au plus).
quelques incohérences/imprécisions dans l'interface. Type "Send another file" comme bouton d'envoi de fichier (même pour le premier fichier). Ou le bouton "Refresh" sur mes dossiers partagés (puisqu'apparemment ce n'est pas un dossier local, mais un espace vers lequel j'ai uploadé des choses, il ne devrait pas avoir besoin de se rafraîchir, si?).
C'est vrai, l'interface est encore un peu "brute" et demande à être améliorée. Le bouton refresh sert quand certains partages sont définis avec des dossiers déjà présents (avec "Add existing directory"), car dans ce cas des fichiers peuvent avoir été ajoutés de l'extérieur de Teapotnet, et les dossiers de ce type ne se ont pour l'instant pas surveillés, juste réindexés incrémentalement à intervalles réguliers.
la licence dans /static n'est pas claire. Elle parle à la fois de BY-SA et de NC. Quid?
Je vais jeter un oeil à ça.
ça n'a pas l'air d'être prévu pour l'i18n. C'est un peu dommage.
Exact, c'est dommage. Ça serait une fonction utile à ajouter.
Pour les versions futures, c'est presque exactement ce que l'on veut ajouter ! Les utilisateurs et identités sont en fait juste une question d'interfaçage, le programme gère déjà des utilisateurs multiples. Il est d'ailleurs possible d'ajouter des utilisateurs comme décrit dans INSTALL: echo myusername mypassword > users.txt puis lancer Teapotnet qui lit puis supprime le fichier.
Mais comme tu le dis, notre objectif principal et de rester simple d'utilisation.
Oui, le tracker utilise des requêtes HTTP par simplicité.
Le protocole lui-même est sur TCP, c'est un protocole texte relativement simple (malheureusement il n'y a pas encore de doc digne de ce nom), et toutes les connexions sont chiffrées avec AES après authentification et dérivation des clés de session. La négociation avant chiffrement est obfusquée en chiffrant avec une clé préétablie pour éviter des motifs facilement filtrables. Actuellement les dérivations de clés sont faites avec PBKDF2 (HMAC-SHA512, 10000 iterations). La méthode actuelle ne permet pas la confidentialité persistante pour l'instant mais cela pourrait être implémenté à l'avenir.
Exact, ./teapotnet --tracker [mon_port] lance un tracker sur le port indiqué. Le plus pratique est ensuite de transférer sur le serveur web local le chemin /tracker sur http://localhost:[mon_port] (ProxyPass dans le cas d'apache)
Pour répondre à ton autre question, on peut évidemment ajouter comme contacts des utilisateurs sur d'autres trackers. À noter que le tracker sert surtout à bootstrapper car les instances retiennent les adresses des contacts.
Pour l'instant la localisation des pairs est fournie par des trackers uniquement. Le tracker est simplement une table pour relier des hashs anonymisés à des adresses sur le réseau. Il est possible d'en déployer un avec l'option --tracker en ligne de commande (et éventuellement rediriger avec le serveur web déjà présent les requêtes sur l'URL /tracker), mais un tracker en PHP, nettement plus simple à déployer, sera bientôt disponible.
Un tracker fonctionne à l'adresse teapotnet.org, et il est utilisé par défaut.
Désolé, le mot est malheureux, j'entendais simplement par "résilient" qu'il surmonte les obstables. Disons "tout terrain" ! L'objective est d'avoir une application qui "juste marche" même dans un environnement limité comme tous ces pseudos accès Internet où la plupart des protocoles sont filtrés, surtout ce qui ressemble à du Bittorrent (du genre point d'accès wifi public, résidence universitaire, 3G, etc). Ce n'est pas selon moi un problème de facilité d'utilisation.
Le NAT n'a pas grand rapport avec cet aspect. Je sais bien qu'une bonne partie des protocoles P2P dignes de ce nom fonctionnent derrière des NAT, et heureusement d'ailleurs ! Je disais seulement que le NAT traversal fonctionnait. Par contre, je n'ai je pense pas été clair, le protocole n'est pas sur HTTP, car ce serait inutilement couteux pour le transport des messages.
C'est assez proche, Camlistore est un projet vraiment sympa. La différence majeure est que Teapotnet n'est pas spécifiquement un système de stockage, il permet aussi d'envoyer des messages et ainsi de fournir une sorte de réseau social (avec synchronisation des messages et contacts entre les instances). Il est plus orienté vers l'accès à des fichiers distant qu'au stockage proprement dit.
Bref, pour stocker mes fichiers entre un NAS et un serveur Amazon, Calimstore semble très bien. Pour accèder aux photos et vidéos que mes parents ont pris en vacances, Teapotnet est tout à fait indiqué.
# Pour résumer...
Posté par Paulo (site web personnel) . En réponse au journal Un président néo-libéral est-il moins pire qu'une présidente xénophobe ?. Évalué à 3.
Pour résumer, si on te force à choisir entre une glace au citron et une glace à la bouse de vache, toi tu réponds "Je n'aime pas le citron, du coup je ne sais pas…".
Intéressant, merci, ça valait le coup de nous éclairer avec ce journal lumineux.
[^] # Re: google est-il le plus dangereux ?
Posté par Paulo (site web personnel) . En réponse au journal Android "pure" : Filtrer les applications qui utilise les Google play services. Évalué à 0.
Oui, les gens bien font confiance à Google pour vérifier que le certificat de leur banque est valide.
[^] # Re: Et les métadonnées ?
Posté par Paulo (site web personnel) . En réponse au journal Voilà comment inciter 25% des internautes à chiffrer leurs mails. Évalué à 2.
Elle n'est déployée, justement, qu'entre serveurs SMTP. Les messages transitent en clair dans les serveurs, ce qui offre des garanties de confidentialité assez limitées. Pire, en pratique elle ne fonctionne que contre les attaques purement passives.
En effet, elle est très souvent opportuniste, et on peut forcer deux serveurs à ne pas activer la couche TLS. C'est malheureusement ce que recommande la RFC 3207: "A publicly-referenced SMTP server MUST NOT require use of the STARTTLS extension in order to deliver mail locally.".
En plus, aujourd'hui, les MTA ne vérifient en général pas que le certificat présenté correspond bien au serveur distant, car en général, ce n'est pas le cas. Il suffit alors d'avoir un certificat valide pour n'importe quel domaine sous la main pour faire un MIM.
[^] # Re: RetroShare
Posté par Paulo (site web personnel) . En réponse au journal Teapotnet, un réseau social privé pour l'échange de fichiers. Évalué à 2.
Merci pour tes tests exhaustifs et tes retours très instructifs. Je suis effectivement à l'origine du projet même si maintenant on est deux.
En fait il faut au moins que l'un des deux noeuds ait un ami non NATé. Ce sera étendu quand on pourra faire des requêtes aux amis d'amis.
C'est bizarre, je ne sais pas trop d'où ça vient. En tout cas c'est un bug, ça devrait aller raisonnablement vite (quelques dizaines de secondes tout au plus).
C'est vrai, l'interface est encore un peu "brute" et demande à être améliorée. Le bouton refresh sert quand certains partages sont définis avec des dossiers déjà présents (avec "Add existing directory"), car dans ce cas des fichiers peuvent avoir été ajoutés de l'extérieur de Teapotnet, et les dossiers de ce type ne se ont pour l'instant pas surveillés, juste réindexés incrémentalement à intervalles réguliers.
Je vais jeter un oeil à ça.
Exact, c'est dommage. Ça serait une fonction utile à ajouter.
Pour les versions futures, c'est presque exactement ce que l'on veut ajouter ! Les utilisateurs et identités sont en fait juste une question d'interfaçage, le programme gère déjà des utilisateurs multiples. Il est d'ailleurs possible d'ajouter des utilisateurs comme décrit dans INSTALL:
echo myusername mypassword > users.txtpuis lancer Teapotnet qui lit puis supprime le fichier.Mais comme tu le dis, notre objectif principal et de rester simple d'utilisation.
[^] # Re: RetroShare
Posté par Paulo (site web personnel) . En réponse au journal Teapotnet, un réseau social privé pour l'échange de fichiers. Évalué à 3.
Oui, le tracker utilise des requêtes HTTP par simplicité.
Le protocole lui-même est sur TCP, c'est un protocole texte relativement simple (malheureusement il n'y a pas encore de doc digne de ce nom), et toutes les connexions sont chiffrées avec AES après authentification et dérivation des clés de session. La négociation avant chiffrement est obfusquée en chiffrant avec une clé préétablie pour éviter des motifs facilement filtrables. Actuellement les dérivations de clés sont faites avec PBKDF2 (HMAC-SHA512, 10000 iterations). La méthode actuelle ne permet pas la confidentialité persistante pour l'instant mais cela pourrait être implémenté à l'avenir.
[^] # Re: RetroShare
Posté par Paulo (site web personnel) . En réponse au journal Teapotnet, un réseau social privé pour l'échange de fichiers. Évalué à 2.
Exact, ./teapotnet --tracker [mon_port] lance un tracker sur le port indiqué. Le plus pratique est ensuite de transférer sur le serveur web local le chemin /tracker sur http://localhost:[mon_port] (ProxyPass dans le cas d'apache)
Pour répondre à ton autre question, on peut évidemment ajouter comme contacts des utilisateurs sur d'autres trackers. À noter que le tracker sert surtout à bootstrapper car les instances retiennent les adresses des contacts.
[^] # Re: Intéressant mais...
Posté par Paulo (site web personnel) . En réponse au journal Teapotnet, un réseau social privé pour l'échange de fichiers. Évalué à 2.
Pour l'instant la localisation des pairs est fournie par des trackers uniquement. Le tracker est simplement une table pour relier des hashs anonymisés à des adresses sur le réseau. Il est possible d'en déployer un avec l'option --tracker en ligne de commande (et éventuellement rediriger avec le serveur web déjà présent les requêtes sur l'URL /tracker), mais un tracker en PHP, nettement plus simple à déployer, sera bientôt disponible.
Un tracker fonctionne à l'adresse teapotnet.org, et il est utilisé par défaut.
[^] # Re: Au bûcher !
Posté par Paulo (site web personnel) . En réponse au journal Teapotnet, un réseau social privé pour l'échange de fichiers. Évalué à 3.
Désolé, le mot est malheureux, j'entendais simplement par "résilient" qu'il surmonte les obstables. Disons "tout terrain" ! L'objective est d'avoir une application qui "juste marche" même dans un environnement limité comme tous ces pseudos accès Internet où la plupart des protocoles sont filtrés, surtout ce qui ressemble à du Bittorrent (du genre point d'accès wifi public, résidence universitaire, 3G, etc). Ce n'est pas selon moi un problème de facilité d'utilisation.
Le NAT n'a pas grand rapport avec cet aspect. Je sais bien qu'une bonne partie des protocoles P2P dignes de ce nom fonctionnent derrière des NAT, et heureusement d'ailleurs ! Je disais seulement que le NAT traversal fonctionnait. Par contre, je n'ai je pense pas été clair, le protocole n'est pas sur HTTP, car ce serait inutilement couteux pour le transport des messages.
Désolé pour la doc, ça sera vite disponible !
[^] # Re: Teapotnet ?
Posté par Paulo (site web personnel) . En réponse au journal Teapotnet, un réseau social privé pour l'échange de fichiers. Évalué à 3.
C'est assez proche, Camlistore est un projet vraiment sympa. La différence majeure est que Teapotnet n'est pas spécifiquement un système de stockage, il permet aussi d'envoyer des messages et ainsi de fournir une sorte de réseau social (avec synchronisation des messages et contacts entre les instances). Il est plus orienté vers l'accès à des fichiers distant qu'au stockage proprement dit.
Bref, pour stocker mes fichiers entre un NAS et un serveur Amazon, Calimstore semble très bien. Pour accèder aux photos et vidéos que mes parents ont pris en vacances, Teapotnet est tout à fait indiqué.