Tor-Geschichte: Onion Routing bis heute

Die Geschichte von Tor in Kürze

Die Geschichte von Tor beginnt 1995 am U.S. Naval Research Laboratory, einem Forschungslabor der U.S. Navy. David Goldschlag, Michael G. Reed und Paul Syverson entwickelten dort die ersten Prototypen für Onion Routing. In der eigenen Zeitleiste des Tor Project wird die zentrale Frage so wiedergegeben: Ob es „eine Möglichkeit gibt, Internetverbindungen herzustellen, die nicht offenlegen, wer mit wem kommuniziert“. Das Netzwerk, das heute genutzt wird, wurde im Oktober 2002 in Betrieb genommen. Sein Quellcode wurde unter einer freien Open-Source-Softwarelizenz veröffentlicht. The Tor Project, Inc. wurde 2006 als Nonprofit-Organisation gegründet.

Alle folgenden Datumsangaben stammen aus der veröffentlichten Zeitleiste des Tor Project, aus den Release Notes oder aus den eigenen Support-Seiten. Bei umstrittenen Angaben, etwa zur Finanzierung der Arbeit, nennt dieser Abschnitt die verfügbaren Belege und die Stellen, an denen Sie diese selbst überprüfen können.

Was Onion-Routing tatsächlich bewirkt

Onion-Routing trennt zwei Informationen, die das Internet normalerweise miteinander verknüpft: Ihre Identität und die angeforderte Ressource. Ihr Tor-Client wählt drei Relays aus und baut eine Verbindung über diese Relays auf. Er verschlüsselt Ihren Datenverkehr in drei Schichten, eine Schicht pro Relay. Jedes Relay entfernt eine Schicht, erfährt nur die Adresse des nächsten Hops und leitet das Paket weiter. Diese Schichtung ist der Ursprung der Bezeichnung.

Das erste Relay, der Guard, sieht Ihre IP-Adresse, aber nicht Ihr Ziel. Das letzte Relay, der Exit, sieht Ihr Ziel, aber nicht Ihre IP-Adresse. Das mittlere Relay sieht weder das eine noch das andere. Kein einzelnes Relay kennt beide Informationen. Darauf beruht das gesamte Sicherheitskonzept. Deshalb müssen die Relays von voneinander unabhängigen Personen betrieben werden. Wenn eine Organisation Ihren Guard und Ihren Exit betreibt, ist die Trennung aufgehoben. Die Verschlüsselung bietet Ihnen dann keinen Schutz.

Die bekannte Schwachstelle ist die Verkehrskorrelation. Ein Beobachter, der beide Enden einer Verbindung gleichzeitig überwachen kann, kann die Zeitpunkte und Größen der eingehenden Pakete mit denen der ausgehenden Pakete abgleichen. Tor schützt nicht vor einem Angreifer, der das gesamte Internet gleichzeitig überwachen kann. Das geht auch aus dem Bedrohungsmodell des Designpapiers von 2004 von Roger Dingledine, Nick Mathewson und Paul Syverson mit dem Titel "Tor: The Second-Generation Onion Router" hervor.

Warum ein privates Netzwerk nutzlos gewesen wäre

Diesen Teil lassen kurze Zusammenfassungen aus. Er erklärt alles Weitere auf dieser Seite.

Eine militärische oder nachrichtendienstliche Organisation kann in einem Netzwerk, das ausschließlich ihren eigenen Datenverkehr überträgt, keine Anonymität erreichen. Anonymität entsteht durch eine Gruppe, nicht durch eine Verschlüsselung. Wenn jede Verbindung, die das Netzwerk verlässt, zu einem einzigen Büro gehört, kennt ein Beobachter, der eine solche Verbindung sieht, die Antwort bereits. Die Verschlüsselung funktioniert weiterhin vollständig. Anonymität gibt es trotzdem nicht, weil niemand vorhanden ist, mit dem die Organisation verwechselt werden kann.

Das Design musste daher öffentlich sein, und der Datenverkehr musste mit dem anderer Personen vermischt werden. Der Code wurde im Oktober 2002 unter einer Freie-Software-Lizenz veröffentlicht, und jeder konnte einen Relay betreiben. Journalisten, Aktivisten, Forscher und gewöhnliche Menschen, die Werbenetzwerken ausweichen wollten, bildeten gemeinsam die Gruppe, die alle anderen darin schützt. Dingledine und Mathewson legten dieses Argument 2006 in einem Paper mit dem Titel „Anonymity Loves Company: Usability and the Network Effect“ dar, das sie beim Workshop on the Economics of Information Security präsentierten. Die Schlussfolgerung lautet, dass die Größe und Vielfalt der Benutzerbasis eine Sicherheitseigenschaft des Systems sind. Sie sind keine Marketingkennzahl.

Von Alpha-Code zur gemeinnützigen Organisation

Die Zeitleiste des Tor Project und die veröffentlichten Fachartikel dokumentieren diese Schritte:

• Oktober 2002: Das Tor-Netzwerk wird bereitgestellt. Der Code steht „unter einer freien und offenen Softwarelizenz“.
• Ende 2003: Das Netzwerk läuft auf „etwa einem Dutzend freiwillig betriebenen Nodes, überwiegend in den USA, sowie einem in Deutschland“.
• 2004: Dingledine, Mathewson und Syverson veröffentlichen den Designartikel „Tor: The Second-Generation Onion Router“.
• 2004: Die Electronic Frontier Foundation (EFF) beginnt, die Arbeit an Tor zu finanzieren.
• 2006: The Tor Project, Inc. wird als gemeinnützige Organisation nach 501(c)(3) gegründet, um die Entwicklung fortzuführen.
• 2007: Die Arbeit an Bridges beginnt, weil nationale Firewalls damit begonnen haben, die öffentliche Relay-Liste zu blockieren.
• 2008: Die Entwicklung des Tor Browser beginnt.

Zwei spätere Zeitpunkte sind für die heutige Nutzung des Netzwerks relevant. Die Zeitleiste des Tor Project ordnet die Nutzung von Tor während des Arabischen Frühlings dem Ende des Jahres 2010 zu. Tor schützte dabei Identitäten und ermöglichte den Zugriff auf blockierte Websites. Außerdem nennt sie die Snowden-Dokumente von 2013 als den Zeitpunkt, an dem die Rolle von Tor allgemein bekannt wurde. Den Dokumenten zufolge war Tor zu diesem Zeitpunkt nicht gebrochen. Keines der beiden Ereignisse änderte das Protokoll. Beide veränderten jedoch, wer Tor installierte.

Wer Tor finanziert und wie Sie das prüfen

Das Tor Project beantwortet diese Frage auf seinen eigenen Support-Seiten: „The Tor Project is supported by a mix of government grants, private foundations, and individual donors.“ Staatliche Gelder gehören dazu, und das war von Anfang an so. Auf der Unterstützerseite werden neben der Ford Foundation, dem Open Technology Fund, Craig Newmark Philanthropies und Unternehmen wie Brave, DuckDuckGo, Mullvad VPN und Fastly auch das U.S. Department of State genannt. Im Oktober 2026 erklärte das Projekt, dass es eine technisch eng begrenzte Zusammenarbeit mit Mullvad fortführe, das Co-Branding mit dem Unternehmen jedoch pausiert habe. Vorausgegangen waren Bedenken wegen einer politischen Spende eines Mullvad-Mitgründers. Geprüfte Finanzberichte werden als Blogbeiträge veröffentlicht. Der jüngste Bericht deckt das Geschäftsjahr 2023 bis 2024 ab und wurde im Dezember 2025 veröffentlicht. Nach eigener Aussage des Projekts ist „talking openly about our sponsors and funding model is the best way to maintain trust with our community“.

Die relevante Frage lautet nicht, wer bezahlt hat. Entscheidend ist, was sich mit Geld kaufen ließe. Tor ist kein Dienst, bei dem Sie sich anmelden. Tor besteht aus einer Protokollspezifikation, einem Client, dessen Quellcode Sie einsehen können, und einem Netzwerk aus Relays, die von unabhängigen Betreibern verwaltet werden. Wer eine Hintertür einbauen wollte, müsste sie an einer von drei Stellen platzieren. Jede dieser Stellen lässt sich prüfen.

• Im Quellcode. Der Client ist Open Source, und das Protokoll ist öffentlich spezifiziert. Akademische Forscher veröffentlichen regelmäßig Angriffe auf Tor. Sie haben aus beruflicher Sicht jeden Anreiz, eine Schwachstelle zuerst zu finden.
• In der Binärdatei. Tor-Browser-Builds sind seit August 2013 deterministisch. Ein unabhängiger Builder kann daher eine Version neu erstellen und sie Byte für Byte mit dem veröffentlichten Download vergleichen. Eine Binärdatei, die nicht zu ihrem Quellcode passt, ist erkennbar, ohne der Person zu vertrauen, die sie veröffentlicht hat.
• In den Relays. Das Tor Project betreibt das Netzwerk nicht selbst. „The Tor network relies on volunteers to donate bandwidth“, und Guards, mittlere Relays, Exits und Bridges gehören Tausenden voneinander unabhängigen Betreibern. Wird ein Geldgeber kompromittiert, sind diese Betreiber dadurch nicht kompromittiert.

Die eigene Erklärung des Projekts ist kurz: „Tor has no backdoors. The software is open source, its code can be independently audited, and every release is signed to protect against tampering.“ Dieser Satz ist nur deshalb aussagekräftig, weil jede Klausel auf etwas verweist, das Sie selbst prüfen können.

Es gibt einen berechtigten Vorbehalt. Er betrifft die Prioritäten, nicht die Integrität. Fördermittel bestimmen, welche Arbeiten zuerst umgesetzt werden. Deshalb wurde die Umgehung von Zensur beständiger finanziert als beispielsweise die Netzwerkleistung. Das ist eine berechtigte Kritik am Projekt. Sie unterscheidet sich von der Behauptung, der Code sei kompromittiert. Diese Frage beantworten Sie, indem Sie die Finanzberichte lesen, statt den Beteuerungen einer beliebigen Person zu vertrauen.

Aus Hidden Services wurden Onion Services

Ein Onion Service ist ein Server, der seine IP-Adresse nie offenlegt. Der Client und der Server bauen jeweils einen eigenen Circuit zu einem Rendezvous Point innerhalb des Netzwerks auf. Dadurch erfährt keine Seite die Adresse der anderen. Die Adresse ist kein Name, den eine Registry jemandem zuweist. Sie wird aus dem Public Key des Servers abgeleitet. Deshalb sieht eine .onion-Adresse wie eine zufällige Zeichenfolge aus.

Die Zeitleiste der Onion Services nennt die Releases:

• 8 April 2004: Hidden Services werden erstmals implementiert, in Tor 0.0.6pre1.
• 21 September 2007: Hidden Services der Version 2 erscheinen in Tor 0.2.0.7-alpha.
• 19 December 2016: Die Entwicklung von Version 3 beginnt in Tor 0.3.0.1-alpha.
• 9 January 2018: Version 3 wird in Tor 0.3.2.9 veröffentlicht.

Die Umbenennung von "Hidden Services" in "Onion Services" erfolgte schrittweise und nicht an einem einzelnen Datum. Auch die Dokumentation des Tor Project verwendet weiterhin beide Begriffe. Der alte Begriff beschrieb den eigentlichen Sachverhalt nicht korrekt. Viele Onion Sites sind öffentlich, indexiert und werden beworben. Versteckt ist der Standort des Servers, nicht die Site. Der ursprüngliche Name ist in der Konfigurationsdatei erhalten geblieben. Das ist ein nützliches historisches Relikt. So deklarieren Sie einen Onion Service auch heute noch in torrc:

HiddenServiceDir /var/lib/tor/my_service/
HiddenServicePort 80 127.0.0.1:8080

Das Verzeichnis enthält die Service Keys sowie eine hostname-Datei mit der Adresse. Die Port-Zeile ordnet einen Port der Onion-Adresse einer lokalen Adresse auf demselben Rechner zu. Dadurch kann der Webserver weiterhin an 127.0.0.1 gebunden bleiben und muss überhaupt nicht an einem öffentlichen Interface lauschen. Version 3 ist der Standard. Ein heute mit diesen beiden Zeilen erstellter Service erhält daher eine v3-Adresse. Bei einem gemieteten Server besteht die Einrichtung im Wesentlichen darin, nginx an Loopback zu binden und anschließend alle Leaks zu schließen, über die sich die Adresse zu Ihrer öffentlichen IP zurückverfolgen ließe. Genau darum geht es in dem schrittweisen Einrichten einer .onion-Site auf Ihrem eigenen VPS.

Eine Onion-Adresse ist außerdem kein Domainname. RFC 7686, veröffentlicht im October 2015, reservierte .onion als Domainname für eine besondere Verwendung. Dadurch sollten normale Resolver aufhören, diese Anfragen in das öffentliche DNS (Domain Name System) zu leaken. Die darin festgelegte Regel ist eindeutig: "Authoritative servers MUST respond to queries for .onion with NXDOMAIN." Vergleichen Sie das mit der Auflösung eines normalen Domainnamens. Darin liegt der wesentliche Unterschied. Eine Registry weist Ihnen einen DNS-Namen zu. Anschließend wird er über Server aufgelöst, die Sie nicht kontrollieren. Eine Onion-Adresse ist ein Public Key. Sie authentifiziert sich selbst, und eine Auflösung ist nicht erforderlich.

Warum alte .onion-Adressen nicht mehr funktionieren

Die beiden Adressformate sind nicht kompatibel. Das ältere Format wurde dauerhaft abgeschaltet.

[
  {
    "version": "v2 (retired 2021)",
    "address_length_chars": 16,
    "service_key": "RSA-1024",
    "address_hash": "SHA-1, truncated to 80 bits"
  },
  {
    "version": "v3 (current)",
    "address_length_chars": 56,
    "service_key": "Ed25519",
    "address_hash": "SHA3-256"
  }
]

Eine v2-Adresse war 16 Zeichen lang, weil sie nur die ersten 80 Bit eines SHA-1-Hashwerts eines öffentlichen RSA-1024-Schlüssels enthielt. Eine v3-Adresse ist 56 Zeichen lang, weil sie den vollständigen öffentlichen Ed25519-Schlüssel sowie eine Prüfsumme und ein Versionsbyte enthält. Die v3-Adresse ist länger, weil der Schlüssel nicht mehr gekürzt wird. Die Adresse ist damit die vollständige Identität des Dienstes.

Die Abkündigung wurde im Juli 2020 angekündigt. Dafür war folgender Zeitplan vorgesehen:

• 15. September 2020, Tor 0.4.4.x: Tor sollte Betreiber und Clients darauf hinweisen, dass v2 veraltet ist.
• 15. Juli 2021, Tor 0.4.6.x: Die v2-Unterstützung sollte aus der Codebasis entfernt werden.
• 15. Oktober 2021: Neue stabile Client-Releases für jede unterstützte Serie sollten v2 deaktivieren.

Die tatsächlichen Releases erschienen nicht an diesen Terminen. Der Code wurde früher umgestellt: Im Changelog von Tor 0.4.6.1-alpha vom 18. März 2021 steht: „Ab diesem Release unterstützt Tor die alten v2-Onion-Dienste nicht mehr.“ Am 10. Mai 2021 fügte Tor 0.4.5.8 eine Warnung „beim Verbinden mit inzwischen abgekündigten v2-Onion-Diensten“ hinzu. Tor 0.4.6.3-rc lieferte eine bessere Fehlermeldung für die Dienste, die „nicht mehr unterstützt“ werden. Der Browser wurde später umgestellt. Der stabile Tor Browser stellte v2 in Version 11.0 am 8. November 2021 ein: „Seit der Aktualisierung auf Tor 0.4.6.8 sind v2-Onion-Dienste im Tor Browser nicht mehr erreichbar.“

Als Grund wurde die Kryptografie genannt. „Mit dem wachsenden Verständnis der Menschheit von Mathematik und Kryptografie wurde die Grundlage von Version 2 brüchig und war zu diesem Zeitpunkt unsicher.“ Ein auf 80 Bit gekürzter SHA-1-Hash und ein 1024-Bit-RSA-Schlüssel lagen 2021 beide unter einem vertretbaren Sicherheitsniveau. Außerdem bot das Adressformat keinen Platz, um einen der beiden Bestandteile zu ersetzen.

Für Leser ist die Konsequenz einfach und sollte klar benannt werden. Jeder vor 2021 veröffentlichte Link mit 16 Zeichen .onion ist dauerhaft ungültig. Es gibt keine Weiterleitung. Eine v2-Adresse konnte nicht aktualisiert werden, weil sie ein gekürzter Hash des alten RSA-Schlüssels war. Betreiber mussten einen neuen Dienst erstellen und die neue Adresse über einen Kanal veröffentlichen, dem ihre Benutzer bereits vertrauten.

Bridges und Pluggable Transports: Zensur bleibt in Bewegung

Die Liste der öffentlichen Relays wird absichtlich veröffentlicht. Dadurch kann ein Client seinen eigenen Pfad auswählen, statt darauf zu vertrauen, dass ein Server den Pfad für ihn auswählt. Dieselbe veröffentlichte Liste ist eine fertige Sperrliste für jedes Land, das Tor blockieren möchte. Die Arbeit an Bridges begann 2007. Ein Bridge ist ein Relay, das nicht in der öffentlichen Liste enthalten ist. Sie können eine kleine Anzahl davon per Web oder E-Mail anfordern. Ein Zensor kann keine Adressen blockieren, die er nicht vollständig erfassen kann. Diese Infrastruktur existiert nur, weil Freiwillige laufend weitere Bridges hinzufügen. Einen obfs4-Bridge auf einem günstigen VPS zu betreiben erfordert lediglich einige torrc-Direktiven und eine Firewall-Regel und ist kein umfangreiches Projekt.

Anschließend verlagerte sich die Blockierung von Adressen auf die Form des Datenverkehrs. Deep Packet Inspection erkennt das Tor-Protokoll im Netzwerkverkehr, unabhängig davon, an welche IP-Adresse die Verbindung geht. Die Antwort darauf waren Pluggable Transports: eine Hülle, die das Erscheinungsbild des Tor-Datenverkehrs verändert, ohne seine Funktion zu ändern. Im aktuellen Tor Browser werden sie als eine Binärdatei namens lyrebird ausgeliefert, dem Nachfolger von obfs4proxy. Die Client-Konfiguration besteht aus drei Zeilen torrc:

UseBridges 1
ClientTransportPlugin meek_lite,obfs4,snowflake,webtunnel exec [PATH]/lyrebird
Bridge obfs4 <IP ADDRESS>:<PORT> <FINGERPRINT> cert=<CERTIFICATE> iat-mode=0

Ersetzen Sie [PATH] durch das Verzeichnis, in dem sich die lyrebird-Binärdatei befindet. Übernehmen Sie die vollständige Bridge-Zeile von der Bridges-Seite des Tor Project, statt sie manuell einzugeben. Jeder Transport ist für eine andere Blockierungsmethode ausgelegt:

• obfs4 lässt den Datenverkehr wie etwas nicht Erkennbares aussehen. Der Datenverkehr enthält keinen Protokoll-Header, auf den ein Filter abgleichen kann. Die Support-Seiten von Tor führen obfs4 an erster Stelle der Transports auf, die Sie beim ersten Umgehen einer Blockierung versuchen sollten.
• snowflake leitet die Verbindung über kurzlebige Proxys, die von Freiwilligen in gewöhnlichen Webbrowsern betrieben werden. Dadurch ändert sich die Adresse, zu der Sie eine Verbindung herstellen, laufend. snowflake erreichte den stabilen Tor Browser in Version 10.5 am 6. Juli 2021.
• meek leitet die Verbindung über einen großen Cloud-Provider. Dadurch sieht der Datenverkehr so aus, als würde er zu diesem Provider gehen. Eine Blockierung würde daher auch den Provider blockieren.
• webtunnel verfolgt den entgegengesetzten Ansatz zu obfs4. Der Datenverkehr sieht nicht wie etwas Unbekanntes aus, sondern wie eine gewöhnliche HTTPS-Verbindung zu einem Webserver. Dazu wird „die Payload-Verbindung in eine WebSocket-ähnliche HTTPS-Verbindung eingebettet“. Das Tor Project veröffentlichte webtunnel am 12. März 2024 im stabilen Tor Browser, für Netzwerke, die nur eine kurze Liste von Protokollen zulassen.

Diese Abfolge zeigt die tatsächliche Entwicklung der letzten zwanzig Jahre. Jeder neue Transport entstand, weil eine bestimmte Blockierungstechnik wirksam wurde. Die Veröffentlichungsdaten dokumentieren, welche Maßnahmen Zensoren in den jeweiligen Jahren einsetzten.

Tor ist kein VPN, und ein VPS ist es ebenfalls nicht

Viele Menschen kommen zu Tor, nachdem sie über VPNs gelesen haben. Deshalb ist eine genaue Unterscheidung wichtig. Ein VPN (Virtual Private Network) leitet Ihren Datenverkehr an einen einzelnen Server weiter, der von einem einzelnen Unternehmen betrieben wird. Dieses Unternehmen sieht gleichzeitig Ihre echte Adresse und Ihr Ziel. Tor leitet Ihren Datenverkehr über drei Relays weiter, die von verschiedenen Personen betrieben werden. Dadurch verfügt keines dieser Relays allein über beide Informationen. Das sind unterschiedliche Vertrauensmodelle mit unterschiedlichen Ausfallursachen. Der Unterschied zwischen einem VPS und einem VPN erklärt, wofür die beiden jeweils geeignet sind.

Wenn Sie einen privaten Tunnel zwischen von Ihnen kontrollierten Maschinen benötigen und nicht Anonymität innerhalb einer Gruppe, brauchen Sie ein VPN, das Sie selbst betreiben. Sie können ein WireGuard-VPN auf einem VPS selbst hosten und dafür etwa vierzig Zeilen Konfiguration verwenden. Damit schützen Sie Ihren Datenverkehr vor dem lokalen Netzwerk und Ihrem Internetprovider. Gegenüber dem Unternehmen, das den Server hostet, erhalten Sie dadurch keine Anonymität, weil Sie diesen Server mit Ihren eigenen Zahlungsdaten gemietet haben. Die separate Frage, ob VPS-Hosting sicher ist, betrifft wiederum eine andere Bedrohung: Wer sonst kann auf Ihre Maschine zugreifen?

Ein Relay zu betreiben, ist die andere Richtung. Das Netzwerk ist darauf angewiesen. Bridges, Guards, Middle Relays und Exits benötigen Betreiber. Der Relay-Leitfaden des Tor Project stellt klar, dass „der Betrieb eines Relays technische Kenntnisse und dauerhaftes Engagement erfordert“. Exits bringen rechtliche Risiken mit sich, weil der Datenverkehr anderer Personen unter Ihrer IP-Adresse das Internet verlässt und Ihr Hostingprovider davon erfahren wird. Lesen Sie diesen Leitfaden, bevor Sie ein Relay starten, nicht erst danach.

FAQ

Wurde Tor von der US-Regierung entwickelt?

Onion Routing begann 1995 am U.S. Naval Research Laboratory. Dort entwickelten David Goldschlag, Michael G. Reed und Paul Syverson die ersten Prototypen. Tor selbst war die nächste Generation des Designs und wurde ungefähr 2001 und 2002 von Roger Dingledine, Nick Mathewson und Paul Syverson begonnen. Das Netzwerk wurde im Oktober 2002 unter einer Free-Software-Lizenz bereitgestellt. The Tor Project, Inc. ist seit 2006 eine unabhängige gemeinnützige Organisation nach 501(c)(3). Der Ursprung bei einer Regierungsbehörde ist real. Er ist auch der Grund, warum das Netzwerk für alle geöffnet werden musste: Ein Netzwerk, das den Datenverkehr einer einzelnen Organisation überträgt, bietet dieser Organisation keine Anonymität. Jede von dort ausgehende Verbindung identifiziert den Absender dadurch, dass er das Netzwerk verwendet.

Bedeutet die staatliche Finanzierung, dass Tor eine Hintertür hat?

Die Antwort von The Tor Project lautet: „Tor hat keine Hintertüren. Die Software ist Open Source, ihr Quellcode kann unabhängig geprüft werden, und jede Version ist signiert, um Manipulationen zu verhindern.“ Die Strukturen rund um Tor machen diese Aussage überprüfbar und nicht zu einem bloßen Versprechen. Das Protokoll ist öffentlich spezifiziert. Builds von Tor Browser sind deterministisch. Dadurch kann ein unabhängiger Builder eine Version neu erstellen und mit dem veröffentlichten Binary vergleichen. Die Relays werden von Freiwilligen betrieben und nicht von einem Geldgeber. Die Finanzierung beeinflusst zwar, welche Arbeiten zuerst durchgeführt werden. Die geprüften Finanzberichte im Tor-Blog zeigen, woher das Geld stammt. Das ist eine Frage der Prioritäten und nicht des Quellcodes.

Warum funktioniert meine alte .onion-Adresse nicht mehr?

Es handelte sich um eine Adresse der Version 2. Onion Services der Version 2 wurden 2021 eingestellt. The Tor Project kündigte die Einstellung im Juli 2020 an. Tor 0.4.6.1-alpha entfernte die Unterstützung für v2 im März 2021. Der stabile Tor Browser stellte mit Version 11.0 am 8. November 2021 den Zugriff auf v2-Adressen ein. Eine v2-Adresse ist vor .onion 16 Zeichen lang, eine v3-Adresse 56 Zeichen. Es gibt keine Weiterleitung und keinen Upgrade-Pfad. Die Adresse wurde aus dem alten Schlüssel abgeleitet. Der Betreiber musste daher einen neuen Service erstellen und die neue Adresse veröffentlichen.

Ist Tor dasselbe wie ein VPN?

Nein. Ein VPN sendet Ihren Datenverkehr an einen einzelnen Server, der von einem Unternehmen betrieben wird. Dieses Unternehmen kann Ihre echte IP-Adresse und Ihr Ziel gemeinsam sehen. Tor sendet den Datenverkehr über drei Relays, die von verschiedenen Personen betrieben werden. Das erste Relay sieht Ihre Adresse, aber nicht Ihr Ziel. Das letzte Relay sieht Ihr Ziel, aber nicht Ihre Adresse. Tor ist langsamer. Es ist für Anonymität gegenüber einem Beobachter ausgelegt, der nicht das gesamte Internet überwacht. Ein VPN ist schneller. Es ist für den Schutz Ihrer Privatsphäre gegenüber Ihrem lokalen Netzwerk und Ihrem Internetprovider ausgelegt.

Was ist ein Pluggable Transport, und brauche ich einen?

Ein Pluggable Transport ist eine Hülle, die das Erscheinungsbild des Tor-Datenverkehrs auf der Leitung verändert, ohne die Funktionsweise von Tor zu ändern. Dadurch kann ein Filter, der das Tor-Protokoll erkennt, den Datenverkehr nicht anhand dieses Protokolls zuordnen. Sie benötigen einen solchen Transport nur, wenn eine Verbindung mit normalem Tor fehlschlägt. Das bedeutet normalerweise, dass Ihr Netzwerk oder Ihr Land Tor blockiert. Tor Browser enthält obfs4, snowflake, meek und webtunnel in einem einzelnen Binary namens lyrebird. Die Support-Seiten von Tor empfehlen, nacheinander obfs4, webtunnel, snowflake oder meek zu testen. Beginnen Sie daher mit obfs4. Wenn die Verbindung nicht hergestellt wird, fahren Sie mit dem nächsten Eintrag in dieser Liste fort.