Familles de relays déclarées : pourquoi la construction de chemins de Tor évite les circuits d'un même opérateur
Pendant la plus grande partie de son histoire, exploiter plus d'un relay Tor s'est accompagné d'un petit devoir administratif : une ligne MyFamily dans chaque torrc, listant les empreintes de tous les autres relays du même opérateur. Ce mécanisme a désormais quitté le réseau, et les opérateurs multi-relays déclarent leurs familles avec un successeur à base de clés. La raison d'être de l'option n'a pas changé, et cela mérite d'être rappelé à quiconque ajoute aujourd'hui un second relay.
À quoi sert une déclaration de famille
Une famille de relays est un ensemble de relays sous un même contrôle administratif : une personne, une organisation, ou un hôte faisant tourner plusieurs instances de tor. La déclaration existe pour la construction de chemins. Les clients de Tor évitent autant que possible de placer deux membres d'une même famille dans un même circuit, car un circuit dont l'entrée et la sortie appartiennent à la même partie est exactement le scénario d'une attaque de corrélation de bout en bout : l'entrée voit le client, la sortie voit la destination, et un opérateur unique détenant les deux vues peut les recouper.Lorsque deux relays déclarent qu'ils appartiennent à la même « famille », les clients de Tor ne les utilisent pas dans le même circuit.La documentation communautaire décrit l'option successeur de la même façon : FamilyID, précise-t-elle, indique simplement aux clients de Tor quels relays sont contrôlés par une seule entité, un opérateur ou une organisation, afin que les relays d'un même opérateur ne soient pas utilisés à plusieurs positions d'un même circuit. Sans ce signal, la sélection de chemins traite les relays apparentés comme des inconnus.
Lorsque les opérateurs oublient de déclarer
L'ancien concept reposait entièrement sur la tenue du registre par les opérateurs, sur chaque relay, et sur sa synchronisation. Un groupe partageant un opérateur mais sans déclaration est invisible pour la sélection de chemins : le réseau compte ses relays comme des participants indépendants. Cela fausse les statistiques de diversité utilisées pour décrire le réseau, et réduit la protection réelle des clients, car la règle côté client s'arrête exactement à la frontière de ce qui est déclaré. Le projet OrNetStats, du chercheur relay de longue date nusenu, suit ce sujet depuis des années. Il regroupe les relays en familles effectives - des relays avec une configuration MyFamily mutuelle - et parmi ses questions de fond figurent les groupes présentant d'éventuelles mauvaises configurations MyFamily et ceux qui font peser sur les utilisateurs de Tor un risque de corrélation de bout en bout. Son rapport dédié ne liste des opérateurs que si la combinaison est réaliste : probabilités de guard et de exit supérieures à zéro, famille absente ou mal configurée, et relays répartis sur plus d'un bloc de réseau /16 - autrement dit, des groupes susceptibles de réellement tenir les deux bouts d'un circuit. Une fois la famille correctement configurée, note le rapport, les relays disparaissent de la page en un jour ou deux. Les informations de contact font partie de la même histoire. ContactInfo est une chaîne non authentifiée, et OrNetStats relève que cela a permis d'usurper l'identité d'autres opérateurs de relays, un phénomène déjà exploité dans la nature selon le projet. Il affiche donc, lorsque c'est possible, des identifiants d'opérateur authentifiés (AROI), qui lient les données de contact à un contrôle DNS ou de serveur web que l'opérateur doit réellement détenir.De MyFamily à Happy Families
L'ancien mécanisme montait aussi mal en charge. Chaque relay devait lister tous les autres membres, et chaque changement obligeait tous les membres à modifier leur configuration. La proposition 321, rédigée par Nick Mathewson en mai 2020, a chiffré le coût : selon sa mesure de février 2025, les déclarations de famille représentaient plus de 55 pour cent du contenu des microdescripteurs, et l'ajout ou le retrait d'un serveur imposait de modifier le torrc de tous les autres. Un appel à commentaires de novembre 2021 sur une manière plus simple de déclarer les familles a recueilli des retours d'opérateurs, dont nusenu, et le concept retenu conserve la propriété de sécurité en changeant la mécanique : l'opérateur génère une clé de signature de famille une seule fois, la remet à chaque relay de la famille et définit l'option FamilyId. L'appartenance est prouvée par des certificats dans les descripteurs, et les autorités d'annuaire publient des lignes family-ids compactes plutôt que des listes d'empreintes quadratiques. Le guide communautaire baptise ce design Happy Families ; il est implémenté dans la série Tor 0.4.9 et dans Arti 1.4.1. La transition s'est achevée en 2026. La série 0.4.8 - la dernière à exiger MyFamily en plus du nouveau mécanisme - a atteint sa fin de vie le 1er juin, et le 1er septembre a été fixé comme la date à partir de laquelle les clients 0.4.8 et antérieurs ne seraient plus maintenus fonctionnels sur le réseau, les anciennes lignes de famille devenant obsolètes pour économiser de la bande passante d'annuaire. Le portail communautaire indique désormais sans détour que MyFamily a été retiré et oriente les opérateurs multi-relays vers FamilyID et une ContactInfo valide. Les outils suivent : le rôle ansible-relayor a supprimé la prise en charge de MyFamily dans sa version de juin 2026, toutes les versions de tor prises en charge parlant le nouveau design.Conseils pratiques pour les opérateurs multi-relays
- Exécuter une version de tor prise en charge sur chaque relay ; le réseau ne transporte plus les anciennes lignes de famille.
- Générer une clé de famille avec tor --keygen-family, copier le fichier de clé dans le KeyDir de chaque relay, ajouter une ligne FamilyId au torrc et recharger.
- Rotérer les clés par étapes : déployer la nouvelle FamilyId à côté de l'ancienne, attendre quelques jours la propagation, puis retirer l'ancienne ligne.
- Définir une ContactInfo fonctionnelle - toujours exigée des opérateurs multi-relays - et envisager de publier un AROI afin que l'identité d'opérateur ne puisse être usurpée.
- Vérifier comment le réseau vous voit : les pages de familles d'OrNetStats et son rapport de corrélation de bout en bout montrent si vos relays sont correctement regroupés.