Aangegeven relayfamilies: waarom Tor geen circuits bouwt met twee relays van dezelfde beheerder
Het draaien van meer dan één Tor-relay hoorde jarenlang een kleine administratieve klus bij: een MyFamily-regel in elke torrc, met de vingerafdrukken van alle andere relays van dezelfde beheerder. Dat mechanisme heeft het netwerk inmiddels verlaten, en beheerders van meerdere relays geven hun families aan met een op sleutels gebaseerde opvolger. De reden waarom de optie bestond is onveranderd, en wie vandaag een tweede relay toevoegt doet er goed aan die nog eens te horen.
Waarom een familieaanduiding bestaat
Een relayfamilie is een set relays onder één administratieve controle: één persoon, één organisatie, of één host met meerdere tor-instanties. De aanduiding bestaat voor de padkeuze. Tor-clients proberen geen twee leden van dezelfde familie in één circuit te plaatsen, want een circuit waarvan de ingang en de uitgang aan dezelfde partij toebehoren is precies het scenario van een end-to-endcorrelatieaanval: de ingang ziet de client, de uitgang ziet de bestemming, en één beheerder die beide zichten houdt kan ze aan elkaar koppelen.Als twee relays aangeven tot dezelfde 'familie' te behoren, gebruiken Tor-clients ze niet in hetzelfde circuit.De communitydocumentatie beschrijft de opvolger precies zo: de FamilyID, aldus de tekst, vertelt Tor-clients simpelweg welke relays door één entiteit, beheerder of organisatie worden bestuurd, zodat relays van dezelfde beheerder niet op meerdere posities in één circuit terechtkomen. Zonder dat signaal behandelt de padkeuze verwante relays als vreemden.
Als beheerders vergeten aan te geven
Het oude ontwerp hing volledig af van beheerders die op elke relay de administratie bijhielden en sync hielden. Een groep met dezelfde beheerder maar zonder aanduiding is onzichtbaar voor de padkeuze: het netwerk telt haar relays als onafhankelijke deelnemers. Dat vertekent de diversiteitsstatistieken waarmee het netwerk wordt beschreven en beperkt de bescherming die clients werkelijk krijgen, want de clientregel stopt precies bij de grens van wat is aangegeven. Het project OrNetStats van de ervaren relayonderzoeker nusenu volgt dit al jaren. Het groepeert relays in effectieve families - relays met een onderling geconfigureerde MyFamily-instelling - en tot de vaste vragen horen welke relaygroepen mogelijk verkeerd geconfigureerde families hebben en welke een end-to-endcorrelatierisico vormen voor Tor-gebruikers. Het eigen rapport noemt beheerders alleen als de combinatie realistisch is: guard- en exitkans boven nul, geen goed geconfigureerde familie en relays verspreid over meer dan één /16-netwerkblok - met andere woorden, groepen die werkelijk beide einden van een circuit zouden kunnen houden. Zodra de familie goed is ingesteld, verdwijnen de relays volgens het rapport binnen een dag of twee van de pagina. Contactinformatie hoort bij hetzelfde verhaal. ContactInfo is een niet-geverifieerde tekenreeks, en OrNetStats meldt dat kwaadwillenden zich hiermee voor andere relaybeheerders konden uitgeven - iets dat volgens het project al in de praktijk is misbruikt. Daarom toont het, waar beschikbaar, geverifieerde beheerdersidentificaties (AROI), die contactgegevens koppelen aan een DNS- of webservercontrole die de beheerder echt moet hebben.Van MyFamily naar Happy Families
Het oude mechanisme schaalde bovendien slecht. Elke relay moest alle andere leden opnoemen, en elke wijziging vereiste dat alle leden hun configuratie aanpasten. Voorstel 321, geschreven door Nick Mathewson in mei 2020, zette een cijfer bij de kosten: familieaanduidingen vormden bij de meting van februari 2025 ruim 55 procent van de microdescriptorinhoud, en het toevoegen of verwijderen van een server vereiste een torrc-wijziging bij alle andere. Een oproep om feedback in november 2021 over een eenvoudiger manier om families aan te geven kreeg antwoord van beheerders, waaronder nusenu, en het ontwerp dat volgde behoudt de beveiligingseigenschap maar verandert de werking: de beheerder genereert één keer een ondertekeningssleutel voor de familie, geeft die aan elke relay van de familie en zet de optie FamilyId. Het lidmaatschap wordt bewezen met certificaten in de relaydescriptors, en de directory-authorities publiceren compacte family-ids-regels in plaats van kwadratische vingerafdruklijsten. De communitygids noemt dit ontwerp Happy Families; het zit in de Tor-serie 0.4.9 en in Arti 1.4.1. De overgang sloot in 2026. De serie 0.4.8 - de laatste die MyFamily náást het nieuwe mechanisme vereiste - bereikte op 1 juni haar einde van de levensduur, en 1 september werd bepaald als de datum waarop clients van 0.4.8 en ouder niet meer functionerend gehouden zouden worden, met de oude familieregels als achterhaald om directorybandbreedte te besparen. Het communityportaal stelt nu onomwonden dat MyFamily is verwijderd en verwijst beheerders van meerdere relays door naar FamilyID en een geldige ContactInfo. De tools volgden: de ansible-relayor-rol schrapte MyFamily-ondersteuning in de release van juni 2026, nu alle ondersteunde tor-versies het nieuwe ontwerp spreken.Praktische richtlijnen voor beheerders van meerdere relays
- Draai op elke relay een ondersteunde tor-versie; het netwerk voert de oude familieregels niet meer mee.
- Genereer een familiesleutel met tor --keygen-family, kopieer het sleutelbestand naar de KeyDir van elke relay, voeg een FamilyId-regel toe aan de torrc en herlaad.
- Wissel sleutels in stappen: zet de nieuwe FamilyId naast de oude, wacht enkele dagen op verspreiding en verwijder dan de oude regel.
- Stel een werkende ContactInfo in - altijd vereist voor beheerders van meerdere relays - en overweeg een AROI te publiceren zodat uw beheerdersidentiteit niet kan worden nageaapt.
- Controleer hoe het netwerk u ziet: de familypagina's van OrNetStats en het correlatierapport laten zien of uw relays correct gegroepeerd zijn.