En février, je vous ai présenté Reticulum , une pile réseau chiffrée de Mark Qvist qui n'a besoin ni de TCP/IP ni d'Internet. Et cette fois, on va aller un peu plus loin en passant à la pratique avec NomadNet, un programme du même auteur qui permet de servir des pages et des fichiers par-dessus Reticulum.

À la fin de ce tuto, vous aurez alors une page d'accueil et quelques fichiers à télécharger, diffusés par votre propre nœud.

Pour ce tuto, je me suis aidé de VMs et de la doc que vous pouvez consulter ici .

Installer NomadNet

NomadNet est tout simplement un paquet Python qui va chercher Reticulum pour l'installer. Il suffit d'invoquer pip comme ceci :

pip install nomadnet

Sur les Debian et Ubuntu récentes, qui bloquent pip, vous pouvez utiliser pipx à la place comme ceci :

pipx install nomadnet
pipx install rns

Et voilà, vous devriez normalement vous retrouver avec NomadNet 1.5.0 et rns 1.6.0.

NomadNet 1.5.0 installé par pipx

Le paquet rns apporte rnstatus et les autres utilitaires de Reticulum 1.6.0

Le second paquet n'est pas obligatoire certes, mais il apporte des utilitaires de Reticulum plutôt cools et pratiques comme rnstatus, qui affiche l'état de vos interfaces.

Lancez ensuite nomadnet une première fois. Le programme s'ouvrira alors sur son guide, dans le terminal, et créera au passage 2 fichiers de configuration : ~/.reticulum/config pour la pile réseau et ~/.nomadnetwork/config pour NomadNet.

Le premier lancement, sur le guide

Ce guide recommande un terminal d'au moins 135 colonnes sur 32 lignes, donc agrandissez un peu la fenêtre si vous voyez que c'est moche et si vous voyez des petits carrés à la place des lettres de l'alphabet, c'est que vous devez installer les Nerd Fonts . Ou vous en passer en changer dans la section [textui] dans le fichier ~/.nomadnetwork/config, le paramètre glyphs = nerdfont par :

glyphs = unicode

Relancez ensuite NomadNet pour que le changement prenne effet.

Côté réseau, la config par défaut n'active qu'une seule interface : l'AutoInterface. Elle permet de découvrir les autres nœuds Reticulum par IPv6 en lien local et transporte les paquets en UDP, sans routeur ni DHCP. Mais elle ne parle qu'aux pairs Reticulum de votre réseau local. Donc si un pare-feu tourne sur la machine et bloque ce trafic, faudra lui ouvrir les ports UDP 29716 et 42671, sinon personne ne vous trouvera et ça c'est triste... snif.

Entre mes deux machines virtuelles, ça a marché sans toucher à rien, puisque le pare-feu ufw est désactivé par défaut dans Ubuntu.

Activer le nœud

Par défaut, NomadNet est un simple client de messagerie. Pour qu'il serve des pages web, ouvrez ~/.nomadnetwork/config, cherchez la section [node] et passez enable_node à yes.

[node]
enable_node = yes
node_name = Mon site
disable_propagation = yes

Le node_name est le nom que votre nœud diffuse à tout le réseau donc je compte sur vous pour choisir un truc cool. Quant à disable_propagation, il sert à faire un nœud qui ne sert que des pages, sans stocker ni relayer les messages chiffrés des autres utilisateurs. En version 1.5.0 c'est déjà le réglage par défaut, donc pas de stress. Relancez ensuite NomadNet, ou faites-le tourner sans interface avec la commande : nomadnet --daemon.

La section [node] de la config, nœud activé

Chez moi, une fois le nœud activé, un onglet My Node est alors apparu dans l'interface, avec l'explorateur des pages et des fichiers, ainsi qu'un éditeur de langage micron (j'y viens après) et un aperçu en direct, soit de quoi se passer de nano.

Sans Nerd Font, des carrés remplacent les icônes de l'onglet My Node

La page provisoire d'un nœud encore vide et la fenêtre de saisie d'adresse, dans une version antérieure de NomadNet

Écrire la page et poser les fichiers

Tant que vous n'avez rien déposé, le nœud sert une page d'accueil générée automatiquement. Comme je vous le disais, les pages s'écrivent en micron, un petit langage de balisage de NomadNet, et vont dans ~/.nomadnetwork/storage/pages. Créez donc d'abord un fichier index.mu, puisque c'est la page servie par défaut à quiconque se connectera à votre noeud.

Les fichiers à partager vont ensuite dans le dossier ~/.nomadnetwork/storage/files, et pour qu'un visiteur puisse en télécharger un, il faudra un lien vers ce même fichier dans une de vos pages.

Voici une page minimale, assemblée à partir des exemples du guide :

>Bienvenue sur mon nœud
Quelques fichiers à récupérer :

`[Le PDF du jour`:/file/document.pdf]

La page index.mu et le PDF posés dans le stockage du nœud

À l'essai, ce lien fonctionne, mais il s'affiche chez le visiteur du texte ordinaire tout moche, alors pour qu'il ressorte un peu mieux, je vous invite à l'entourer d'une couleur et d'un petit soulignement avec ces codes : F79d` et _ pour ouvrir, ``_ et ``f` pour refermer :

`F79d`_`[Le PDF du jour`:/file/document.pdf]`_`f

Notre page vue depuis la seconde machine : le lien ne se distingue pas du texte ordinaire

Avec ses balises de couleur, le lien sort en bleu souligné

L'éditeur micron de l'onglet My Node et son aperçu en direct

L'adresse :/file/document.pdf pointe donc vers un fichier local, posé dans storage/files mais attention par contre, NomadNet ne dressera la liste de ces deux dossiers qu'au démarrage, puisque page_refresh_interval et file_refresh_interval sont à 0 par défaut. Donc après chaque ajout, soit vous redémarrez votre noeud, soit vous donnez à ces deux réglages un intervalle en minutes pour que ça s'auto-refresh tous les X.

Ainsi, une page déjà existante que l'on modifie s'affichera aussitôt chez le visiteur dans sa nouvelle version pour peu qu'il refresh, par contre, une page ajoutée par la suite sera en "Request failed" tant que le nœud n'a pas redémarré.

L'adresse complète d'une page se compose donc d'un hash de destination du nœud, qui fait 32 caractères hexadécimaux, suivi de :/page/index.mu. Dans l'onglet Network de NomadNet, Ctrl+U ouvre la boîte de saisie d'URL, et le programme se charge de trouver le nœud et de s'y connecter. Depuis une autre machine du même réseau local, c'est là aussi que votre page devrait s'afficher.

Notre nœud "Mon site" dans le flux d'annonces du voisin

Maintenant le plus simple pour la trouver, c'est encore de passer par le flux d'annonces de l'onglet Network, où votre nœud apparaît sous son nom, puis de cliquer dessus et de choisir Connect. Et si vous passez par Ctrl+U, chez moi la boîte de dialogue est arrivée préremplie avec l'adresse de la page en cours, qu'il a donc fallu effacer avant de taper la mienne, avec l'adresse du nœud lue sur sa fiche, à la ligne Addr.

La boîte de saisie d'URL avec l'adresse complète de la page

Reste le téléchargement, et là, sur mon Ubuntu en français, ça a coincé car NomadNet enregistre par défaut dans ~/Downloads, un dossier qui n'existe pas chez moi puisqu'il s'appelle Téléchargements. Et donc chez moi le transfert est resté figé sur "Receiving response 100%", sans un message à l'écran. L'erreur n'apparaissait que dans ~/.nomadnetwork/logfile. Donc si ce dossier n'existe pas chez vous non plus, corrigez ça sur la machine du visiteur, à la ligne downloads_path de la section [client] de ~/.nomadnetwork/config :

downloads_path = ~/Téléchargements

Le dossier de téléchargement corrigé dans la config de NomadNet

Chez moi, après un redémarrage de NomadNet, le PDF est arrivé ensuite en une fraction de seconde, avec une empreinte SHA-256 identique à celle de l'original.

Le PDF enregistré, 13,12 Ko, identique à l'original

Le forum rns.recipes ouvert dans le navigateur intégré de NomadNet, son adresse de page en haut

Sortir du réseau local

Maintenant pour être joignable depuis l'extérieur, il faut en général ajouter une interface dans ~/.reticulum/config, sous [interfaces], à moins qu'un autre système de votre réseau local, configuré en passerelle, ne le fasse déjà pour vous. Pour passer par Internet, la forme que donne la doc est celle-ci, où target_host et target_port sont ceux d'un point d'entrée que vous aurez choisi :

[[TCP Client Interface]]
 type = TCPClientInterface
 enabled = yes
 target_host = 127.0.0.1
 target_port = 4242

Le projet ne fournit plus d'adresse toute faite, puisque son testnet public a été fermé donc la doc renvoie vers deux annuaires communautaires, directory.rns.recipes et rmap.world, et conseille de mettre en place plusieurs connexions plutôt qu'une seule. Sachez aussi que si Reticulum chiffre ses échanges par défaut, TCP lui ne chiffre rien. Cela veut dire que l'adresse IP des deux bouts est visible pour qui inspecte la connexion, et il peut aussi en déduire que vous faites tourner Reticulum. Donc si vous voulez masquer réellement ces adresses, faudra mettre en place une interface I2P au prix d'un démon i2pd à faire tourner à côté (une fois encore tout est dans la doc).

Dans l'annuaire directory.rns.recipes on a 71 points d'entrée TCP, dont 40 sont actuellement en ligne, chacun avec pour chacun son bloc de configuration prêt à copier. J'ai ajouté RMAP et SWISS RNS sur la machine du visiteur, relancé NomadNet, et une minute plus tard, une dizaine de nœuds figuraient déjà dans la liste, le mien compris :

[[RMAP]]
 type = TCPClientInterface
 enabled = yes
 target_host = rmap.world
 target_port = 4242

[[SWISS RNS]]
 type = TCPClientInterface
 enabled = yes
 target_host = swiss-rns.cl0ud.ch
 target_port = 4242

Dix nœuds listés une minute après l'ajout des deux points d'entrée, le mien compris, les noms des autres étant floutés

rnstatus avec l'AutoInterface et les deux interfaces TCP actives

Je n'ai fait ce test que dans ce sens, le visiteur voit des nœuds d'Internet, mais je n'ai pas vérifié qu'un inconnu pouvait atteindre notre nœud, puisque seule la machine du visiteur avait ces deux interfaces.

Ce que votre nœud montre

Une fois en ligne, le nœud s'annonce au démarrage puis toutes les 360 minutes, et cette annonce diffuse son nom en clair. Et d'après le code de NomadNet (Node.py), le nœud réutilise l'identité principale du programme, celle qui sert aussi à votre messagerie, donc n'importe qui peut relier votre site à votre adresse de messagerie.

Et ça se voit, puisque chez le visiteur, la fiche de votre nœud affiche une ligne Oprtr qui n'est autre que votre adresse de messagerie LXMF , en clair.

La fiche du nœud chez le visiteur, avec l'adresse de messagerie de l'opérateur en face d'Oprtr

Les pages et fichiers que vous déposez sont publics, sauf si vous posez à côté un fichier du même nom suivi de .allowed, qui liste les identités autorisées. Et surtout, hors Windows, un fichier exécutable placé dans pages est lancé comme un programme quand un visiteur autorisé le demande, puisque c'est comme ça que NomadNet génère ses pages dynamiques. Donc vérifiez les droits de ce que vous y copiez.

Reste la question de la maturité car pour le moment Reticulum n'a fait l'objet d'aucun audit de sécurité externe, NomadNet est en bêta, y'a eu quelques failles de sécu corrigées depuis et les dépôts GitHub ne sont plus que des miroirs figés.

Ajoutez à ça la licence maison, la Reticulum License, qui interdit tout usage dans un système conçu pour nuire aux humains et toute utilisation dans la création d'une IA ou de ses données d'entraînement. Bref, les défenseurs d'Omarchy repasseront , loool. Voilà, donc pour un petit site entre voisins ou entre amis, c'est jouable mais pour quelque chose de sensible, je vous conseille d'attendre un audit et surtout de bien lire la doc.

Source : NomadNet sur GitHub

Vous avez un Mac et un PC Windows sur le même bureau, et à chaque fois qu'il faut faire passer une commande de l'un à l'autre, vous vous envoyez un message Slack à vous-même, ou vous ouvrez un fichier texte dans un dossier partagé. Hé oui, avouez, c'est le lose un peu quand même. Heureusement, UniClipboard règle exactement ce problème ! Vous copiez ici, vous collez là-bas, et basta !

La première fois que vous utilisez UniClipboard, vous choisissez une phrase de passe, vos machines rejoignent le même espace avec un code d'invitation, et le presse-papiers circule entre elles. Pas de compte à vous créer et surtout, texte, images et fichiers passent d'une machine à l'autre sans souci.

L'outil vous permet même de conserver un historique local dans lequel vous pouvez faire des recherches hyper rapidement, à l'aide d'un raccourci clavier.

Entre 2 ordinateurs sur le même réseau ça fonctionne super bien mais quand deux machines ne se voient pas directement, elles passent par un relais, et ce relais n'a aucune clé : il ne transporte que du chiffré. Maintenant, si l'idée même de passer par un intermédiaire vous hérisse le poil, y'a un mode LAN-only qui coupe tout chemin sortant de votre réseau. Comme ça vous êtes pépouze.

Le 30 juillet, un attaquant a vidé 1 196 adresses Bitcoin en 41 minutes. Un peu plus de 1 082 bitcoins, environ 70 millions de dollars. Aucune des victimes n'avait cliqué sur quoi que ce soit.

Elles avaient acheté un Coldcard, le portefeuille matériel de la société canadienne Coinkite, l'appareil que les puristes du bitcoin recommandent depuis des années précisément parce qu'il ne se connecte jamais à Internet.

Un portefeuille matériel fabrique une seed, la suite de mots dont dérivent toutes vos clés. Toute la sécurité repose sur un seul point : que cette suite soit réellement imprévisible. La puce embarque pour ça un générateur d'aléatoire physique.

En mars 2021, le firmware 4.0.0 a introduit une erreur d'intégration. Coldcard voulait désactiver le générateur intégré de MicroPython pour utiliser le sien, et a donc défini le paramètre MICROPY_HW_ENABLE_RNG à zéro. Sauf que la bibliothèque libngu vérifiait seulement si ce paramètre existait, pas la valeur qu'il portait. Il existait. Le test passait.

Pendant cinq ans, chaque tirage est donc passé par Yasmarang, un générateur pseudo-aléatoire non cryptographique dont l'état de départ venait de trois choses : l'identifiant 32 bits de la puce, un registre de minuterie et l'horloge interne. Rien de secret là-dedans, et plus la moindre entropie fraîche ensuite.

Les Mk3 se retrouvaient avec une quarantaine de bits d'imprévisibilité au lieu des 128 promis, les Mk4, Mk5 et Q avec 72. Pour ces derniers, l'ensemble des clés que l'appareil pouvait produire tombait à quelques milliards de combinaisons.

À ce niveau, il n'y a plus rien à pirater. L'attaquant génère les seeds candidates sur sa propre machine, calcule les adresses que chacune produirait, et les compare à la blockchain, publique par construction. Quand une adresse contient des fonds, il tient la clé. Aucun appareil n'a jamais été touché.

Coinkite a publié un firmware d'urgence le 31 juillet pour tous les modèles concernés. Attention au contresens qui coûte cher : la mise à jour ne répare pas une seed déjà créée. Il faut en générer une nouvelle et y déplacer les fonds. Les configurations multisignature, où le Coldcard n'est qu'une clé parmi plusieurs, sont largement épargnées.

Rodolfo Novak, le patron de Coinkite, a écrit qu'il était désolé et dévasté, et assume. Il avance aussi que l'attaquant a peut-être déniché la faille avec une IA, sans en apporter la preuve, tout en reconnaissant que sa propre revue de code assistée par IA était passée à côté.

Cinq ans qu'un zéro traînait dans un fichier de configuration, sur l'appareil vendu comme le plus sûr du marché. Le pire endroit possible pour ce genre d'oubli.

Source : The Hacker News

Si vous avez déjà envoyé un lien à usage unique qui est arrivé mort chez votre collègue, c'est probablement la prévisualisation de la messagerie qui a ouvert le lien en premier et qui a cramé le secret accompagnant le lien.

La bonne nouvelle c'est que Oğuzhan Karacabay vient de publier une grosse mise à jour d' OTI , son service open source auto-hébergeable qui génère des liens de partage consultables une seule fois, avec chiffrement dans le navigateur.

Vous collez un mot de passe, une clé d'API ou un bout de config dans OTI, le navigateur chiffre, le serveur lui ne stocke que du charabia, et le destinataire reçoit une jolie URL qui ne fonctionnera bien qu'une fois.

Ce qui change, c'est que le lien ne meurt plus tout seul. En chargeant la page, votre destinataire voit un compte à rebours et un bouton "Decrypt Message", rien d'autre. Du coup, tant que personne ne clique, le message continue son roupillon.

Comme ça, un bot qui déroule les URLs pour fabriquer une jolie vignette repart bredouille. Après si c'est un vrai scanner de sécurité qui charge vraiment la page dans un navigateur automatisé, vous ne pourrez pas éviter le problème.

L'autre nouveauté dans OTI c'est à la création d'un nouveau lien. Le service vous génère en fait 2 liens. Il y a celui que vous envoyez et un second que vous gardez pour vous. Ce dernier vous permettra de consulter l'état du message sans jamais afficher son contenu.

Côté crypto, le contenu est chiffré en AES-256-GCM via WebCrypto, et cette clé AES est elle-même emballée dans une paire RSA-2048 générée dans votre navigateur. La clé privée voyage dans le fragment de l'URL, la partie après le #, que les navigateurs n'envoient jamais au serveur.

Le principe zero-knowledge utilisé par OTI est quasi le même que celui de PrivateBin ou d' Enclosed où la clé ne quitte jamais le navigateur.

Par contre, ça donne des liens obèses puisque le mien faisait 1825 caractères, dont 1728 rien que pour le fragment, et c'est déjà compressé en zlib. Bon courage donc pour le dicter au téléphone ^^ (il y a un QR code, heureusement !)

Le reste, c'est du confort... Fichiers .txt jusqu'à 100 Ko validés dans le navigateur avant chiffrement, mot de passe optionnel par-dessus, expiration au choix entre 5 minutes et 7 jours, limitation de débit via Redis et une tâche planifiée qui balaie les secrets périmés toutes les 30 minutes.

Pour l'héberger, c'est de l'AdonisJS 6 en TypeScript avec Dockerfile, docker-compose et migrations fournis, en licence MIT. Redis peut céder sa place au limiteur en mémoire si vous montez juste un petit truc perso.

Notez quand même que pour le moment, le projet n'a pas été audité et est maintenu par un gars tout seul, donc évitez de l'utiliser pour des secrets d'État.

La démo est en ligne si vous voulez essayer avant d'installer.