Der Ruhestands-Fahrplan für C tor: Sunset-Daten, der Stand von Arti und was Betreiber im Blick behalten sollten
Der Ruhestand von Tors ursprünglicher C-Implementierung hat sich von einem Grundsatz zu einem konkreten Zeitplan entwickelt. Am 23. Juni 2026 kündigte das Tor Project an, die Netzwerk-Kompatibilität einzustellen für Tor 0.4.8 und alle älteren Versionen: Nach dem 1. September 2026 werden diese Versionen "überhaupt nicht mehr im Netzwerk funktionieren". Die Ankündigung, verankert im laufenden Arti-Relay-Projekt, ist bislang das deutlichste öffentliche Signal dafür, wie der Übergang von C tor zu Rust gestaffelt wird.
Warum Tor in Rust neu geschrieben wird
Arti ist die Next-Generation-Implementierung der Tor-Protokolle in Rust, beschrieben im eigenen README des Projekts als Versuch, eine embedbare, produktionsreife Codebasis zu schaffen. Die genannten Gründe sind praktischer statt kosmetischer Natur. Das Team schätzt, dass mindestens die Hälfte der erfassten Sicherheitsschwachstellen in einer speichersicheren Sprache unmöglich gewesen wäre. Die C-Codebasis, seit 2002 in kontinuierlicher Entwicklung, hat laut demselben Dokument unnötige Spaghetti-Beziehungen zwischen Komponenten angesammelt. Und eine Rust-Bibliothek lässt sich in Anwendungen einbetten, wie es das ursprüngliche SOCKS-Proxy-Design nie vorgesehen hatte – was die Entwickler sich als Beschleunigung künftiger Arbeit erhoffen. Der Migrationszeitplan wurde im Februar 2023 von Nick Mathewson, Tors Mitgründer und einem der leitenden Arti-Architekten, in einer tor-dev-Diskussion umrissen:Mittelfristig werden wir die C-Tor-Client-Implementierung verwerfen. Das wird erst einige Zeit nach dem Punkt sein, an dem Arti ein vollständiger Tor-Client mit Unterstützung für Onion Services und einer vollständigen Embedding-/FFI-/RPC-Lösung ist.Langfristig soll Arti C tor nach Mathewsons Worten vollständig ersetzen, was auch Relays und Verzeichnisbehörden in Rust erfordert. Er betonte, dass kein Zeitplan festgelegt worden sei und dass jede spätere Zeitleiste aus mancher Perspektive ärgerlich lang und aus anderer ärgerlich kurz wirken würde. Drei Jahre später spielt sich die Sequenz weitgehend wie beschrieben ab: Zuerst wurde der Client fertig, die Kernrollen des Netzwerks zuletzt.
Was Arti heute kann – und was nicht
Als Client ist Arti in guter Verfassung. Das README, Stand August 2026, bezeichnet ihn als vollwertigen Tor-Client, geeignet für die allgemeine Client-Nutzung: Er läuft als SOCKS-Proxy, verbindet sich mit Onion Services und unterstützt Bridges mit Pluggable Transports inklusive obfs4 und Snowflake. Die Releases kommen stetig. Arti 2.0.0 erschien im Februar 2026, und die aktuelle Version, Arti 2.7.0, erschien am 1. Oktober 2026 mit weiterer Grundlagenarbeit für Relays und Verzeichnisbehörden sowie einer Reihe von Sicherheitsfixes. Diesen Fortschritt auf der Client-Seite haben wir in unserer früheren Arti-Berichterstattung ausführlicher betrachtet. Jenseits des Clients ist das ehrliche Bild dünner. Arti als Relay oder Verzeichnisbehörde zu betreiben wird noch nicht unterstützt, wie die Release Notes zu 2.0.0 direkt festhalten, und das Relay-README trägt eine dauerhafte Warnung: Relay-Unterstützung sei experimentell und "überhaupt nicht bereit für den allgemeinen Einsatz", mit der Bitte, kein Arti-Relay im öffentlichen Tor-Netzwerk zu betreiben. Die interne Checkliste des Projekts zeigt echten Fortschritt, etwa eingehende Kanäle, CREATE2- und EXTEND2-Verarbeitung und ORPort-Listening, während Staukontrolle, Descriptor-Veröffentlichung, Exit-Policies und Abwehr von Denial-of-Service noch offen sind. Onion Services stehen auf der Dienstseite ähnlich da. Die eigene Dokumentation des Projekts sagt, ein auf Arti betriebener Dienst sei nur für Tests und Experimente geeignet: Ihm fehlen Client-Autorisierung, Vanguard-Relays, aussagekräftige Denial-of-Service-Schutzmaßnahmen und Circuit Padding, und es wird gewarnt, dass der Betrieb sogar die Privatsphäre anderer Nutzungen derselben Arti-Instanz gefährden könnte. Sich als Client über Arti mit Onion Services zu verbinden, ist dagegen Teil des normalen Client-Betriebs.Der September-Sunset, erklärt
Die Frist zum 1. September ist ein Kompatibilitäts-Schritt, keine Sicherheitsfrist. Tor 0.4.8 hat laut dem Release-Kalender des Projekts bereits am 1. Juni 2026 das End of Life erreicht und erhält keine weiteren Updates. Was sich nach September ändert, ist das Verzeichnisprotokoll: Die 0.4.9-Serie streicht die alten TAP-Onion-Keys und Relay-Family-Zeilen aus den Verzeichnisdaten, wie in den Proposals 350 und 321 vorgesehen, was die Client-Bandbreite senkt und den Bootstrap für alle beschleunigt. Da Clients und Relays ab 0.4.8 abwärts das Vorhandensein der TAP-Keys erwarten, hören sie auf zu funktionieren, sobald diese Felder verschwinden. Eine zweite Motivation wird offen benannt: Die Arti-Implementierung einer Verzeichnisbehörde braucht bald Netzwerk-Integration und lässt sich ohne veraltete Felder leichter schreiben. Das ist auch nicht das Ende von C tor selbst. Derselbe Kalender listet 0.4.9, im Februar 2026 als stabil markiert, mit noch unentschiedenem eigenem End of Life, sowie eine 0.5.0-Serie, deren Merge-Fenster im März 2026 öffnete. Das Team beschreibt die aktuelle C-tor-Pflege als einschließlich von Funktionen, die den Übergang zu Arti erleichtern sollen. Downstream-Projekte, die noch alte Versionen bündeln, werden direkt kontaktiert; die Outreach-Arbeit wird in einem Network-Health-Ticket verfolgt, das auch Anfragen von Betreibern aufnimmt, die mehr Zeit brauchen.Worauf Betreiber achten sollten
- Relay-Betreiber: Vor dem 1. September 2026 auf 0.4.9.x wechseln; alles Ältere fällt aus dem Netzwerk. Einen Arti-Relay zum Migrieren gibt es noch nicht – solchen Behauptungen gegenüber sollte man skeptisch sein und dem Arti-Changelog folgen.
- Onion-Service-Betreiber: C tor bleibt der unterstützte Weg, einen Dienst zu betreiben. Die Markierungen, die Artis Service-Reife anzeigen werden, sind die oben genannten fehlenden Teile: Restricted Discovery, Vanguard-Unterstützung, Denial-of-Service-Abwehr und Circuit Padding.
- Anwendungsentwickler: Das angestrebte Endziel ist Embedding und RPC statt eines gebündelten SOCKS-Daemons. Arti 2.0.0 stufte die APIs des Top-Level-arti-Crate als experimentell ein, während arti-client die unterstützte Schnittstelle bleibt, und 2.7.0 ergänzte RPC-basierte Konfigurationssteuerung.