Tor (Netzwerk)

Tor
Entwickler	Roger Dingledine und Nick Matthewson
Aktuelle Version	0.2.2.34 (27. Oktober 2011)
Aktuelle Vorabversion	0.2.3.7-alpha (30. Oktober 2011)
Betriebssystem	Plattformunabhängig
Programmier­sprache	C
Kategorie	Sicherheitssoftware
Lizenz	BSD-Lizenz
Deutschsprachig	ja
www.torproject.org

Tor ist ein Netzwerk zur Anonymisierung der Verbindungsdaten. Es wird für TCP-Verbindungen eingesetzt und kann beispielsweise für Web-Browsing, Instant Messaging, IRC, SSH, E-Mail, P2P und andere benutzt werden. Tor schützt vor der Analyse des Datenverkehrs seiner Nutzer.

„Tor“ ist ein Akronym und wird mit unterschiedlichen Bedeutungen belegt. Üblich ist die Bezeichnung The Onion Routing^[1] (englisch onion = Zwiebel). Das Programm wird meist mit der Kurzform bezeichnet.

Geschichte des Projektes

Die ersten Ideen für das Tor-Projekt stammen aus dem Jahr 2000. Die Arbeit an Tor wurde 2002 durch Matej Pfajfar an der Universität Cambridge begonnen. In der ersten Zeit von 2002 bis 2004 wurde Tor durch das United States Naval Research Laboratory mit Unterstützung des Office of Naval Research (ONR) und der Defense Advanced Research Projects Agency (DARPA), vertreten durch Paul Syverson, und basierend auf der originalen Idee des Onion Routing entwickelt. Die weitere Entwicklung wurde vom Freehaven-Projekt unterstützt. Die Electronic Frontier Foundation unterstützte die Entwicklung von Tor zwischen dem letzten Quartal 2004 bis ins späte Jahr 2005 hinein. Seitdem finanziert sich das Projekt durch private Spenden.

Funktionsweise

Anonymes Surfen

Die Software basiert auf dem Prinzip des Onion Routing und wurde mit einigen Abwandlungen implementiert:

1. Der Nutzer installiert auf seinem Computer einen Client, den so genannten Onion Proxy. Dieses Programm verbindet sich mit dem Tor-Netzwerk. In der Startphase lädt sich das Programm eine Liste aller vorhandenen und nutzbaren Tor-Server herunter. Diese mit einer digitalen Signatur versehene Liste wird von Verzeichnisservern (englisch directory server) aufbewahrt. Deren öffentliche Schlüssel werden mit dem Tor-Quellcode geliefert. Das soll sicherstellen, dass der Onion Proxy ein authentisches Verzeichnis erhält.
2. Wenn die Liste empfangen wurde, wählt der Onion Proxy eine zufällige Route über die Tor-Server.
3. Der Client verhandelt mit dem ersten Tor-Server eine verschlüsselte Verbindung. Wenn diese aufgebaut ist, wird sie um einen weiteren Server verlängert. Diese Prozedur wiederholt sich noch einmal, so dass eine Verbindungskette immer drei Tor-Server enthält. Jeder Server kennt seinen Vorgänger und seinen Nachfolger. Die Entwickler des Projektes wählten drei Server, um möglichst große Anonymität bei noch akzeptabler Verzögerungszeit zu erreichen. Der Erfolg hängt dabei davon ab, dass mindestens einer der Server vertrauenswürdig ist und ein Angreifer nicht schon den Anfangs- und Endpunkt der Kommunikation überwacht.
4. Nachdem eine Verbindung aufgebaut wurde, werden über diese Server die Daten versandt. Der letzte Server tritt dabei als Endpunkt der Kommunikation auf. Er wird als Exit- oder Austritts-Server oder -Knoten (englisch exit node) bezeichnet.

Der oben beschriebene Verbindungsaufbau wird in regelmäßigen Abständen wiederholt und die Verbindungsstrecken werden nach etwa 10 Minuten gewechselt.

Die Pakete innerhalb des Tor-Netzwerkes werden immer verschlüsselt weitergegeben. Erst wenn der Exit-Knoten die Pakete weitergibt, können diese unter Umständen unverschlüsselt sein. Daher ist es weiterhin wichtig, Verschlüsselung einzusetzen, da der Betreiber eines Exit-Knotens ansonsten den kompletten Datenverkehr mitlesen kann.

Versteckte Dienste

Tor ermöglicht es, dass beide Seiten einer Kommunikation anonym bleiben. Der Abrufer von Informationen nutzt hierzu die vorgestellten Funktionen von Tor. Ein Anbieter von Informationen verwendet versteckte Dienste (englisch hidden services):

1. Bob möchte einen Dienst anbieten (beispielsweise eine Webseite mit sensiblen Informationen). Zuerst richtet er die dazu notwendige Software (in dem Beispiel einen Webserver) auf dem betreffenden Rechner ein. In diesem Schritt ist Tor nicht involviert.
2. Jetzt wird ein Schlüsselpaar erstellt, das den Dienst identifizieren soll. Die Tor-Software erledigt diesen Schritt automatisch.
3. Zusammen mit einer Liste von zufällig ausgewählten Eintritts-Punkten (englisch introduction point) sendet er den öffentlichen Schlüssel an einen Verzeichnisserver und baut eine Verbindung zu den Eintritts-Punkten auf. Damit ist die Einrichtung des versteckten Dienstes abgeschlossen.
4. Alice möchte eine Verbindung zu Bobs Dienst aufnehmen. Hierzu benötigt sie den Hash-Wert des öffentlichen Schlüssels. Dieser hat die Form wie 6sxoyfb3h2nvok2d.onion. Bobs Webseite könnte beispielsweise über die Adresse http://oldd6th4cr5spio4.onion/ erreichbar sein. Mit diesem Hash-Wert erhält Alice die Details des Dienstes vom Verzeichnisserver.
5. Alice baut über das Tor-Netzwerk eine Verbindung zu einem zufälligen Tor-Server auf, den sie als Rendezvous-Punkt bestimmt.
6. Danach baut sie eine weitere Verbindung zu einem der Eintritts-Punkte auf. Diese Information befand sich in den Details vom Verzeichnisserver. Alice schickt eine verschlüsselte Mitteilung an Bob. In dieser ist der Rendezvous-Punkt beschrieben, zu der Alice eine Verbindung aufrechterhält. Bob und Alice werden sich dort „treffen“.
7. Nachdem Bob diese Mitteilung erhalten hat, entscheidet er, ob er mit Alice kommunizieren will und baut im positiven Fall eine Verbindung zum Rendezvous-Punkt auf.
8. Am Rendezvous-Knoten werden die Kommunikationskanäle, die zu Bob und Alice gehören, verbunden. Beide können jetzt Daten austauschen, ohne dass sie gegenseitig ihre Identität kennen.

Entry Guards

Tor kann, wie alle Echtzeitanonymisierungsdienste, keinen ausreichenden Schutz gegen Angreifer bieten, die den ersten und den letzten Knoten einer Verbindung kontrollieren. Dies ist unabhängig davon, wie viele Knoten dazwischen liegen. Der Angreifer kann hier allein über Paketanzahl und zeitliche Abfolge von Paketen einen Zusammenhang – auch über die Zwischenknoten hinweg – herstellen und hätte somit die Verbindung zwischen Sender und Empfänger aufgedeckt.^[2] Da Tor-Routen kurzlebig sind und regelmäßig neu ausgewählt werden, geht die Wahrscheinlichkeit, dass so zumindest eine der vom Tor-Client aufgebauten Routen durch einen Angreifer aufdeckbar wäre, für jeden Tor-Nutzer auf Dauer gegen 100 %.^{[A 1]} Besonders Nutzer, die Tor regelmäßig zum Schutz einer immer gleichen Kommunikationsbeziehung nutzen, würden bezüglich dieser früher oder später nahezu sicher deanonymisiert. Verschärfend kommt hinzu, dass der Angreifer eine Route boykottieren kann, wenn er mindestens einen beliebigen Knoten in ihr kontrolliert. Auf diese Weise kann er auf allen Routen eine Neuauswahl der Knoten erzwingen, bei denen er beteiligt ist, aber nicht über die zur Deanonymisierung nötige Kontrolle des Start- und Endknotens verfügt. Somit müssen zusätzliche Routen aufgebaut werden und damit steigt die Wahrscheinlichkeit einer für den Angreifer günstigen Route an.^[3]

Deshalb werden bei Tor, dem Standardmodell des Onion Routings widersprechend, die ersten Knoten der Routen vom Client nicht dynamisch gewählt, sondern es werden für alle aufgebauten Routen die gleichen Einstiegsknoten verwendet, sogenannte Entry Guards.^[4] Der Client wählt dazu aus einer Liste mit Entry Guards zufällig eine kleine Menge (standardmäßig drei) aus und verwendet diese anschließend über mehrere Wochen und Sitzungen hinweg als erste Knoten auf allen aufgebauten Routen. Lediglich bei Ausfall dieser Knoten wird eine ggf. vorübergehende Ersatzauswahl getroffen. Entry Guards können dabei nur Knoten werden, die bereits längere Zeit laufen, über diese Zeit eine hohe Verfügbarkeit aufwiesen und eine überdurchschnittliche Übertragungskapazität haben.^[5]

Auf diese Weise kann weitgehend ausgeschlossen werden, dass auf Dauer jeder Nutzer nahezu zwangsläufig eine für einen Angreifer deanonymisierbare Route aufbaut. Sollte der Nutzer nämlich keine der durch einen Angreifer kontrollierten Entry Guards gewählt haben, kann er auf obigem Weg überhaupt nicht deanonymisiert werden, da der erste Knoten der Routen dann stets außerhalb der Kontrolle des Angreifers ist. Liegen die gewählten Entry Guards des Nutzers dagegen unter der Kontrolle des Angreifers, so ist die Wahrscheinlichkeit einer Deanonymisierung erhöht bzw. diese geschieht entsprechend häufiger, weil der Eingangsknoten dann sicher vom Angreifer kontrolliert wird und die Sicherheit der Route nur noch von der Wahl des Ausgangsknotens abhängt.^[6] Des Weiteren wird auf diese Weise das Risiko gesenkt, dass ein Angreifer eine Liste sämtlicher Tor-Nutzer erstellen kann. Da die Nutzer sich stets mit den gleichen Eingangsknoten verbinden, werden die vom Angreifer kontrollierten Entry Guards immer nur von der gleichen Gruppe Nutzer kontaktiert, während alle anderen Tor-Nutzer stets bei ihren Eingangsknoten außerhalb des Einflussbereiches des Angreifers bleiben.

Zensurresistenz/Tor-Bridges

Tor kann nicht nur genutzt werden, um anonyme Internetzugriffe zu ermöglichen, sondern auch, um Zugriffssperren zu umgehen. Die Verbindung wird – an der Sperre vorbei – über das Tor-Netzwerk umgeleitet und kann so das Ziel erreichen. Aus Sicht des Sperrenden ist das, insbesondere im Bereich der Zensur, kein wünschenswerter Zustand. Deshalb wurde ebenfalls der Zugang zu Tor in einigen Fällen (u. a. durch die chinesische Internetkontrolle) bereits unterbunden. Besonders einfach ist das, da die Liste aller Tor-Nodes öffentlich ist. Auf Grund des gewählten Anonymisierungsmodells lässt sich der Zugang zu dieser Liste auch nicht einschränken, da die Auswahlmöglichkeit aus vielen Nodes Voraussetzung ist.

Tor wurde deshalb um eine Bridge-Funktionalität erweitert, welche eine Vermittlung zwischen geblockten Nutzern und dem Tor-Netzwerk vornimmt.^[7] Damit kann jeder Nutzer seinen Tor-Client als sogenannte Bridge konfigurieren, so dass er auch anderen Nutzern den Zugriff auf das Tor-Netzwerk ermöglicht. Die zum Zugriff nötige eigene Internetadresse kann er dann anderen selbst mitteilen oder er hinterlegt sie bei einer vertrauenswürdigen Zentralinstanz (bridge authority) zur weiteren Verteilung. Dort gelangt sie in genau einen von momentan drei Adresspools, denen unterschiedliche Verteilungsstrategien zu Grunde liegen.^[8] Die Verteilung erfolgt in Pool 1 über eine Website, in Pool 2 über E-Mail und in Pool 3 über Instant Messaging, soziale Netzwerke und ähnliche Direktkontakte. Um ein Ausforschen der Pools zu verhindern, werden in Pool 1 für Anfragen von der gleichen IP-Adresse (maßgeblich sind nur die ersten 24 bit) nur Bridges aus einem stets gleichen Bereich der Gesamtliste zurückgegeben (offen ist das Problem, dass hier auch Anfragen über verschiedene Proxies bzw. verschiedene Tor-Nodes selbst erfolgen könnten und staatliche Stellen bzw. Internetprovider Zugriff auf sehr große Adresskontingente haben). In Pool 2 gilt dies entsprechend für Anfragen von ein und derselben E-Mail-Adresse. Um ein massenhaftes Erstellen von verschiedenen E-Mail-Adressen zu verhindern, werden ausschließlich Anfragen von Gmail- und Yahoo-Adressen beantwortet. Dort vertraut Tor darauf, dass die Anbieter selbst entsprechende Maßnahmen ergriffen haben, um massenhafte Kontenerstellung zu verhindern. Pool 3 setzt darauf, dass es schwer ist, unter verschiedenen Identitäten ausreichend menschliches Vertrauen aufzubauen, um über Direktkontakte an viele Bridge-Adressen zu kommen. Sollte sich eine der Verteilungsstrategien als schwach erweisen, so dass ein Angreifer darüber doch sehr viele Adressen erhalten und Zugriffe dorthin dann unterbinden bzw. als Tor-Zugriffe identifizieren kann, stünden die Adressen der anderen Pools trotzdem weiterhin zur Verfügung.

China gelingt es allerdings bereits seit 2009 bzw. 2010, die Verteilstrategien 1 und 2 erfolgreich zu brechen und Zugriffe chinesischer Bürger auf die entsprechenden Bridges zu unterbinden.^[9] Eine Ursache dafür ist, dass die Anzahl der Bridges mit ca. 500 Stück gegenüber den Ressourcen der chinesischen Internetkontrolle zu gering ist. So wird unter ausreichend vielen verschiedenen IP-Adressen bzw. E-Mail-Konten die gesamte Liste der entsprechenden Pools abgefragt. Ferner haben die Tor-Entwickler durch Benutzerfeedback Hinweise darauf, dass China die Zieladresse von Verbindungen testet, die als möglicherweise mit Tor verschlüsselt erkannt werden. Sollte das Ziel dann tatsächlich das Tor-Protokoll sprechen, wird es in eine Sperrliste aufgenommen. Auf diese Weise könnte China sogar Bridges erkennen, deren Adressen nicht öffentlich verteilt werden und Zugriffe darauf unterbinden.

Aus Sicht der Anonymität kann es für einen Nutzer sogar vorteilhaft sein, eine Bridge zu betreiben. Für einen Angreifer lassen sich Aktionen des Nutzers nicht mehr unbedingt von denen der darüber nur weitergeleiteten Nutzer unterscheiden. Auf der anderen Seite existieren auch Risiken: Sollte ein Angreifer in der Lage sein, eine weitergeleitete Verbindung über die Folge-Nodes vom Verbindungsziel her rückwärts zu deanonymisieren, könnte der weiterleitende Nutzer zu Unrecht in Verdacht geraten, der Ursprung der Verbindung zu sein. Auch kann der Betrieb einer Bridge dafür sorgen, dass über einen längeren Zeitraum eigener, über Tor abgewickelter, Verkehr deanonymisierbar wird.^[10] Dieser Angriff basiert darauf, dass die Bridge in der Regel durch einen Nutzer nur genau dann zur Verfügung gestellt werden wird, wenn er selbst gerade Tor nutzt. Angenommen, jemand nutzt Tor, um hin und wieder neue Einträge in seinem Blog zu veröffentlichen. Hat er die Bridge-Funktionalität aktiviert und könnte sich ein Angreifer eine große Anzahl der Tor-Bridge-Adressen beschaffen, dann könnte der Angreifer regelmäßig überprüfen, welche Bridges wann zur Verfügung stehen. So könnte der Angreifer sehr schnell den Kreis der Urheber einschränken. Es kommen dafür nur noch Bridge-Betreiber in Frage, die zu allen fraglichen Zeitpunkten ihre Bridge aktiv hatten.

Kritik und Schwachstellen

Grenzen der Anonymität

Tor bietet keine Anonymität gegen jeden Angreifer.^[11] So ist es durch Überwachung einer ausreichend großen Anzahl von Tor-Knoten oder größeren Teilen des Internets möglich, nahezu sämtliche über Tor abgewickelte Kommunikation nachzuvollziehen.^[12] Ein solches Szenario ist beispielsweise bei Betreibern von Internet-Knoten oder wichtigen Backbones – insbesondere durch Kooperation – durchaus vorstellbar: Gelingt es, den ersten und letzten Knoten der Verbindung zu überwachen, lässt sich mit Hilfe einer statistischen Auswertung auf den Ursprung der Verbindung schließen.^[13]

Gegebenenfalls kann das auch durch staatliche Einflussnahme oder geheimdienstliche Tätigkeit erfolgen. Begünstigt wird es sowohl durch die Struktur des Internets, das sich stark auf einzelne Betreiber stützt, als auch durch die sehr ungleiche Verteilung der Tor-Server weltweit, die sich stark auf wenige Länder konzentrieren. Dadurch würde die Zusammenarbeit von wenigen Instanzen ausreichen, um die Wirkung von Tor deutlich zu schwächen.

Vor- und Nachteile des Anonymisierungsmodells

Tor basiert auf einem verteilten Anonymisierungsnetzwerk mit dynamischer Routenwahl. Bereits das unterscheidet Tor von vielen anderen Anonymisierungsdiensten, die auf dem Ansatz von statischen Routen in Form von Mixkaskaden beruhen. Die Grundannahme für die Sicherheit von Tor lautet, dass es niemandem möglich ist, große Teile des Internets zu überwachen. Diese Grundannahme ruft Kritik hervor. Zum einen ist fraglich, ob sie realistisch ist, zum anderen existiert mit dem Modell der Mixkaskade eine Möglichkeit der Anonymisierung bei Totalüberwachung des zu Grunde liegenden Netzwerkes – zumindest in der Theorie. Das theoretisch stärkere Modell der Mixkaskade muss bei der praktischen Umsetzung im Internet sehr viele Abstriche machen, um benutzbar zu bleiben: beispielsweise können nur bestimmte der benötigten Mixfunktionen tatsächlich implementiert werden. Dadurch kompensieren sich die Vorteile des Mixkaskadenmodells gegenüber dem Ansatz von Tor und die kaskadenbasierten Anonymisierungsdienste können ebenfalls nur eine sehr begrenzte Anonymität bieten.

Es gibt aber auch einige praktische Gründe, die explizit für das von Tor gewählte Konzept sprechen. So kann besonders das Ressourcenproblem, das beim Betrieb eines Anonymisierungsdienstes auftritt (es wird sehr viel Bandbreite und für die Kryptographie eine gewisse Rechenleistung benötigt) sehr einfach gelöst werden, indem die Ressourcen gemeinschaftlich erbracht werden können. Hier kann also nahezu jeder Besitzer eines Breitbandanschlusses durch Betrieb eines Tor-Knotens etwas zum Anonymisierungsdienst beitragen. Beim Mixkaskadenmodell muss die benötigte Bandbreite dagegen durch wenige Instanzen (Mixbetreiber) allein aufgebracht werden, um die Anonymitätsgruppen groß zu halten. Da dies für die Mixbetreiber entsprechende Kosten verursacht, stellt sich dort automatisch auch immer die Finanzierungsfrage. Andererseits stellt die niedrige Beteiligungshürde bei Tor auch immer eine Gefahr dar: es kann keine ausreichende Prüfung der Beteiligten erfolgen. So ist beispielsweise vorstellbar, dass eine Person unter verschiedenen Identitäten sehr viele Tor-Knoten betreibt. Verbindungen, die ausschließlich über die von ihr kontrollierten Knoten laufen, können dadurch aufgedeckt werden. Beim Mixkaskadenmodell sind wesentlich weniger Anonymitätsanbieter nötig – diese können also wesentlich besser auf ihre Identität und ihre Absichten geprüft werden. Auch im Falle staatlicher Zwangsmaßnahmen können sie sowohl sich selbst, als auch ihre Nutzer juristisch verteidigen (wie beispielsweise bei JAP geschehen). Bei Tor existieren derartige gegenseitige Unterstützungen erst im Ansatz. Insbesondere für die Betreiber von Exit-Knoten können sich juristische Risiken ergeben. Denn als Betreiber des Knotens müssen sie bei eventuellem Missbrauch die Beschlagnahmung der Rechner durch Ermittlungsbehörden fürchten. Sie werden als Zeugen in dem betreffenden Verfahren behandelt. Jedoch kann es auch vorkommen, dass ein Verfahren gegen den Betreiber selbst geführt wird.^[14]

Nicht zu vergessen ist aber auch, dass der stark verteilte Ansatz bei Tor gegenüber dem Mixkaskadenkonzept besser vor staatlichen Zwangsmaßnahmen bezüglich des Aufdeckens von Verbindungen schützt, da die staatlichen Stellen nicht wie beim Kaskadenansatz eine kleine Gruppe an Verantwortlichen gegenüber haben, mit denen sie die Überwachungsmaßnahmen direkt durchführen können. Sie müssten hier den wesentlich aufwändigeren und international kaum durchsetzbaren Umweg über die Netzbetreiber wählen. Auch Strafverfolgung wird dadurch erheblich erschwert.

Schwachpunkte der Implementierung

Tor verwendet – entgegen dem Grundmodell des Onion Routings – ein und dieselbe Route für die Datenübertragung mehrerer Anwendungen, die auf dem Client-Rechner ausgeführt werden. Begründet wird dies zum einen mit höherer Effizienz (durch das Teilen einer Route für mehrere TCP-Streams müssen weniger Routen aufgebaut werden und somit wird weniger kryptographischer Aufwand, insbesondere für die asymmetrische Kryptographie, benötigt), zum anderen mit einer Verbesserung der Anonymität (da man weniger Routen aufbaut, ist die Wahrscheinlichkeit geringer, dass man einmal eine Route komplett aus Knoten zusammenstellt, die allesamt in den Händen eines Angreifers liegen und der Datenverkehr darüber somit nicht anonym ist).^[15] Sollte allerdings eine der Anwendungen die Anonymität schädigen (beispielsweise indem sie die IP-Adresse des Clients nachvollziehbar macht), so kann insbesondere ein Exit-Knoten-Betreiber dann auch die über die gleiche Route übertragenen Daten aller anderen Anwendungen dieses Clients zuordnen. Es reicht also ggf. eine Anwendung, welche Absenderdaten preisgibt, aus, damit der Client auch bezüglich anderer Aktivitäten deanonymisiert werden kann.

Forscher am Institut national de recherche en informatique et en automatique haben dies Anfang 2010 mit BitTorrent praktisch demonstriert.^[16] Es wurden dazu mehrere Tor-Exit-Nodes betrieben und der von den Clients darüber laufende BitTorrent-Verkehr ausgewertet bzw. manipuliert. Dabei wurde ausgenutzt, dass oftmals nur die Tracker-Kommunikation über Tor anonymisiert wird, die eigentliche Datenübertragung mit anderen Peers (sowohl beim eigentlichen Filesharing als auch bezüglich des Zugriffs auf die verteilte Hashtabelle beim Trackerless-Betrieb) dann aber meist direkt ohne Anonymisierung erfolgt, da dies über Tor zu langsam wäre bzw. die dabei teilweise verwendete UDP-Kommunikation auch von Tor nicht unterstützt wird. Auf diese Weise konnte die direkte Kommunikation der Clients außerhalb des Tor-Netzwerkes (insbesondere ihre IP-Adressen) ihrer Kommunikation innerhalb des Tor-Netzwerkes zugeordnet werden. Falls der Client neben BitTorrent noch weitere, eigentlich sichere Anwendungen über die gleiche Tor-Route laufen hatte, war somit auch deren Kommunikation deanonymisiert. Da mit der eindeutigen Peer-ID bei BitTorrent ein Langzeitverkettungsmerkmal existiert, sind nach einer einmalig erfolgten Deanonymisierung ggf. auch neue Tor-Routen dann schnell zuordenbar, falls durch sie ebenfalls BitTorrent-Kommunikation abgewickelt wird.

Neben Anwendungen kann aber auch unvorsichtiges Benutzerverhalten den gleichen Effekt haben. Sollte ein Benutzer parallel zu seiner anonym zu haltenden Kommunikation auch persönlich zuzuordnende Kommunikation über Tor abwickeln, so kann letztere die anonyme Kommunikation auf der gleichen Tor-Route für den Exit-Node-Betreiber deanonymisieren. Das muss nicht einmal durch Übertragung von Klarnamen geschehen. Eventuell reichen die ohnehin vorhanden Metadaten einer der Verbindungen (Uhrzeit, übertragene Datenmenge, Zieladresse) für den Exit-Node-Betreiber schon aus, um auf den Urheber schließen zu können. Damit wäre dann auch die restliche Kommunikation innerhalb der gleichen Tor-Route deanonymisiert.

Verwendung und Missbrauch

Tor befindet sich noch in einer frühen Entwicklungsphase und sollte laut den Entwicklern noch nicht für starke Anonymität im Internet verwendet werden. Trotzdem wird geschätzt, dass weltweit hunderttausende Benutzer von Tor Gebrauch machen. Die Server befinden sich in privater Hand und jeder Interessierte kann selbst einen Tor-Server betreiben. Die Architektur ist bereits für DSL-Zugänge ausgelegt. Somit kann jeder Nutzer, der über einen DSL-Anschluss mit einer Upload-Bandbreite von mindestens 20 kB/s (= 160 kbit/s)^[17] verfügt, einen Tor-Server betreiben.

Im Zusammenhang mit Vorermittlungen der Staatsanwaltschaft Konstanz im Bereich der Verbreitung von Kinderpornographie wurden am 7. September 2006 einige deutsche Tor-Server beschlagnahmt, die bei deutschen Host-Providern angemietet und untergebracht waren. Die Ermittlungen richteten sich nicht gegen deren Betreiber. Die Staatsanwaltschaft erhoffte sich lediglich Erkenntnisse über die zugreifenden Nutzer. Aufgrund der Struktur des Tor-Netzwerks war dies als hoffnungslos einzustufen.^[18][19]

Dan Egerstad konnte mit einem Versuchsaufbau, in dem er fünf Exit-Knoten über eigene Rechner zur Verfügung stellte und diese mit Sniffer-Tools abhörte, darlegen, dass viele Nutzer die Sicherung der letzten, unverschlüsselten Meile noch nicht berücksichtigen. Egerstad konnte unverschlüsselte Zugangsdaten, insbesondere von E-Mail-Postfächern, aufzeichnen, und veröffentlichte einen Extrakt aus 100 Postfächern, die er Botschafts- und Regierungsangehörigen zuordnen konnte, um auf die Brisanz hinzuweisen und gleichsam zum Handeln zu bewegen. In diesem Zusammenhang soll laut einem Artikel vom 10. September 2007 eine stark gestiegene Anzahl von Exit-Knoten in China und den USA stehen.^[20] Um Missbrauch dieser Art zu verhindern, genügt eine Ende-zu-Ende-Verschlüsselung, wie sie die meisten E-Mail-Dienste anbieten.

Literatur

• Roger Dingledine u. a.: Tor: The Second-Generation Onion Router. In: Proceedings of the 13^th USENIX Security Symposium, August 9–13, 2004, San Diego, CA, USA. S. 303–320, abgerufen am 14. September 2010 (PDF). 
• Marc Störing: Im Visier der Strafverfolger – Staatlicher Zugriff auf Anonymisierungsserver. In: c't. Nr. 24, 2006, S. 208–210.
• Jens Kubieziel: Anonym im Netz: Wie Sie sich und Ihre Daten schützen. 2. Auflage. Open Source Press, München 2010, ISBN 978-3-937514-95-6.

Siehe auch

• Anonymisierer
• I2P
• Freenet
• Vidalia (Tor)
• Polipo

Einzelnachweise

1. ↑ Erklärung von einem der Entwickler auf der Tor-Diskussionsliste
2. ↑ Paul Syverson, Gene Tsudik u. a.: Towards an Analysis of Onion Routing Security (gzipped PS) In: Proceedings of the Workshop on Design Issues in Anonymity and Unobservability, Juli 2000, Berkeley, CA. Abgerufen am 25. August 2011.
3. ↑ Nikita Borisov, George Danezis u. a.: Denial of Service or Denial of Security? How Attacks on Reliability can Compromise Anonymity (PDF) In: Proceedings of the 14th ACM Conference on Computer and Communications Security (ACM CCS 2007), Oktober 2007, Alexandria, VA. Abgerufen am 25. August 2011.
4. ↑ Tor Project FAQ: What are Entry Guards? Abgerufen am 25. August 2011.
5. ↑ Blog des Tor-Projektes: Research problem: better guard rotation parameters. Eintrag vom 20. August 2011. Abgerufen am 25. August 2011.
6. ↑ Matthew Wright, Micah Adler u. a.: Defending Anonymous Communications Against Passive Logging Attacks (PDF) In: Proceedings of the 2003 IEEE Symposium on Security and Privacy, Mai 2003, Oakland, CA. Abgerufen am 25. August 2011.
7. ↑ R. Dingledine, N. Mathewson: Design of a blocking-resistant anonymity system (PDF) Abgerufen 27. August 2011.
8. ↑ Blog des Tor-Projektes: KAIST freshmen working on bridge distribution strategies. Eintrag vom 8. September 2009. Abgerufen am 31. Dezember 2009.
9. ↑ Blog des Tor-Projektes: Research problems: Ten ways to discover Tor bridges. 31. Oktober 2011, abgerufen am 18. November 2011. 
10. ↑ J. McLachlan, N. Hopper: On the risks of serving whenever you surf. (PDF) Proceedings of the Workshop on Privacy in the Electronic Society (WPES 2009). Abgerufen am 31. Dezember 2009.
11. ↑ Design-Dokument von Tor
12. ↑ Steven J. Murdoch, Piotr Zieliński: Sampled Traffic Analysis by Internet-Exchange-Level Adversaries (PDF)
13. ↑ Übersicht aus der Tor-Webseite
14. ↑ “Herr Weber”: Anonymisierungsdienst TOR: Wenn die Polizei 2× klingelt. (PDF; 8,1 MB) In: Datenschleuder 91/2007, Seiten 16 ff.
15. ↑ Blog des Tor-Projektes: Bittorrent over Tor isn't a good idea. Eintrag vom 29. April 2010. Abgerufen am 14. April 2011.
16. ↑ Stevens Le Blond, Pere Manils u. a.: One Bad Apple Spoils the Bunch: Exploiting P2P Applications to Trace and Profile Tor Users. (PDF; 882 KB) In: Proceedings of 4th USENIX Workshop on Large-Scale Exploits and Emergent Threats (LEET '11), 29. März 2011, Boston, MA. Abgerufen am 13. April 2011.
17. ↑ Anleitung zum Serverbetrieb
18. ↑ German Police Seize TOR Servers 11/2006
19. ↑ Marc Störing: Im Visier der Strafverfolger – Staatlicher Zugriff auf Anonymisierungsserver. In: c't 24/2006, S. 208–210.
20. ↑ Artikel vom 10. September 2007

Anmerkungen

1. ↑ Sei p das Verhältnis der vom Angreifer kontrollierten Knoten zur Anzahl aller Knoten. Die Wahrscheinlichkeit, dass bei zufälliger Knotenwahl der Angreifer Start- und Endknoten einer Route kontrolliert, liegt somit bei p * p = p². Dass keine einzige von r aufgebauten Routen so durch den Angreifer kontrollierbar ist, besitzt nur noch eine Wahrscheinlichkeit von (1 - p²)^r – läuft mit steigendem r also gegen 0.