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: „Das Tor Project wird durch eine Mischung aus staatlichen Fördermitteln, privaten Stiftungen und Einzelspendern unterstützt.“ Staatliche Gelder sind also Teil dieser Finanzierung und waren es von Anfang an. Auf der Seite der Unterstützer werden neben der Ford Foundation, dem Open Technology Fund und Craig Newmark Philanthropies auch das U.S. Department of State sowie Unternehmen wie Brave, DuckDuckGo, Mullvad VPN und Fastly genannt. Geprüfte Finanzberichte werden als Blogbeiträge veröffentlicht. Der jüngste Bericht behandelt das Geschäftsjahr 2023 bis 2024 und wurde im Dezember 2025 veröffentlicht. Das Project vertritt die Position, dass „offene Gespräche über unsere Sponsoren und unser Finanzierungsmodell der beste Weg sind, das Vertrauen unserer Community zu erhalten“.

Die entscheidende Frage ist nicht, wer bezahlt hat. Entscheidend ist, was sich mit dem 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 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. Wissenschaftliche Forschende veröffentlichen regelmäßig Angriffe auf Tor. Sie haben aus beruflichen Gründen ein starkes Interesse daran, eine Schwachstelle zuerst zu finden.
• In der Binärdatei. Tor-Browser-Builds 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 mit ihrem Quellcode übereinstimmt, lässt sich erkennen, ohne der Person zu vertrauen, die sie veröffentlicht hat.
• In den Relays. Das Tor Project betreibt das Netzwerk nicht selbst. „Das Tor-Netzwerk ist darauf angewiesen, dass Freiwillige Bandbreite bereitstellen.“ Guards, mittlere Relays, Exits und Bridges gehören Tausenden voneinander unabhängigen Betreibern. Wenn ein Geldgeber kompromittiert wird, sind diese Betreiber dadurch nicht kompromittiert.

Die eigene Stellungnahme des Projects 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 jeder Teilsatz etwas benennt, das Sie selbst prüfen können.

Es gibt einen berechtigten Einwand. Er betrifft Prioritäten und nicht die Integrität. Fördermittel bestimmen, welche Arbeiten zuerst umgesetzt werden. Deshalb wurde die Umgehung von Zensur kontinuierlicher finanziert als beispielsweise die Netzwerkleistung. Das ist eine berechtigte Kritik am Project. Sie unterscheidet sich von der Behauptung, „der Code sei kompromittiert“. Diese Frage beantworten Sie, indem Sie die Finanzberichte lesen, statt den Zusicherungen 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, und das ältere Format wurde endgültig 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 gekürzt wird. Die Adresse ist damit jetzt die vollständige Identität des Dienstes.

Die Abschaffung erfolgte nach einem angekündigten Zeitplan:

• 15 September 2020, Tor 0.4.4.x: Tor beginnt, Betreiber und Clients darüber zu informieren, 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 jede unterstützte Serie deaktivieren v2.

Als Grund wurde die Kryptografie genannt. „As humankind's understanding of math and cryptography evolved, the foundation of version 2 became fragile and at this point in time, unsafe.“ 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 einen der beiden Werte zu ändern.

Die Konsequenz für Leser ist einfach und sollte klar benannt werden. Jeder vor 2021 veröffentlichte 16 Zeichen lange .onion-Link ist dauerhaft ungültig. Es gibt keine Weiterleitung. Eine v2-Adresse konnte nicht aktualisiert werden, weil die Adresse selbst 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 bleibt in Bewegung

Die Liste der öffentlichen Relays wird absichtlich veröffentlicht. Dadurch kann ein Client seinen eigenen Pfad auswählen, statt einem einzelnen Server diese Auswahl zu überlassen. Dieselbe veröffentlichte Liste ist eine fertige Sperrliste für jedes Land, das Tor blockieren will. Die Arbeit an Bridges begann 2007. Eine 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. Dieses Angebot besteht nur, weil Freiwillige fortlaufend neue Bridges hinzufügen. Eine obfs4-Bridge auf einem günstigen VPS zu betreiben erfordert nur einige torrc-Direktiven und eine Firewall-Regel.

Anschließend verlagerte sich die Blockierung 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 ein Binary namens lyrebird ausgeliefert, dem Nachfolger von obfs4proxy. Die Client-Seite 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 das lyrebird-Binary liegt. Übernehmen Sie die vollständige Zeile Bridge von der Bridges-Website des Tor Project, statt sie manuell einzugeben. Jeder Transport behebt eine andere Blockierungsmethode:

• obfs4 lässt den Datenverkehr wie nichts Erkennbares aussehen. Es gibt keinen Protokoll-Header, auf den ein Filter matchen kann. Tor empfiehlt, diesen Transport zuerst zu versuchen, weil er den Datenverkehr randomisiert und für die meisten Nutzer funktioniert.
• snowflake leitet die Verbindung über kurzlebige Proxys, 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-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, indem „die Payload-Verbindung in eine WebSocket-ähnliche HTTPS-Verbindung eingebettet wird“. 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 Daten dieser Veröffentlichungen dokumentieren, wie Zensoren in den jeweiligen Jahren vorgingen.

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. 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. The Tor Project, Inc. ist seit 2006 eine unabhängige gemeinnützige Organisation nach 501(c)(3). Der staatliche Ursprung ist real. Er erklärt auch, 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 ausgehende Verbindung identifiziert den Absender dadurch, dass er das Netzwerk verwendet.

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

The Tor Project antwortet: „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 das Projekt machen diese Aussage überprüfbar und nicht nur zu einem Versprechen. Das Protokoll ist öffentlich spezifiziert. Builds von Tor Browser sind deterministisch, sodass unabhängige Entwickler eine Version neu erstellen und mit dem veröffentlichten Binary vergleichen können. Die Relays werden von Freiwilligen betrieben und nicht von einem Finanzier. Die Finanzierung beeinflusst zwar, welche Arbeiten zuerst erledigt werden. Die geprüften Finanzberichte im Tor-Blog zeigen, woher das Geld stammt. Das ist eine Frage der Prioritäten, 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 wurde v2 aus der Codebasis von Tor 0.4.6.x entfernt. In stabilen Versionen wurde v2 am 15. Oktober 2021 deaktiviert. Eine v2-Adresse ist vor .onion 16 Zeichen lang, eine v3-Adresse 56 Zeichen. Es gibt weder eine Weiterleitung noch einen Migrationspfad. Die Adresse wurde aus dem alten Schlüssel abgeleitet. Der Betreiber musste deshalb 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 leitet 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. Es ist für Anonymität gegenüber einem Beobachter ausgelegt, der nicht das gesamte Internet überwacht. Ein VPN ist schneller. Es schützt Ihre Privatsphäre gegenüber Ihrem lokalen Netzwerk und Ihrem Internetprovider.

Was ist ein Pluggable Transport, und brauche ich einen?

Ein Pluggable Transport ist eine Hülle, die das Erscheinungsbild des Tor-Datenverkehrs im Netzwerk verändert, ohne die Funktionsweise von Tor zu ändern. Ein Filter, der das Tor-Protokoll erkennt, kann den Datenverkehr dadurch nicht anhand dieses Protokolls zuordnen. 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 einem einzigen Binary namens lyrebird. Beginnen Sie mit obfs4, weil dieser randomisierende Transport für die meisten Benutzer funktioniert. Wenn die Verbindung damit nicht zustande kommt, versuchen Sie webtunnel oder snowflake.