Comment héberger un site .onion : services onion, adresses v3 et fuites qui démasquent

Qu'est-ce qu'un service onion, concrètement ?

Un service onion est un serveur qui ne révèle jamais où il se trouve. Plutôt que de publier une adresse dans le DNS et d'attendre les connexions, il construit des circuits sortants à travers le réseau Tor vers une poignée de relais qu'il choisit comme points d'introduction, et publie un descripteur signé indiquant « quiconque détient cette clé peut être joint via ces relais ». Un client qui connaît l'adresse récupère ce descripteur, choisit un troisième relais comme point de rendez-vous, et demande à un point d'introduction de transmettre une requête pour s'y retrouver. Les deux parties construisent chacune leur propre circuit vers le point de rendez-vous, et aucune des deux n'apprend jamais l'adresse IP de l'autre, car elle ne lui est jamais communiquée.

L'adresse elle-même est la partie intéressante. Une adresse onion v3 compte 56 caractères en base32 suivis de .onion, et ce n'est pas un nom qui pointe vers une clé — elle est la clé : une clé publique ed25519, une somme de contrôle et un octet de version, encodés. Il n'y a rien à consulter ni personne à qui faire confiance. Quand votre client se connecte, le descripteur qu'il récupère est signé par cette clé exacte, si bien que l'adresse authentifie le service par construction. Aucune autorité de certification n'intervient, personne ne peut émettre de certificat pour votre adresse, et aucun registre de transparence ne consigne l'existence du service. La spécification du rendez-vous vaut la lecture si vous voulez la mécanique complète de la poignée de main.

Cette liste résume à elle seule tout l'intérêt du dispositif, et elle explique la diversité des personnes qui en font tourner. Les instances SecureDrop des rédactions sont des services onion parce qu'une source ne devrait pas avoir à faire confiance au DNS. Debian met en miroir son archive via des services onion pour que l'acte de mettre à jour un paquet ne soit pas visible comme une destination. Plusieurs très grandes plateformes grand public en publient un pour que les internautes des réseaux censurés puissent les joindre sans qu'une IP bloquée ne s'interpose. Rien d'exotique là-dedans : c'est un transport avec un jeu de garanties différent.

Ce que le protocole protège, et ce qu'il ne peut pas protéger

La garantie du protocole est étroite mais solide : la couche réseau ne révèle pas où tourne le service. Un adversaire capable d'observer de vastes portions d'Internet ne peut toujours pas résoudre votre adresse vers une machine, car il n'existe aucune étape de résolution à observer. On ne peut pas remettre l'adresse à un hébergeur en lui demandant à quel client elle appartient, car rien, du côté de l'hébergeur, ne le sait. Les scanners ne peuvent pas trouver le service, puisqu'il ne répond sur aucun port public. Et une attaque qui submergerait un site ordinaire n'a nulle part où viser, ce qui explique que ce sujet revienne aussi souvent dans les discussions sur le DDoS que dans celles sur la vie privée.

Tout ce qui se trouve au-dessus de la couche réseau reste à votre charge, et c'est là que se trouve l'historique réel des échecs. Des services ont été localisés parce que l'application affichait une trace d'erreur contenant un vrai nom d'hôte, parce que le même serveur web répondait sur l'IP publique avec une page identique, parce qu'un certificat pour un autre domaine de l'exploitant était installé sur la même machine, parce qu'une image portait des coordonnées GPS dans ses métadonnées, parce que la machine envoyait du courrier qui traversait l'Internet ouvert, ou parce qu'un point de terminaison de statut laissé ouvert au monde entier listait l'adresse du serveur lui-même. Tor a fait son travail dans chacun de ces cas. La personne au-dessus ne l'a pas fait.

Il faut donc garder deux idées en tête à la fois. Le transport est solide, et l'est depuis des années ; le traiter comme le maillon faible, c'est mal lire la façon dont ces enquêtes se sont réellement déroulées. Et le transport est aussi la moitié facile — la moitié difficile est une discipline sur tout ce que la machine dit et fait, ce dont traite l'essentiel du reste de ce guide. Si vous êtes ici pour une question plus large sur la traçabilité d'un serveur loué, la version honnête de cette réponse complète bien cette page.

Mettre en place un service onion : deux directives et un redémarrage

La configuration est vraiment minime, ce qui surprend ceux qui s'attendaient à quelque chose de cérémonieux. Installez le démon tor, puis ajoutez deux directives à torrc : un HiddenServiceDir désignant un répertoire que Tor va créer et posséder, et un HiddenServicePort qui fait correspondre le port virtuel utilisé par les appelants à l'adresse locale sur laquelle écoute votre application. Redémarrez, et Tor génère une paire de clés ed25519 et écrit votre adresse dans un fichier hostname à l'intérieur de ce répertoire.

L'erreur la plus fréquente, et de loin, se trouve dans la troisième ligne. Une installation par défaut d'un serveur web écoute sur 0.0.0.0, c'est-à-dire l'adresse IPv4 publique, et généralement l'adresse IPv6 aussi. Placez un service onion devant, et vous servez désormais les mêmes octets à deux endroits, dont l'un est indexé par tous les scanners d'Internet. Quiconque compare un hash de page, un favicon, un ETag ou une page d'erreur caractéristique les relie en quelques secondes. Liez-vous à 127.0.0.1, puis vérifiez-le avec ss -ltnp plutôt que de le supposer — la vérification prend cinq secondes, et cette supposition a coûté à certains absolument tout.

Sauvegardez hs_ed25519_secret_key quelque part de chiffré et hors de la machine avant d'aller plus loin. Ce fichier n'est pas associé à l'adresse ; il est l'adresse. Perdez-le, et l'adresse disparaît définitivement, sans récupération possible et sans appel. Divulguez-le, et n'importe qui d'autre peut monter un service qui répond pour votre adresse et qui est cryptographiquement indiscernable de vous. Traitez-le comme une clé de signature, ce qu'il est — et si le disque sur lequel il vit est loué, chiffrer ce disque est l'étape complémentaire évidente, avec les réserves que ce guide détaille.

Fermez ensuite la porte d'entrée. Un service onion n'a besoin d'absolument aucun port entrant — chaque connexion qu'il utilise, c'est lui qui l'a ouverte, en sortant, vers le réseau Tor. Vous pouvez bloquer tout le trafic entrant au niveau du pare-feu et le service continue de fonctionner parfaitement. Presque rien d'autre de ce que vous pouvez héberger n'offre cela, et cela élimine toute une catégorie d'attaques qui commencent par un scan de ports. Faites aussi transiter votre propre accès d'administration par Tor, et la machine cesse tout simplement de répondre à Internet.

Adresses v3, préfixes vanity, et le problème de phishing qu'ils créent

Si un tutoriel que vous lisez mentionne des adresses à 16 caractères, c'est qu'il décrit un protocole qui n'existe plus. Les services onion en version 2 utilisaient des hachages RSA-1024 sur 80 bits, assez courts pour être séduisants et assez faibles pour poser problème ; ils étaient aussi énumérables, car quiconque faisait tourner un relais d'annuaire pouvait récolter les adresses qui y transitaient. Le Tor Project a annoncé le calendrier de dépréciation en 2020, désactivé la v2 dans la série 0.4.6 en juillet 2021, puis retiré le code entièrement en octobre de la même année. Les adresses en version 3 comptent 56 caractères, reposent sur ed25519, et ne fuitent plus via les relais d'annuaire.

Cette longueur est le prix à payer, et c'est pour cela que les adresses vanity existent. Des outils comme mkp224o génèrent des paires de clés en masse et ne conservent que celles dont l'adresse commence par un préfixe choisi. Cela n'affaiblit rien : vous ne contraignez pas la clé, vous éliminez des candidates jusqu'à ce que l'une d'elles encode par hasard les lettres voulues, et la survivante est exactement aussi solide que n'importe quelle autre. Ce que cela coûte, c'est du temps, et le coût est exponentiel — chaque caractère supplémentaire multiplie le travail par 32, si bien qu'un préfixe de quatre caractères est instantané sur un portable, six ou sept caractères demandent une machine qui tourne pendant des heures, et dix deviennent une véritable entreprise. Personne ne force par brute une adresse complète de 56 caractères ; c'est tout l'intérêt de l'espace de recherche.

Le vrai danger est le miroir exact de l'avantage. Si un préfixe reconnaissable aide vos utilisateurs à vous identifier, il aide tout aussi bien quelqu'un d'autre à générer un quasi-doublon et à le poser sur une page de phishing, car les huit caractères qu'un humain lit réellement sont la seule partie qu'il vérifie. Défendez-la comme on a toujours défendu les empreintes de clé : publiez l'adresse complète à plusieurs endroits indépendants, signez-la avec une clé que vos utilisateurs possèdent déjà, placez-la dans l'en-tête Onion-Location de votre site en clair si vous en avez un, et annoncez clairement que vous ne communiquerez jamais une nouvelle adresse uniquement sur les réseaux sociaux. Un préfixe vanity est une fonctionnalité d'ergonomie, pas d'authentification.

La surface de fuite qui a réellement démasqué des services

C'est la section qui compte vraiment. Le schéma est le même dans chaque cas documenté publiquement : la couche réseau a tenu, et quelque chose au-dessus a désigné une machine précise, une personne précise, ou une autre propriété précise. La plupart de ces fuites sont banales, toutes sont vérifiables en une après-midi, et cette vérification, c'est le vrai travail.

Deux d'entre elles méritent d'être soulignées, car elles piègent même les gens prudents. La première est le trafic sortant : une machine qui n'accepte jamais de connexion peut encore s'annoncer en en initiant une. Les mises à jour de paquets sont normales et inévitables ; un agent de supervision qui remonte vers un tableau de bord associé à votre nom ne l'est pas, pas plus qu'une application qui envoie des courriels de réinitialisation de mot de passe via l'Internet ouvert depuis une machine dont tout l'intérêt est de ne pas être localisée. La seconde est la clé d'hôte SSH. La réutiliser d'une machine à l'autre est une habitude qui paraît soignée mais qui crée un lien cryptographique permanent et interrogeable entre deux serveurs censés n'avoir aucun rapport.

Faites cet audit en tant qu'étranger, pas en tant qu'exploitant. Ouvrez le service dans Tor Browser depuis une machine qui n'a jamais touché au projet, lisez chaque en-tête de réponse, déclenchez une erreur volontairement, affichez le code source d'une page que vous n'avez pas écrite vous-même, et surveillez le panneau réseau pour tout ce que la page va chercher ailleurs. Puis installez-vous sur le serveur et observez ce qui en sort pendant une journée entière. Ce que vous trouverez ce jour-là, c'est tout l'objet de ce guide.

Autorisation client : un service que seules certaines personnes peuvent joindre

Il existe un mode que la plupart des gens ignorent, et c'est ce qu'il y a de plus élégant dans le protocole. Avec l'autorisation client, le descripteur que publie votre service est chiffré pour un ensemble de clés publiques x25519 que vous désignez. Un client qui ne possède pas la clé privée correspondante ne peut même pas déchiffrer le descripteur, ce qui signifie qu'il ne peut pas apprendre les points d'introduction, ce qui signifie qu'il ne peut pas se connecter — et ne peut même pas confirmer que quelque chose existe là. Vous déposez les clés publiques des clients dans un répertoire authorized_clients à côté des clés du service, un fichier par client, et vous redémarrez.

Comparez cela aux façons habituelles de restreindre l'accès. Une liste blanche d'IP suppose de savoir où se trouvent vos utilisateurs, et laisse un service répondre à Internet pour que tous les autres puissent le scanner et le prendre en empreinte. Une authentification HTTP basique laisse une invite de connexion bien visible, annonçant que quelque chose existe. Un VPN ajoute tout un second système à faire tourner, avec sa propre adresse à exposer. L'autorisation client retire le service de la vue de quiconque n'est pas sur la liste, ce qui est une propriété d'une tout autre nature : non pas une porte verrouillée, mais l'absence même de porte.

Le terrain naturel, ce sont les surfaces d'administration. Placez le site public sur un service onion ordinaire, et le panneau d'admin, le tableau de bord de métriques, la console de base de données et le point d'entrée SSH derrière des services onion autorisés séparés : les parties de votre déploiement qui seraient sinon sondées en continu deviennent tout simplement introuvables. Le coût, c'est la distribution des clés — chaque client doit avoir sa clé privée installée dans sa configuration Tor — ce qui convient à une poignée d'exploitants mais devient impraticable pour un public large. Réservez-la aux cas où l'audience se compte sur les doigts.

Latence, redondance, et les compromis à assumer honnêtement

Une connexion onion traverse six relais : trois choisis par le client, trois choisis par le service, qui se rejoignent au milieu. C'est le prix à payer pour qu'aucune des deux extrémités ne connaisse l'autre, et cela se traduit en latence plutôt qu'en bande passante — le premier octet est lent, le débit ensuite est généralement correct. Concevez en conséquence : moins d'allers-retours, un cache agressif, pas de chaînes de requêtes bavardes, pas de page qui a besoin de onze sous-ressources avant de s'afficher. Un site agréable à utiliser via un service onion est généralement un site qui était déjà bien construit au départ.

Si votre service n'a pas lui-même besoin d'anonymat de localisation — une grande plateforme publique qui publie une adresse onion uniquement pour que les utilisateurs censurés puissent la joindre, par exemple — Tor propose un mode « single onion service » qui utilise un chemin à un seul saut côté service. Cela divise à peu près par deux la latence et abandonne explicitement l'anonymat propre du service, et le nom de la directive de configuration le dit en toutes lettres. C'est la bonne réponse pour une organisation connue, et exactement la mauvaise réponse pour quiconque cherche à protéger sa propre localisation. Choisissez-le délibérément, ou pas du tout.

La redondance mérite une remarque, car l'approche naïve échoue. Vous ne pouvez pas simplement copier le matériel de clés sur une seconde machine et faire tourner les deux — deux services qui publient des descripteurs pour la même adresse se disputent l'annuaire, et les clients atterrissent de façon imprévisible. OnionBalance existe précisément pour cela : une instance frontale détient l'adresse publique et publie un descripteur pointant vers les points d'introduction de plusieurs services backend, chacun avec sa propre clé. Les backends peuvent être reconstruits ou déplacés un par un sans que l'adresse ne change jamais.

Faire tourner un service onion à côté d'un site ordinaire

Beaucoup de services onion sont une seconde porte d'entrée vers quelque chose qui existe déjà publiquement, et c'est un projet différent d'un service dont la localisation est secrète. Décidez lequel des deux vous construisez avant d'écrire la moindre configuration, car les deux veulent des choses opposées. Si l'objectif est la résistance à la censure pour un site que tout le monde sait déjà être le vôtre, relier les deux est justement la fonctionnalité recherchée : publiez un en-tête Onion-Location sur le site en clair, et Tor Browser proposera automatiquement l'adresse onion aux visiteurs. Si l'objectif est que personne ne sache où tourne le service, alors chaque lien entre les deux est une fuite, et le bon nombre de liens est zéro.

C'est la demi-mesure qui fait mal. Faire tourner les deux depuis une seule machine, avec une seule base de données, un seul domaine de cookie de session et un seul jeu de fichiers téléversés, tout en se disant que les deux audiences sont séparées, signifie qu'une seule erreur de configuration effondre la distinction — et vous ne le découvrirez que lorsque quelqu'un d'autre l'aura fait avant vous. Si les deux doivent exister et ne doivent pas être reliés, ce sont deux déploiements sur deux machines avec deux jeux d'identifiants, et le coût opérationnel de cela est le prix de la propriété que vous vouliez.

Un détail pratique si vous les reliez malgré tout : cantonnez les sessions et les cookies par hôte. Un utilisateur qui se connecte sur le site en clair puis arrive via l'adresse onion devrait obtenir une session neuve, pas une session partagée, sinon vous avez construit un mécanisme qui corrèle les deux visites pour quiconque peut observer l'une ou l'autre. Et servez à l'adresse onion ses propres liens canoniques, pour que le site ne redirige pas obligeamment un utilisateur de Tor Browser vers l'hôte en clair qu'il a délibérément évité.

Ce que l'hébergeur doit vraiment réussir de son côté

Les exigences sont inhabituelles, ce qui explique pourquoi un hébergeur généraliste convient souvent mal. Il vous faut un chemin sortant sans entrave vers le réseau Tor, car c'est le seul type de connexion que votre service établit ; certains fournisseurs filtrent purement et simplement le trafic d'annuaire et de relais Tor, et vous le découvrirez sous la forme d'un service qui ne publie jamais de descripteur. Il vous faut un fournisseur dont la politique d'utilisation acceptable aborde Tor par écrit plutôt que par le silence, car le silence est ce qui se transforme en courriel de résiliation la première fois que quelqu'un se plaint de quelque chose de totalement sans rapport. Vous n'avez besoin ni d'une IP stable, ni d'un domaine, ni d'un certificat, ni d'un quelconque port entrant — ce qui rend hors sujet la plupart de ce que les hébergeurs vendent comme éléments différenciants.

Le profil d'abus est la bonne surprise. Un nœud de sortie établit des connexions vers l'Internet ouvert pour le compte d'inconnus et collecte donc des plaintes ; c'est le contrat implicite, et c'est pourquoi les sorties ont besoin d'un fournisseur avec une position clairement documentée. Un service onion fait l'inverse : chaque connexion vient du réseau Tor, il ne contacte jamais l'Internet ouvert pour le compte de qui que ce soit, et par conséquent il ne génère quasiment aucun courrier d'abus. C'est une charge bien plus tranquille à héberger que le relais d'à côté, et bien plus tranquille qu'un serveur web public.

Chez BitVPS, Tor est autorisé par écrit — relais, ponts, sorties et services onion à égalité, le cas des sorties étant documenté sur la page abus plutôt que laissé au hasard. La page d'hébergement Tor couvre le dimensionnement des relais ; les services onion sont plus légers. Concrètement, une Growth à $13.50 avec 4 vCPU, 8 Go de RAM et une liaison illimitée fait tourner un service onion sérieux avec de la marge pour l'application derrière, et une Starter à $8.50 suffit pour un petit service. Choisissez l'emplacement pour sa posture légale plutôt que pour sa latence : avec six sauts, la différence entre un datacentre proche et un datacentre lointain devient quasiment invisible.

La page réseau publie l'ASN et le peering, ce qui compte ici pour une raison indirecte. Vous n'exposez aucune adresse, donc la raison habituelle de se soucier du réseau d'un fournisseur disparaît — mais un hébergeur qui documente publiquement son infrastructure est aussi un hébergeur qui a couché par écrit ce qu'il fait quand on l'interroge au sujet d'un client, et c'est cela que vous achetez réellement.

Où se situe la limite

Autant être direct sur ce point, car cette technologie traîne une réputation qui ne correspond pas au trafic réel. Les services onion sont un transport doté d'une propriété de confidentialité précise, et les personnes qui en font tourner sont très majoritairement ordinaires : des rédactions qui reçoivent des tuyaux, une archive de paquets qui ne veut pas journaliser quelle machine a récupéré quelle mise à jour, des projets de messagerie et d'auto-hébergement, des habitants de pays où l'Internet ordinaire est filtré, et des administrateurs qui préfèrent simplement que leur interface d'administration ne soit pas scannable. En faire tourner un est licite dans la grande majorité des juridictions, et ce n'est pas une déclaration sur ce que vous hébergez.

Ce que ce n'est pas, en revanche, c'est un changement des règles. Un fournisseur qui ignore les notifications de droit d'auteur — ce qui est notre cas, comme ce guide l'explique — agit tout de même contre les contenus d'abus sexuel sur mineurs et les menaces crédibles envers des personnes, et agit vite : notre délai publié est de quatre heures pour ces cas-là, contre quarante-huit pour tout le reste. Ce n'est pas une faille dans une politique par ailleurs permissive, c'est la politique elle-même, et aucun transport ne la change. La politique d'utilisation acceptable est courte et vaut la peine d'être lue avant de construire, pas après.

L'autre remarque honnête, c'est que l'anonymat est une propriété de système, pas un produit qu'on achète. L'adresse cache la machine ; elle ne cache pas une trace de paiement, un mot de passe réutilisé, un style d'écriture, un domaine que vous avez enregistré des années plus tôt avec le même e-mail, ou une capture d'écran contenant vos propres chemins de système de fichiers. Si le modèle de menace est sérieux, le transport en est la partie la plus facile, et celle à laquelle vous consacrerez le moins de temps. Le parcours plus large couvre le reste de cette chaîne, et l'explicatif sur le bulletproof hosting est un antidote utile au marketing qui entoure tout ce sujet.