Tor-Geschichte: Onion Routing bis heute

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 heißt es, ihre Frage sei gewesen, 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. Der Quellcode wurde unter einer freien und offenen Softwarelizenz veröffentlicht. The Tor Project, Inc. wurde 2006 als gemeinnützige Organisation gegründet.

Alle folgenden Zeitangaben stammen aus der veröffentlichten Zeitleiste des Tor Project, den Release Notes oder den eigenen Support-Seiten. Bei umstrittenen Angaben, etwa zur Finanzierung der Arbeit, nennt dieser Abschnitt die Belege und zeigt, wo Sie sie selbst prüfen können.

Was Onion Routing tatsächlich bewirkt

Onion Routing trennt zwei Informationen, die das Internet normalerweise miteinander verknüpft: wer Sie sind und welche Anfrage Sie gestellt haben. 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. Von dieser Schichtung stammt der Name.

Das erste Relay, der sogenannte 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 verfügt über beide Informationen. Darauf beruht die gesamte Sicherheitsargumentation. 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 und die Verschlüsselung schützt Sie nicht.

Die bekannte Schwachstelle ist die Verkehrskorrelation. Ein Beobachter, der beide Enden einer Verbindung gleichzeitig überwachen kann, kann Zeitpunkte und Größen der eingehenden Pakete mit den ausgehenden Paketen 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 durch ein 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 ausgehende Verbindung sieht, die Antwort bereits. Die Verschlüsselung funktioniert weiterhin einwandfrei. Anonymität gibt es trotzdem nicht, weil niemand vorhanden ist, mit dem die Organisation verwechselt werden könnte.

Das Design musste daher öffentlich sein, und der Datenverkehr musste mit dem Datenverkehr anderer Personen vermischt werden. Der Quellcode wurde im Oktober 2002 unter einer Lizenz für freie Software veröffentlicht, und jeder konnte einen Relay betreiben. Journalisten, Aktivisten, Forschende und gewöhnliche Personen, die einem Werbenetzwerk ausweichen wollten, bildeten gemeinsam die Gruppe, die alle anderen innerhalb des Netzwerks schützt. Dingledine und Mathewson erläuterten dieses Argument 2006 in einem Paper mit dem Titel "Anonymity Loves Company: Usability and the Network Effect", das sie beim Workshop on the Economics of Information Security präsentierten. Die Schlussfolgerung lautet, dass die Größe und Vielfalt der Nutzerbasis eine Sicherheitseigenschaft des Systems ist. Sie ist keine Marketingzahl.

Von Alpha-Code zu einer Nonprofit-Organisation

Die Chronik des Tor Project und die veröffentlichten Fachveröffentlichungen 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 die Design-Abhandlung „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 Nonprofit-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 von Tor Browser beginnt.

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

Wer Tor finanziert und wie Sie das überprüfen

Das Tor Project beantwortet diese Frage auf seinen eigenen Support-Seiten: „Das Tor Project wird durch eine Mischung aus staatlichen Zuschüssen, privaten Stiftungen und Einzelspenden unterstützt.“ Staatliche Gelder gehören dazu, und das war von Anfang an so. Auf der Seite mit den Unterstützern werden das U.S. Department of State sowie die Ford Foundation, der Open Technology Fund, Craig Newmark Philanthropies und Unternehmen wie Brave, DuckDuckGo, Mullvad VPN und Fastly genannt. Geprüfte Finanzberichte werden als Blogbeiträge veröffentlicht. Der aktuellste Bericht deckt das Geschäftsjahr 2023 bis 2024 ab und wurde im Dezember 2025 veröffentlicht. Die erklärte Position des Projekts lautet: „Offen über unsere Sponsoren und unser Finanzierungsmodell zu sprechen, ist der beste Weg, das Vertrauen unserer Community zu erhalten.“

Die entscheidende Frage ist 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 lesen können, und einem Netzwerk aus Relays, die von unabhängigen Betreibern betrieben werden. Wer eine Hintertür einbauen wollte, müsste dies an einer von drei Stellen tun. Jede dieser Stellen lässt sich überprüfen.

• Im Quellcode. Der Client ist Open Source, und das Protokoll ist öffentlich spezifiziert. Wissenschaftliche Forscher veröffentlichen regelmäßig Angriffe auf Tor. Sie haben aus beruflichem Eigeninteresse jeden Anreiz, eine Schwachstelle zuerst zu finden.
• In der Binärdatei. Builds des Tor Browser sind seit August 2013 deterministisch. Ein unabhängiger Builder kann daher ein Release neu erstellen und 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. „Das Tor-Netzwerk ist darauf angewiesen, dass Freiwillige Bandbreite bereitstellen.“ Guards, mittlere Relays, Exits und Bridges gehören Tausenden unabhängigen Betreibern. Die Kompromittierung eines Geldgebers kompromittiert diese Betreiber nicht.

Die eigene Stellungnahme des Projekts ist kurz: „Tor hat keine Hintertüren. Die Software ist Open Source, ihr Code kann unabhängig geprüft werden, und jedes Release ist signiert, um Manipulationen zu verhindern.“ Dieser Satz ist nur deshalb aussagekräftig, weil jede Teilaussage etwas benennt, das Sie selbst überprüfen können.

Es gibt einen berechtigten Vorbehalt. Er betrifft Prioritäten und nicht die Integrität. Fördergelder bestimmen, welche Arbeiten zuerst erledigt werden. Deshalb wurde die Umgehung von Zensur gleichmäßiger finanziert als beispielsweise die Netzwerkleistung. Das ist eine berechtigte Kritik am Projekt. Sie unterscheidet sich von der Aussage, der Code sei kompromittiert. Diese Kritik beantworten Sie, indem Sie die Finanzberichte lesen, statt den Zusicherungen anderer zu vertrauen.

Aus Hidden Services wurden Onion Services

Ein Onion Service ist ein Server, der seine IP-Adresse nie preisgibt. Der Client und der Server bauen jeweils einen eigenen Circuit zu einem Treffpunkt innerhalb des Netzwerks auf. Dadurch erfährt keine Seite die Adresse der anderen. Die Adresse ist kein Name, den eine Registry jemandem zugewiesen hat. Sie wird aus dem öffentlichen Schlüssel des Servers abgeleitet. Deshalb sieht eine .onion-Adresse wie eine zufällige Zeichenfolge aus.

Die Chronologie der Onion Services führt die Releases auf:

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

Die Umbenennung von „Hidden Services“ in „Onion Services“ erfolgte schrittweise und nicht an einem einzelnen Datum. Die Dokumentation des Tor Project verwendet weiterhin beide Begriffe. Der alte Begriff beschrieb den Sachverhalt falsch. 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 Relikt. So wird ein Onion Service in torrc weiterhin definiert:

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

Das Verzeichnis enthält die Schlüssel des Services 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 an 127.0.0.1 gebunden bleiben und muss nie auf einer öffentlichen Schnittstelle lauschen. Version 3 ist der Standard. Ein heute mit diesen beiden Zeilen erstellter Service erhält daher eine v3-Adresse.

Eine Onion-Adresse ist außerdem kein Domainname. RFC 7686, veröffentlicht im Oktober 2015, reservierte .onion als speziell verwendeten Domainnamen. Dadurch sollten gewöhnliche Resolver diese Anfragen nicht mehr an das öffentliche DNS (Domain Name System) weitergeben. Die darin festgelegte Regel ist eindeutig: „Autoritative Server MUST respond to queries for .onion with NXDOMAIN.“ Vergleichen Sie das mit der Auflösung eines gewöhnlichen Domainnamens. Genau darin liegt der entscheidende Unterschied. Ein DNS-Name wird Ihnen von einer Registry zugewiesen und über Server aufgelöst, die Sie nicht kontrollieren. Eine Onion-Adresse ist ein öffentlicher Schlüssel. Sie authentifiziert sich selbst, und eine Auflösung ist nicht erforderlich.

Warum alte .onion-Adressen nicht mehr funktionierten

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 einen 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 abgeschnitten wird. Dadurch ist die Adresse selbst nun die vollständige Identität des Dienstes.

Die Abschaltung erfolgte nach einem angekündigten Zeitplan:

• 15 September 2020, Tor 0.4.4.x: Tor beginnt, Betreiber und Clients darauf hinzuweisen, dass v2 veraltet ist.
• 15 July 2021, Tor 0.4.6.x: Die v2-Unterstützung wird aus der Codebasis entfernt.
• 15 October 2021: Neue stabile Client-Releases für alle unterstützten Serien deaktivieren v2.

Als Grund wurde die Kryptografie genannt. „Mit dem wachsenden Verständnis der Menschheit für Mathematik und Kryptografie wurde die Grundlage von Version 2 brüchig und war zu diesem Zeitpunkt nicht mehr sicher.“ 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 Spielraum, um sie zu ersetzen.

Die Konsequenz für Leser ist einfach und sollte deshalb 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 die Adresse der alte Schlüssel 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 entwickelte sich weiter

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 zugleich eine fertige Sperrliste für jedes Land, das Tor blockieren möchte. Die Arbeiten an Bridges begannen 2007. Ein Bridge ist ein Relay, das nicht in der öffentlichen Liste enthalten ist. Sie fordern eine kleine Anzahl davon über das Web oder per E-Mail an. Ein Zensor kann keine Adressen blockieren, die er nicht auflisten kann.

Die Blockierung verlagerte sich anschließend von Adressen auf die Form des Datenverkehrs. Deep Packet Inspection erkennt das Tor-Protokoll im Netzwerk, 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. Sie ist der Nachfolger von obfs4proxy. Die Client-Konfiguration besteht aus drei Zeilen in 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 Zeile Bridge von der Bridges-Website des Tor Project, statt sie manuell einzugeben. Jeder Transport wirkt gegen eine andere Blockierungsmethode:

• obfs4 lässt den Datenverkehr wie nichts Erkennbares aussehen. Es gibt keinen Protokoll-Header, auf den ein Filter prüfen kann. Tor empfiehlt, diesen Transport zuerst zu testen, weil er den Datenverkehr randomisiert und für die meisten Benutzer funktioniert.
• snowflake leitet Sie über kurzlebige Proxys weiter, die Freiwillige in gewöhnlichen Webbrowsern betreiben. Dadurch ändert sich die Adresse, zu der Sie eine Verbindung herstellen, fortlaufend. snowflake erreichte den stabilen Tor Browser in Version 10.5 am 6. Juli 2021.
• meek leitet die Verbindung über einen großen Cloud-Anbieter. Dadurch sieht der Datenverkehr so aus, als würde er zu diesem Anbieter gehen. Eine Blockierung würde daher auch den Anbieter blockieren.
• webtunnel verfolgt den entgegengesetzten Ansatz zu obfs4. Der Datenverkehr sieht nicht wie nichts aus, sondern wie eine gewöhnliche HTTPS-Verbindung zu einem Webserver. Dazu wird die Nutzdatenverbindung „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 vergangenen zwanzig Jahre. Jeder neue Transport entstand, weil eine bestimmte Blockierungstechnik wirksam wurde. Die Veröffentlichungsdaten dokumentieren, welche Methoden Zensoren in dem jeweiligen Jahr einsetzten.

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

Viele Menschen stoßen auf Tor, nachdem sie über VPNs gelesen haben. Deshalb ist eine genaue Einordnung wichtig. Ein VPN (virtuelles privates Netzwerk) leitet Ihren Datenverkehr an einen einzigen Server weiter, der von einem einzigen 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 kein einzelnes Relay über beide Informationen. Das sind unterschiedliche Vertrauensmodelle mit unterschiedlichen Fehlerbildern. Der Unterschied zwischen einem VPS und einem VPN erklärt, wo die beiden jeweils eingesetzt werden.

Wenn Sie einen privaten Tunnel zwischen von Ihnen kontrollierten Maschinen benötigen und nicht Anonymität innerhalb einer Gruppe, benötigen Sie ein VPN, das Sie selbst betreiben. Sie können ein WireGuard-VPN auf einem VPS selbst hosten und dafür etwa vierzig Konfigurationszeilen verwenden. Dadurch wird Ihr Datenverkehr vor dem lokalen Netzwerk und Ihrem Internetanbieter geschützt. Gegenüber dem Unternehmen, das den Server hostet, bietet es Ihnen keine Anonymität, weil Sie diesen Server mit Ihren eigenen Zahlungsdaten gemietet haben. Die separate Frage, ob VPS-Hosting sicher ist, betrifft eine andere Bedrohung: Wer sonst auf Ihren Server zugreifen kann.

Ein Relay zu betreiben, ist die andere Richtung, und 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 Hostinganbieter davon erfährt. 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. Die Entwicklung begann etwa 2001 und 2002 durch Roger Dingledine, Nick Mathewson und Paul Syverson. Das Netzwerk wurde im Oktober 2002 unter einer Freie-Software-Lizenz bereitgestellt. Das Tor Project, Inc. ist seit 2006 eine unabhängige gemeinnützige Organisation nach 501(c)(3). Der Ursprung bei der Regierung ist real. Er erklärt auch, warum das Netzwerk für alle geöffnet werden musste: Ein Netzwerk, das den Datenverkehr nur einer Organisation überträgt, bietet dieser Organisation keine Anonymität. Jede ausgehende Verbindung identifiziert den Absender dadurch, dass er das Netzwerk verwendet.

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

Die Antwort des Tor Project lautet: „Tor hat keine Hintertüren. Die Software ist Open Source, der Quellcode kann unabhängig geprüft werden, und jede Veröffentlichung wird signiert, um Manipulationen zu verhindern.“ Die Strukturen rund um Tor machen diese Aussage überprüfbar und nicht nur zu einem Versprechen. Das Protokoll ist öffentlich spezifiziert. Die Builds des Tor Browser sind deterministisch. Dadurch kann ein unabhängiger Builder eine Veröffentlichung reproduzieren und mit der veröffentlichten Binärdatei vergleichen. Die Relays werden von Freiwilligen betrieben und nicht von einem Finanzier. 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. Tor warnte ab dem 15. September 2020 davor. Am 15. Juli 2021 entfernte Tor v2 aus der Codebasis von Tor 0.4.6.x. In stabilen Veröffentlichungen wurde v2 am 15. Oktober 2021 deaktiviert. Eine v2-Adresse ist vor .onion 16 Zeichen lang. Eine v3-Adresse ist 56 Zeichen lang. Es gibt keine Weiterleitung und keinen Upgrade-Pfad, weil die Adresse aus dem alten Schlüssel abgeleitet wurde. 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 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 unterschiedlichen 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 und wurde für Anonymität gegenüber einem Beobachter entwickelt, der nicht das gesamte Internet überwacht. Ein VPN ist schneller und wurde zum Schutz Ihrer Privatsphäre gegenüber Ihrem lokalen Netzwerk und Ihrem Internetanbieter entwickelt.

Was ist ein pluggable Transport, und brauche ich einen?

Ein pluggable Transport ist eine Umhüllung, die das Erscheinungsbild des Tor-Datenverkehrs auf der Leitung ändert, ohne die Funktionsweise von Tor zu ändern. Dadurch kann ein Filter, der das Tor-Protokoll erkennt, nicht danach suchen. Sie benötigen einen solchen Transport nur, wenn eine direkte Tor-Verbindung fehlschlägt. Das bedeutet normalerweise, dass Ihr Netzwerk oder Ihr Land Tor blockiert. Tor Browser enthält obfs4, snowflake, meek und webtunnel in einer einzelnen Binärdatei namens lyrebird. Beginnen Sie mit obfs4, weil dieser randomisierende Transport für die meisten Benutzer funktioniert. Wenn die Verbindung damit nie zustande kommt, versuchen Sie webtunnel oder snowflake.