Ach wie gut, dass niemand weiß ... Web-Services im TOR-Netzwerk

Ordnungsmerkmale

erschienen in: <kes> 2007^#6, Seite 78

Zusammenfassung: Auch im geschäftlichen Umfeld kann Anonymität bisweilen interessant sein. Über das TOR-Netzwerk sind dabei nicht nur anonyme Zugriffe von Clients, sondern auch anonyme Services möglich.

Autor: Von Steffen Hitzemann, Karlsruhe

"The Onion-Router" – kurz: TOR – basiert auf einem Peer-to-Peer-artigen Netzwerk, dessen Knotenanzahl sich in den vergangenen 18 Monaten auf über 1000 verdoppelt hat. Dabei handelt es sich wohlgemerkt nur um die Rechner, die laufend zur Verfügung stehen, um diesen Anonymisierungs-Dienst mitzutragen; aktuelle Zahlen belegen eine steigende Popularität. Die Entwicklung von TOR ist zwar längst noch nicht abgeschlossen, dennoch lässt sich feststellen, dass TOR aus einer ersten Evolutionsstufe der Anonymisierer als ein Gewinner hervorging.

Evolution der Anonymisierer

Spricht man von Tools und Services, die den Datenverkehr im Internet anonymisieren, ist in aller Regel gemeint, dass nur der Absender einer Nachricht deren gesamten Weg nachvollziehen kann und nur er weiß, dass er der Urheber ist. Die Anonymisierung ist dabei auf der Internetschicht zu verstehen, betrifft also die IP-Adresse des Senders – gegen identifizierende Elemente höherer Protokollschichten (vor allem auf Anwendungsebene) schützen Anonymisierungsdienste hingegen normalerweise nicht.

Der erste Anonymisierungs-Ansatz waren spezielle Proxies: Anders als normale Proxy-Server, die beispielsweise die Funktion einer Schnittstelle zwischen lokalem Netz und Internet einnehmen oder als Zwischenspeicher für den Datenverkehr fungieren, haben Anonymisierungs-Proxies die primäre Aufgabe, die IP-Adresse von Clients zu verbergen. Dabei dürfen sie natürlich nicht wie ein regulärer Proxy dem Zielserver über Kopfdaten mitteilen, woher eine Anfrage stammt – Client-Anfragen dürfen zudem nicht protokolliert oder veröffentlicht werden. Und außerdem muss der Proxy selbst (bzw. sein Betreiber) vertrauenswürdig sein. Auch heute existieren noch mehrere Angebote solcher anonymisierenden Proxies, etwa der Anonymizer ( www.anonymizer.com) oder Steganos' Internet Anonym ( www.steganos.com).

Der Ansatz des einfachen Proxy zeigt allerdings Schwächen, wenn es um die Beobachtbarkeit des Datenverkehrs durch Dritte geht: Vergleicht ein Außenstehender mit entsprechendem Netzwerkzugriff die beim Proxy eingehenden Nachrichten mit den ausgehenden, so wird es ihm möglich sein, sie aufgrund ihres Inhalts einander zuzuordnen, wodurch er folgern kann, von welchem Client welche Anfrage kam. Um das zu verhindern, kann man ein Verschlüsselungsprotokoll wie Secure Sockets Layer (SSL) oder ein VPN für die Verbindung mit dem Client verwenden, sodass inhaltliche Übereinstimmungen von ein- und ausgehenden Nachrichten verschwinden. Es bleiben jedoch noch Ähnlichkeiten bei der Nachrichten-Länge oder zeitliche Korrelationen, um die Anonymität möglicherweise aufzuheben.

Mixe

Um dieses Problem zu beseitigen, entwickelte David Chaum 1981 das Konzept der so genannten Mixe [1]. Ein Mix ist ebenfalls ein anonymisierender Proxy, der jedoch zusätzlich (im Idealfall) alle möglichen Zusammenhänge zwischen ein- und ausgehenden Nachrichten eliminiert. Das sind im Wesentlichen der Inhalt, der wiederum durch Verschlüsselung verborgen bleibt, die Länge der Nachrichten (vgl. [2]), deren Signifikanz dadurch eliminiert wird, dass alle Nachrichten in gleich große Fragmente aufgeteilt werden, sowie die Korrelation von Ein- und Ausgangszeit, die manipuliert wird, indem die Nachrichten vor ihrer Weiterleitung umsortiert ("gemixt") und für kurze Zeit gesammelt werden.

Zusätzlich verhindern Mixe auch Replay-Attacken, bei denen ein Angreifer eine eingehende Nachricht kopiert und mehrfach erneut an den Mix sendet, um dann zu beobachten, in welche Richtung eine Nachricht ebenso mehrfach weitergeleitet wird. Als Gegenmaßnahme erzeugt und speichert der Mix zu jeder Nachricht einen Hash-Wert – erneut mit demselben Wert eingehende Nachrichten verwirft das System.

Chaum schlug darüber hinaus auch vor, mehrere solcher Mixe hintereinanderzuschalten, um nicht von der Vertrauenswürdigkeit eines einzelnen Knotens abhängig zu sein. Dieser Vorschlag lässt sich einerseits in einer Art Client-Server-Architektur umsetzen, bei der man immer dieselben Mixe in der derselben Reihenfolge nutzt (Mix-Kaskaden). Zum anderen funktioniert das in Verbindung mit einem Peer-to-Peer-(P2P)-Ansatz, bei dem in einem Mix-Netzwerk eine wechselnde Auswahl teilnehmender Rechner in variabler Reihenfolge zum Einsatz kommt. Der Name dieses so genannten Onion-Routing ist in Anlehnung an das "zwiebelschalenartige" Verschlüsselungsverfahren entstanden, das hierbei verwendet wird und dafür sorgt, dass niemand außer dem Absender sowohl Absender als auch Empfänger einer übergebenen Nachricht kennt.

Zu beiden Verfahren entstanden im Laufe der Zeit Programme und Systeme: Während die Mix-Kaskaden von Beginn an durch den Java Anon Proxy (JAP,  http://anon.inf.tu-dresden.de/index.html) dominiert wurden, gibt es zum Onion-Routing zahlreiche Projekte, von denen "The Onion-Router" (TOR,  www.torproject.org) aktuell mit Abstand das populärste ist. Andere Implementierungen, wie Babel, Mixmaster und Mixminion oder auch Tarzan, MorphMix, Cebolla, GNUNet oder das Anonymity Network konnten sich nicht durchsetzen, da sie die zugrunde liegenden Konzepte offenbar zu idealisiert oder nicht praxistauglich umsetzen: So versuchen beispielsweise die erstgenannten Mixe, absolut alle Zusammenhänge zwischen ein- und ausgehenden Nachrichten zu eliminieren, was zu langen Verzögerungsraten (High-Latency) führt.

TOR scheint hingegen mit einem Low-Latency-Ansatz und einer hybriden P2P-Architektur ein Mittelweg gelungen zu sein, der Onion-Routing praktikabel macht. Während JAP ausschließlich Clients anonymisiert, ermöglicht es TOR durch seinen P2P-Ansatz zudem auch, als Server bestimmte Dienste anonym anzubieten.

Das TOR zur Welt

Bei der von TOR umgesetzten Form des Onion-Routing verzichten die Mixe auf das Umsortieren und Sammeln von Nachrichten vor der Weiterleitung, setzen aber die restlichen Funktionen wie von Chaum konzipiert um. Eine anonymisierte Verbindung über ausgewählte Mixe wird im Zusammenhang mit TOR als "Circuit" bezeichnet. Zum Aufbau eines Circuit werden zunächst mit den am Onion-Routing beteiligten Mixen kryptographische Schlüssel für das verwendete systemeigene Verschlüsselungsverfahren ausgehandelt und anschließend initiale Nachrichten versendet, sodass jeder Knoten seinen Vorgänger und Nachfolger auf diesem Circuit kennt.

Die aktuelle Implementierung verwendet für eine anonymisierte Verbindung drei Mixe (in Abb. 1 grün gefärbt), von denen der letzte als Exit-Server bezeichnet wird: Dieser hat streng genommen den Status des Empfängers beim Onion-Routing und leitet die Nachricht anschließend an den eigentlichen Empfänger außerhalb des TOR-Netzwerks weiter.

Das bedeutet naturgemäß, dass beim Exit-Server die Nachricht unverschlüsselt vorliegt. Dies wäre eigentlich nicht erwähnenswert, da die Anonymisierung dadurch nicht beeinträchtigt wird. Allerdings scheinen sich viele Anwender nicht bewusst zu sein, dass TOR keinen Fokus auf die Wahrung der inhaltlischen Vertraulichkeit legt. Unlängst hat ein Betreiber leicht manipulierter Exit-Server eine große Anzahl E-Mail-Zugangsdaten und andere vertrauliche Inhalte abgefangen und teilweise veröffentlicht, um auf entsprechend leichtsinnige Nutzung und die Gefahr böswilliger Exit-Server hinzuweisen [3].

Innerhalb des TOR-Netzwerks als der Gesamtheit aller Mixe kann ein Knoten als einfacher Onion-Router auftreten oder zusätzlich die Rolle eines so genannten Directory-Servers annehmen, der Informationen über andere Onion-Router verwaltet. "Einfache" Router öffnen demgegenüber im Wesentlichen einen ihrer Ports für das Onion-Routing und warten auf eingehende Verbindungen anderer Knoten.

Abbildung 1: Das TOR-Netzwerk

Hier kommt der zweite Teil der TOR-Software ins Spiel: der Onion-Proxy. Dieser arbeitet – oberflächlich betrachtet – als SOCKS-Proxy [4] und kann dadurch TCP-Verbindungen jeder Art als Proxy bedienen, also auch nicht-HTTP-Anwendungen anonymisieren. Darüber hinaus setzt der Onion-Proxy natürlich das gesamte Onion-Routing um, eine wesentliche Aktivität ist also der Aufbau von Circuits über das TOR-Netzwerk. Und nicht zuletzt umfasst der Proxy eine Funktion zur anonymen Bereitstellung von Server-Diensten: Clients können über diese "Hidden Services" Verbindungen zu einem Server mit Onion-Proxy herstellen, ohne dessen IP-Adresse zu kennen.

Hidden Services

Wenn ein Server zum ersten Mal über ein Onion-Proxy einen Hidden Service anbietet, generiert er ein Public-Key-Schlüsselpaar und wählt zufällige Onion-Router aus dem TOR-Netzwerk aus, die er als so genannte Introduction Points benutzt. Er baut so viele Circuits auf, dass jeder dieser Knoten einmal als letzter Onion-Router auftritt (Pfade "1" in Abb. 2). Anschließend erstellt der Server einen so genannten Deskriptor für seinen Dienst, der den generierten Public Key sowie eine Liste der ausgewählten Introduction Points enthält, und veröffentlicht diesen auf einem Directory-Server (2). Dieser legt den jeweiligen Deskriptor unter einem Hash-Wert ab, den er aus dem öffentlichen Schlüssel des Deskriptors generiert. Der Server erstellt ebenfalls diesen Hash-Wert und der Betreiber kann über geeignete Kanäle ("out-of-band") verbreiten, dass sein Dienst fortan unter der Adresse hash.onion erreichbar ist.

Möchte ein Client auf hash.onion zugreifen, kann er mittels des Hash-Wertes bei einem Directory-Server den Deskriptor des zugehörigen Service herunterladen (3); er erhält damit unter anderem die Liste der Introduction Points. Anschließend wählt der Client zufällig einen Onion-Router als so genannten Rendezvous-Point aus und erstellt einen Circuit mit diesem Endpunkt (4). Um dem Hidden Service den Rendezvous-Point mitzuteilen, baut der Client einen weiteren Circuit zu einem der Introduction Points auf und übermittelt ihm die entsprechenden Informationen (5), sodass der Server jetzt seinerseits einen Circuit mit dem Rendezvous-Point als letztem Knoten erstellen kann (6).

So werden die beiden Circuits am Rendezvous-Point zusammengeführt [5] – der Client kann also eine Verbindung zum Hidden Service aufbauen, ohne dessen IP-Adresse zu erfahren. Der Hidden Service bleibt zudem auch gegenüber allen verwendeten Knoten anonym: Mit dem Directory-Server hat er über einen anonymisierenden Circuit kommuniziert und ihm nur die Adressen mehrerer Introduction Points mitgeteilt, mit denen er ebenfalls nur über Circuits Verbindungen herstellt – und auch zum Rendezvous-Point baut er die Verbindung über einen Circuit auf, was die Anonymität gewährleistet.

Abbildung 2: Hidden Services im TOR-Netzwerk

Hilfreiche Tools

Zum Aufruf eines Hidden Service muss ein Client allerdings die TOR-Software installiert haben. Darüber hinaus bietet sich bisweilen an, noch weitere Software zu installieren: zum Beispiel Vidalia ( www.vidalia-project.net) und Privoxy ( www.privoxy.org), die häufig im Paket mit der TOR-Software zum Download angeboten werden. Vidalia ist eine grafische Benutzeroberfläche zur Steuerung von TOR, die den Anwender bei der Konfiguration des Onion-Proxy und der Einrichtung seines Rechners als Onion-Router unterstützt. Außerdem bietet Vidalia weitere interessante Funktionen an, etwa eine Übersicht der aktiven Onion-Router oder eine Weltkarte, in der für Circuits genutzte Onion-Router eingezeichnet sind. Man kann aber auch problemlos ohne Vidalia einen TOR-Knoten betreiben oder den Onion-Proxy nutzen.

Im Gegensatz dazu ist die Funktionalität von Privoxy, einem HTTP-Proxy mit Filterfunktionen, häufig notwendig, um TOR als Anonymisierungsdienst zu nutzen: Um beispielsweise die korrekte Behandlung von .onion-Adressen für Hidden Services sicherzustellen, sollte man bei der TOR-Nutzung auch den DNS-Lookup stets über den Onion-Proxy laufen lassen – für .onion-Adressen erfolgt dann natürlich keine DNS-Abfrage, sondern eine Auflösung des Hidden-Service-Mechanismus. Wenn eine HTTP-Anwendung derartige Lookups über die allgemeine Proxy-Konfiguration nicht unterstützt, dann hilft Privoxy weiter: als HTTP-Proxy eingesetzt gehen alle HTTP-Anfragen dorthin, bevor die Namensauflösung stattfindet – Privoxy wiederum nutzt den Onion-Proxy als SOCKS-Proxy, sodass hierüber auch DNS-Anfragen vom Onion-Proxy ausgeführt werden können.

Alternativ zu Privoxy kann natürlich auch jeder andere HTTP-Proxy Verwendung finden, der als SOCKS-Wrapper konfigurierbar ist, zum Beispiel FreeCap oder SocksCap. Im Zusammenhang mit TOR als Anonymisierungsdienst wird aber bevorzugt Privoxy eingesetzt, da dieser auch als Content-Filter für den HTTP-Verkehr agiert und alle Client-Inhalte herausfischen kann, die dessen Identität verraten würden.

Web-Services mit TOR

Über die Hidden Services lassen sich auch Web-Services anonymisieren: Zuerst muss dazu natürlich die TOR-Software auf dem betreffenden Host installiert werden, um den Onion-Proxy zu installieren. Die Grundkonfiguration zum Anschluss an das TOR-Netzwerk und zur Bereitzustellung von Hidden Services erfolgt in der torrc-Datei. Dabei ist einerseits ein Arbeitsverzeichnis anzugeben, das zur Speicherung temporärer Daten geeignet ist. Bedeutender sind die Parameter, über den ein virtueller Port sowie die Zieladresse für den Hidden Service definiert werden: Diese Einstellung legt also fest, wohin auf hash.onion:virtualport eingehende Anfragen weitergeleitet werden, wobei der Eingangsport (virtualport) sowie Zieladresse und -port frei konfigurierbar sind. Sofern die TOR-Software auf dem Web-Service-Host installiert ist, genügt localhost als Zieladresse. Beim Starten der TOR-Software erhält man alsdann die .onion-Adresse als Pseudonym für den konfigurierten Service.

Diese anonymisierte Adresse ist unbedingt auch in den Komponenten der Web-Service-Infrastruktur zu verwenden, um alle Hinweise auf die wirkliche IP-Identität zu eliminieren. Das Vorgehen dazu ist jedoch unkompliziert, denn jede Angabe des Hostnamens in den Beschreibungsdaten (WSDL, UDDI oder WSIL) kann einfach durch die .onion-Adresse nebst virtuellem Port ersetzt werden – in den SOAP-Nachrichten sind ohnehin keine kritischen Angaben vorhanden.

In Web-Service-Description-(WSDL)-Dokumenten sind es speziell die "Port"-Elemente, in denen über das Attribut "location" Bezug auf die Adresse des Hosts genommen wird (vgl. Abb. 3): Beim Publizieren in einem UDDI-Verzeichnis (Universal Description, Discovery, and Integration), wozu der Host natürlich ebenfalls eine anonymisierte Verbindung verwenden sollte, sind vor allem die im "bindingTemplate"-Element angegebene Adresse des Web-Service sowie die in "tModel"-Elementen möglicherweise auftretenden Referenzen auf Beschreibungen, die auf dem Host liegen (wie WSDL-Dokumente), zu beachten. Werden zusätzlich Dokumente des WSIL-Standards (Web Services Inspection Language) eingesetzt, sollten auch alle darin auftretenden Referenzen die .onion-Adresse als Pseudonym verwenden.

<?xml version="1.0" encoding="utf-8"?>

<!–Generated by WSDLDefinitionsParser–>

<wsdl:definitions xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
        name="TorWebServiceWsd" targetNamespace="urn:TorWebServiceWsd" 
        xmlns:bns0="urn:TorWebServiceWsd/Config1/document" 
        xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/">

        <wsdl:import location="./bindings/Config1_document.wsdl"
                namespace="urn:TorWebServiceWsd/Config1/document"/>
        <wsdl:service name="TorWebService">
                <wsdl:port name="Config1Port_Document" binding="bns0:Config1Binding">
                        <soap:address location="http://vt43talxysae6bvi.onion:8888/
                        TorWebService/Config1?style=document"/>
                </wsdl:port>
        </wsdl:service>
</wsdl:definitions>

Anwendungsfälle

Anonyme Web-Services können immer dann sinnvoll Anwendung finden, wenn ein Service-Provider den Zusammenhang zwischen einem Web-Service und der IP-Adresse seines Hosts verdecken will. Ein naheliegender Hintergrund wäre es, dass er ganz schlicht seine Identität geheim halten will – aber dies ist nicht die einzig denkbare Motivation. Die bisher vom Autoren ausgemachten Anwendungsszenarien lassen sich in drei Gruppen einteilen:

Allgemeine B2Bi-Szenarien

Anonyme Web-Services können immer dann nutzbringend sein, wenn der Service-Provider zum eigenen Vorteil seine Identität nicht preisgeben möchte, weil deren Bekanntheit ungewollte Auswirkungen hätte, beispielsweise in Form von Wettbewerbsvorteilen für die Service-Consumer. Denkbar sind hier verschiedenste Business-to-Business-Integration-(B2Bi)-Szenarien, zum Beispiel wenn ein Unternehmen einen Auftrag in Form einer Ausschreibung per Web-Service vergibt. Wenn man aus Wettbewerbsgründen nicht möchte, dass Konkurrenten davon Notiz nehmen, sollte die Ausschreibung anonym erfolgen – das setzt natürlich voraus, dass auch der Inhalt der Ausschreibung nicht sofort ihren Urheber verrät. Das Verfahren bietet sich also besonders für standardisierte, häufig zu vergebene Aufträge an.

Schutz des Marktplatzes bei B2Bi

Möglich ist auch, dass ein Unternehmen als Nachfrager (Service-Requestor) daran interessiert ist, dass ein Service-Provider bestimmte Dienste für den B2B-Bereich anonym anbietet, was auch vertraglich festgelegt werden kann. Beispielsweise könnte ein Online-Versandhaus seinen Zulieferern die Auflage machen, ihre Web-Services zu anonymisieren, damit niemand die Adresse der Zulieferer herausfinden und dann direkt bei diesen bestellen kann.

Mobile Computing

Dieses Szenario ist zwar heute noch nicht top-aktuell, aber interessant, sofern sich das Internet weiter zu einer Peer-to-Peer-Architektur entwickelt, in der jeder sowohl Anbieter als auch Konsument von Diensten ist. Wer dann Web-Services auf einem mobilen Gerät betreibt, müsste die zugehörigen Informationen ebenfalls in einem UDDI-Verzeichnis publizieren. Im mobilen Einsatz in verschiedenen WLANs wäre man ohne anonymisierte Dienste dann in der Regel persönlich zu orten, da beispielsweise die dynamischen IP-Adressen von WLANs und Einwahlknoten lokalisierbar sind (z. B. über  www.ip2location.com oder  www.geobytes.com/IpLocator.htm).

Verwendet der Benutzer allerdings mit TOR anonymisierte Web-Services, so wird diese Beobachtbarkeit aufgehoben: Denn Zieladresse des Dienstes ist ja dann die .onion-Adresse, aus der sich keine IP-Adresse und damit auch kein Aufenthaltsort feststellen lässt. Ein weiterer positiver Effekt ist, dass die Service-Adresse immer gleich bleibt und damit der UDDI-Eintrag nicht ständig aktualisiert werden muss.

Abbildung 4: Ohne anonymisierte Dienste würden Web-Services mobiler Systeme über die IP-Nummer des jeweiligen Einwahlpunkts Dritten ein Tracking ermöglichen.

Fazit

Anonymisierende Anwendungen wie TOR können auch für den professionellen Einsatz interessant sein. Dabei ist allerdings anzumerken, dass die TOR-Entwickler keine Garantien für den Grad oder die Zuverlässigkeit der mit dem System verbundenen Anonymisierung geben. Die praktische Verfügbarkeit von TOR als Dienst hingegen ist sehr gut: Zum einen besteht das TOR-Netzwerk schon aus einer recht großen Zahl von Onion-Routern, zum anderen ist die verwendete P2P-Architektur sehr resistent gegen Denial-of-Service-Angriffe: Attacken gegen einzelne Knoten lassen sich bisher zwar nicht ausschließen (vgl. [7]), aber es gibt ja dann ausreichend andere Knoten, die sich gleichwertig verwenden lassen.

Man kann sicherlich sagen, dass es für die Weiterentwicklung der TOR-Software positiv wäre, wenn beispielsweise gewerbliche Online-Dienste oder auch verstärkte Überwachungstendenzen ein erhöhtes Interesse an Anonymität im Internet hervorbrächten. Derzeit scheinen die Chancen nicht schlecht zu stehen, dass zumindest einer dieser Fälle eintritt. Zudem sollte man nicht die Möglichkeit übersehen, aus dem professionellen Bereich auf die Fortentwicklung von Anonymisierungsdiensten Einfluss zu nehmen und somit frühzeitig interessante Nutzungsmöglichkeiten für das unternehmerische oder behördliche Umfeld zu erschließen.

Steffen Hitzemann ist Dipl.-Wirtschaftsinformatiker (BA) und als Master-Student im Bereich Product Security der SAP AG tätig.

zurück zum Inhalt
© SecuMedia-Verlags-GmbH, 55205 Ingelheim (DE),
<kes> 2007^#6, Seite 78
tag:kes.info,2007:art:2007-6-078