Vous avez besoin de partager un gros fichier avec un pote au travers d’Internet ? Bon, y’a WeTransfer et ce genre de choses mais ça reste limité en taille de fichier et c’est stocké on ne sait où… Après vous pouvez tenter scp en priant pour qu’il n’ait pas 15 couches de NAT, mais bon galère quoi…

Bienvenue dans sur le nouvel Internet, où le peer-to-peer est mort et enterré sous des tonnes de NAT, de pare-feu et de FAI qui bloquent tout. Du coup, on a tous abandonné le P2P pour le cloud et on upload nos fichiers comme des cons, lentement, parfois en payant, au lieu de balancer la sauce en direct.

Heureusement, y’a SendMe qui vient nous rappeler qu’Internet peut fonctionner autrement. C’est un outil de transfert de fichiers qui connecte deux machines directement, sans serveur intermédiaire. Vous lancez sendme send ~/mes_photos, ça génère un ticket unique, vous envoyez ce ticket à votre destinataire, il tape sendme receive blobQmFoo..., et c’est parti mon kiki pour un transfert direct à l’ancienne, device-to-device.

Pas de compte, pas de limite, que dalle à configurer, juste deux machines qui se parlent directement, comme au bon vieux temps !

Le truc cool, c’est que SendMe utilise Iroh , un protocole P2P qui contourne tous les problèmes de NAT et compagnie puisqu’il fonctionne avec un système de “dial by public key” où chaque endpoint a une clé publique unique de 256 bits. Et ensuite, vous vous connectez en utilisant cette clé plutôt qu’une adresse IP.

Quand vous générez un ticket avec SendMe, ce ticket contient la clé publique de votre machine que le destinataire utilise pour se connecter chez vous. Peu importe que vous soyez derrière un NAT, que votre adresse IP change, ou que vous n’ayez aucune idée de ce qu’est un port forwarding. Iroh gère le NAT hole punching automatiquement, et si vraiment la connexion directe est impossible, il passe par un serveur relai en fallback.

Iroh, c’est du QUIC pur jus, un protocole de transport moderne dont je vous ai déjà parlé, qui apporte pas mal de trucs cools comme du chiffrement, de l’authentification par défaut (TLS 1.3), du multiplexage de streams, pas de head-of-line blocking, et connexion en zéro round-trip. Du coup, une fois connecté, les transferts peuvent saturer une connexion 8 Gbps sans problème !

Les fichiers sont ainsi streamés avec vérification Blake3, donc vous êtes sûr de l’intégrité des données et si le transfert est interrompu, pas de problème, il reprend là où il s’était arrêté. Et comme tout passe en chiffrement de bout en bout via QUIC, personne ne peut voir ce qui transite dans les tutubes de votre Internet.

L’installation sur Unix/Linux/macOS, un petit curl et hop, c’est plié :

curl -fsSL https://iroh.computer/sendme.sh | sh

Sur Windows:

iwr https://www.iroh.computer/sendme.ps1 -useb | iex

Vous vous retrouvez avec un binaire sendme prêt à l’emploi.

Maintenant, si vous préférez une interface graphique plutôt que la ligne de commande, il existe aussi AltSendme , une application desktop cross-platform qui utilise le même protocole Iroh. L’app est développée en Rust avec Tauri pour le backend et React + TypeScript pour le frontend et le gros avantage, c’est qu’elle est compatible avec SendMe CLI. Vous pouvez donc générer un ticket avec l’interface graphique et quelqu’un peut le recevoir en ligne de commande, ou vice-versa.

AltSendme ajoute également une couche d’interface utilisateur sympa tout en gardant toute la puissance technique d’Iroh… Même chiffrement de bout en bout (QUIC + TLS 1.3), même NAT hole punching, même vérification Blake3, mêmes téléchargements résumables. C’est dispo sous Windows, macOS (Intel et Apple Silicon), et Linux (deb et AppImage) et comme d’hab, le projet est open-source sous licence AGPL-3.0.

En février dernier, les dev ont ajouté le support navigateur via WebAssembly, ce qui signifie qu’à terme, vous pourrez faire du P2P directement depuis votre navigateur. Ils bossent aussi sur QUIC Multipath, une extension qui permet d’utiliser plusieurs chemins réseau simultanément pour encore plus de performance et de résilience.

L’idée derrière Iroh, c’est donc de redonner aux internautes le contrôle de leurs réseaux plutôt que de tout centraliser comme des teubés sous crack sur des serveurs Amazon, Google ou Microsoft. Ce protocole permet ainsi aux machines de se parler directement, comme Internet était censé fonctionner à l’origine.

SendMe et AltSendme ne sont que deux applications construites sur Iroh et ce protocole lui-même offre d’autres modules comme iroh-blobs (pour le transfert de fichiers verified) et iroh-gossip (pour la communication en temps réel). Vous pourriez donc construire du streaming vidéo avec priorisation de streams, du networking de jeux, de la communication temps réel, ou n’importe quelle app qui a besoin de connexions directes rapides et sécurisées entre devices, avec ce truc.

Merci à Lorenper pour le partage de cette découverte.

Et si je vous disais qu’il existe un futur où vous allez pouvoir vous connecter en SSH à votre serveur de production avec votre compte Google et que celui-ci serait totalement invisible aux yeux du monde ?

Et bien ça arrive bientôt et ça s’appelle SSH3 !

Alors déjà, pas de panique, je vais pas vous sortir le speech classique du “Oh regardez, un nouveau protocole qui va révolutionner le monde”. Non non, l’histoire est beaucoup plus tordue que ça car SSH3, c’est un symptôme d’un phénomène beaucoup plus gros qui est en train de se passer sous notre nez et qui est la “webisation” d’Internet (oui, je viens d’inventer ce mot).

Car pendant que tout le monde s’excitait tous sur ChatGPT et les IA génératives, des chercheurs belges de l’UCLouvain étaient tranquillement en train de planifier la disparition des serveurs SSH de la surface d’Internet. Et je dis bien “disparaître” dans le sens où votre serveur devient invisible aux scans de ports , car votre serveur SSH peut maintenant se planquer derrière ce qui ressemble à un banal site web.

Pour réussir ce tour de magie, SSH3 utilise HTTP/3 et QUIC au lieu du bon vieux protocole SSH traditionnel. Et là vous me dites “Mais Korben, c’est quoi le rapport avec l’invisibilité ?” Bah c’est simple, comme SSH3 tourne sur les mêmes ports que n’importe quel site HTTPS, impossible de distinguer un serveur SSH3 d’un serveur web lambda. Vous pourriez même planquer votre serveur SSH derrière une URL secrète… Tentez ensuite un scan de ports, et vous ne verrez rien de plus qu’un stupide serveur web…

Ce que j’appelle “webisation”, c’est en fait l’absorption totale de l’infrastructure système par les technologies du web. Et même SSH, le protocole le plus fondamental de l’administration système présent depuis 1995, va devoir capituler face à HTTP/3.

C’est la victoire finale du navigateur sur le terminal, et personne n’en cause vraiment… Avec SSH3, vous allez donc pouvoir utiliser vos certificats Let’s Encrypt pour authentifier votre serveur et le GitHub du projet explique que c’est plus sécurisé que les clés d’hôtes SSH classiques car votre terminal vérifiera le certificat comme le fait votre navigateur.

Mais attendez, le délire va encore plus loin puisque OAuth 2.0 et OpenID Connect sont également supportés nativement. Vous allez donc pouvoir vous connecter à votre serveur de prod avec votre compte Google, Microsoft ou GitHub. Et si j’en crois le draft IETF , c’est parfaitement légitime et sécurisé grâce à l’authentification HTTP standard.

Alors évidemment, l’idée de se logger sur un serveur critique avec son compte Gmail, ça peut faire peur mais on fait déjà confiance à ces mêmes providers pour notre authentification partout ailleurs, donc un de plus ou un de moins… Puis j’imagine que vous pourrez aussi mettre en place votre propre provider, ce qui vous permettra d’éviter les GAFAM tout en ayant une gestion plus simple des accès à vos machines.

Au niveau perfs, SSH3 établit une connexion en seulement 3 round-trips contre 5 à 7 pour SSH classique. Sur une connexion avec 100ms de latence, ça fait une différence énorme. Et en bonus SSH3 supporte le port forwarding UDP en plus du TCP. Cela veut dire que vous pouvez enfin “tunneler” du QUIC, du DNS ou du RTP correctement… Ce projet a explosé en décembre 2023 quand François Michel et Olivier Bonaventure ont publié leur papier mais attention, c’est encore expérimental. Les développeurs le répètent partout : Ne mettez pas ça en prod tout de suite !

Alors est-ce qu’on doit s’inquiéter de cette uniformisation des protocoles ?

Peut-être car si tout le monde utilise les mêmes briques de base, une faille dans QUIC ou HTTP/3 pourrait affecter absolument TOUT. Mais d’un autre côté, concentrer les efforts de sécurité sur moins de protocoles, c’est aussi moins de surface d’attaque à surveiller.

Maintenant pour tester SSH3, c’est simple si vous avez Go installé :

go install github.com/francoismichel/ssh3/cmd/...@latest

`ssh3-server -generate-selfsigned-cert localhost`

`ssh3 user@server`