Relay-Familien deklarieren: Warum Tor-Paths keine Circuits eines einzelnen Betreibers kombinieren
Für den größten Teil seiner Geschichte bedeutete der Betrieb von mehr als einem Tor-Relay eine kleine administrative Aufgabe: eine MyFamily-Zeile in jeder torrc, mit den Fingerprints aller anderen Relays unter der Kontrolle desselben Betreibers. Dieser Mechanismus hat das Netz inzwischen verlassen, und Betreiber mehrerer Relays deklarieren ihre Familien nun mit einem schlüsselbasierten Nachfolger. Der Grund, warum es die Option gab, hat sich nicht geändert - und lohnt sich für alle, die heute ein zweites Relay hinzufügen, noch einmal in Erinnerung zu rufen.
Wozu eine Familien-Deklaration dient
Eine Relay-Familie ist eine Gruppe von Relays unter einheitlicher Verwaltung: eine Person, eine Organisation oder ein Host mit mehreren tor-Instanzen. Die Deklaration existiert für die Pfadauswahl. Tor-Clients platzieren nach Möglichkeit nicht zwei Mitglieder derselben Familie in einem Circuit, denn ein Circuit, dessen Ein- und Ausgang derselben Partei untersteht, ist genau das Szenario eines End-to-End-Korrelationsangriffs: Der Eingang sieht den Client, der Ausgang sieht das Ziel, und wer beide Ansichten hält, kann sie zusammenführen.Wenn zwei Relays erklären, dass sie zur selben 'Familie' gehören, verwenden Tor-Clients sie nicht im selben Circuit.Die Community-Dokumentation beschreibt die Nachfolgeoption auf dieselbe Weise: FamilyID, so heißt es, teilt Tor-Clients schlicht mit, welche Relays von einer einzigen Entität, einem Betreiber oder einer Organisation kontrolliert werden, damit Relays desselben Betreibers nicht in mehreren Positionen eines Circuits landen. Ohne dieses Signal behandelt die Pfadauswahl verwandte Relays als Fremde.
Wenn Betreiber die Deklaration vergessen
Das alte Design hing allein davon ab, dass Betreiber die Buchführung auf jedem Relay erledigen und aktuell halten. Eine Gruppe mit gemeinsamem Betreiber, aber ohne Deklaration, ist für die Pfadauswahl unsichtbar: Das Netz zählt ihre Relays als unabhängige Teilnehmer. Das verzerrt die Diversitätsstatistiken, mit denen das Netz beschrieben wird, und es schmälert den Schutz, den Clients tatsächlich erhalten, denn die Regel auf Client-Seite endet exakt an der Grenze des Deklarierten. Das Projekt OrNetStats des langjährigen Relay-Forschers nusenu verfolgt das seit Jahren. Es fasst Relays zu effektiven Familien zusammen - Relays mit wechselseitig konfigurierter MyFamily-Einstellung -, und zu seinen Dauerfragen gehören, welche Relay-Gruppen mögliche MyFamily-Fehlkonfigurationen aufweisen und welche durch End-to-End-Korrelation ein Risiko für Tor-Nutzer darstellen. Der spezielle Bericht listet Betreiber nur, wenn die Kombination realistisch ist: Guard- und Exit-Wahrscheinlichkeit über null, keine sauber konfigurierte Familie und Relays verteilt auf mehr als einen /16-Netzblock - mit anderen Worten Gruppen, die tatsächlich beide Enden eines Circuits halten könnten. Ist die Familie korrekt konfiguriert, verschwinden die Relays dem Bericht zufolge binnen ein bis zwei Tagen von der Seite. Kontaktinformationen gehören zur selben Geschichte. ContactInfo ist eine nicht authentifizierte Zeichenkette, und OrNetStats vermerkt, dass sich daraus ermöglichte, sich für andere Relay-Betreiber auszugeben - etwas, das laut dem Projekt bereits in der Praxis ausgenutzt wurde. Daher zeigt OrNetStats, wo verfügbar, authentifizierte Relay-Betreiber-IDs (AROI), die die Kontaktdaten an eine DNS- oder Webserver-Kontrolle binden, die der Betreiber wirklich halten muss.Von MyFamily zu Happy Families
Der alte Mechanismus skalierte zudem schlecht. Jedes Relay musste jedes andere Mitglied auflisten, und jede Änderung verlangte eine Anpassung bei allen Mitgliedern. Proposal 321, verfasst von Nick Mathewson im Mai 2020, bezifferte die Kosten: Nach seiner Messung vom Februar 2025 machten Familien-Deklarationen über 55 Prozent des Microdescriptor-Inhalts aus, und das Hinzufügen oder Entfernen eines Servers erforderte torrc-Änderungen auf allen übrigen Servern. Ein Feedback-Aufruf im November 2021 zu einem einfacheren Weg, Familien zu deklarieren, stieß auf Resonanz von Betreibern, nusenu eingeschlossen. Der daraus entstandene Entwurf bewahrt die Sicherheitseigenschaft und ändert die Mechanik: Der Betreiber erzeugt einmalig einen Familiensignaturschlüssel, übergibt ihn an jedes Familien-Relay und setzt die Option FamilyId. Die Mitgliedschaft wird über Zertifikate in den Relay-Deskriptoren nachgewiesen, und die Directory Authorities veröffentlichen kompakte family-ids-Zeilen statt quadratischer Fingerprint-Listen. Der Community-Leitfaden nennt das Design Happy Families; umgesetzt ist es in der Tor-0.4.9-Serie und in Arti 1.4.1. Der Übergang schloss sich 2026 ab. Die 0.4.8-Serie - die letzte, die MyFamily neben dem neuen Mechanismus verlangte - erreichte am 1. Juni ihr End-of-Life, und der 1. September wurde als Datum festgelegt, nach dem Clients ab 0.4.8 nicht mehr funktionierend gehalten würden; die alten Familienzeilen wurden obsolet, um Directory-Bandbreite zu sparen. Das Community-Portal stellt inzwischen klar, dass MyFamily entfernt wurde, und verweist Betreiber mehrerer Relays an FamilyID und eine gültige ContactInfo. Auch die Werkzeuge folgten: Die ansible-relayor-Rolle entfernte die MyFamily-Unterstützung in ihrer Juni-Veröffentlichung 2026 - alle unterstützten tor-Versionen sprechen das neue Design.Praktische Hinweise für Betreiber mehrerer Relays
- Auf jedem Relay eine unterstützte tor-Version betreiben; das Netz trägt die alten Familienzeilen nicht mehr.
- Einen Familienschlüssel mit tor --keygen-family erzeugen, die Schlüsseldatei in das KeyDir jedes Relays kopieren, eine FamilyId-Zeile in die torrc eintragen und neu laden.
- Schlüssel in Etappen rotieren: die neue FamilyId neben der alten ausrollen, einige Tage auf die Verbreitung warten, dann die alte Zeile entfernen.
- Eine funktionierende ContactInfo setzen - für Betreiber mehrerer Relays stets Pflicht - und gegebenenfalls ein AROI veröffentlichen, damit die Betreiber-Identität nicht gefälscht werden kann.
- Prüfen, wie das Netz einen sieht: Die Familienseiten von OrNetStats und der End-to-End-Korrelationsbericht zeigen, ob die eigenen Relays korrekt gruppiert sind.