Onion Routing und Tor

Wer braucht Anonymität?

• Journalisten, Dissidenten, Whistleblowers (Indymedia, Blogger, Iran, Tibet)
• Zensurresistente Publizisten und Leser (e.g. Forschung über Rechtsradikalität)
• Sozial unerwünschte Kommunikation (Ärzte, Selbsthilfegruppen, Missbrauchsforen)
• Law enforcement (anonyme Hinweise, Verbrechensmeldungen)
• Firmen (Industriespionage, Supplier, Kunden)
• Du (Mit wem tauscht du Mails aus? Welche Seiten besuchst du? Wo arbeitest du? (Stalking) Was kaufst du? Was für Ärzte besuchst du? (Abtreibung?) Was für Bücher liest du? (Amazon-Wunschlistenfall))
• Regierungen (Unverfälschte Umfragen/Wahlen, Austausch zwischen sich nicht vertrauenden Staaten)

Wären Kriminelle nicht auch gerne anonym?

Diese Vorstellung liegt durchaus im Rahmen des Möglichen. Doch sollte man hierbei bedenken, dass den Kriminellen ihre Umwelt nicht so sehr am Herzen liegt wie manch anderem Menschen.

• Identitätsdiebstahl
• Zeitweise Unidentifizierbarkeit (e.g. Selbstmordattentäter, Märtyrer)
• Motivation, komplexere Anonymitätssysteme zu verwenden
• Motivation, Anonymität zu erkaufen

Normale Menschen, Polizei, Regierungen und Firmen haben diese Möglichkeit nicht

Und was ist mit intrusion?

• Brich in ein System ein
• Vernichte die Logfiles
• Rootkits
• Suche dir ein anderes System und fange von vorne an
• Wozu braucht man dann noch Tor?

Normale Menschen, Polizei, Regierungen und Firmen haben diese Möglichkeit nicht

-> Mist.

Problem

• In öffentlichen Netzen (e.g. Internet) verraten die Verbindungsheader, wer mit wem kommuniziert
• Paketrouten können aufgezeichnet werden (e.g. Lawful Interception)
• Verschlüsselung betrifft nicht die Routingdaten!

Warum ist das ein Problem?

• Unterdrückung von sensibler Kommunikation
• Zensur
• Einbrüche in Intimsphäre
• Industriespionage
• Verfälschung von Umfrageergebnissen
• Keine geheimen Wahlen möglich
• Kommunikation zwischen klassifizierten Entitäten nicht möglich

Sollte einen da eigentlich nicht ein Dialup-Internetzugang schützen?

• Man weiss, dass der Zugang über eine Dialup-Leitung stattgefunden hat
• Auskunftspflicht der Provider, die noch dazu nicht immer gut informiert sind (Urheberrechtsdelikte)

Lösungsanforderungen

Eine Lösung dieses Problemes erfordert somit eine Reihe von Eigenschaften, die die Kommunikation erfüllen muss:

• Man muss Traffic anderer Leute transportieren, damit nicht ersichtlich ist, welcher Traffic welchem Benutzer zugeordnet werden kann
• Man will nicht einem Einzelnen vertrauen (distributed trust)

-> die Sicherheit basiert auf Diversität und Verteilung des Netzes

• Sender und Empfänger sollen voreinander geschützt sein (dürfen nichts übereinander erfahren)

-> Channel- und Data-Anonymity

• Beobachter von Aussen dürfen keine Ahnung haben was vor sich geht
• Beobachter von innen dürfen keine Ahnung haben was vor sich geht

-> Channel-Anonymity

Anonyme authentisierte Verbindungen machen also durchaus Sinn! (Und bieten zum ersten Mal echte Pseudonymität) Dabei sollte die Authentisierung lediglich über die Daten statfinden, da es über den Channel offensichtlich nicht möglich ist (IP wechselt u.U. während einer Session auf einer Website etliche Male)

Bisherige Ansätze

Proxies

Ein Anonymitätsproxy verschleiert den Ursprung einer Verbindung.

Hierbei wird durch einen Provider einer oder mehrere Proxies hintereinandergeschaltet und erledigen dann den Datenaustausch für den Benutzer, so dass dieser nicht zum wirklichen Zielhost verbinden muss. Dies funktioniert für Web-Verbindungen ganz gut (SSL, TLS, SSH und andere symmetrischen low-cost-Verschlüsselungsmechanismen). Beispiele wären der Anonymizer, JAP und wie sie alle heissen.

Vorteile:

• Einfach einzurichten
• Fokussiert viel Traffic auf einen Punkt und erschwert somit Trafficanalyse

Nachteile:

• Schwer skalierbar (Load balancing kaum anwendbar, da die Load ja das eigentliche Problem ist)
• Bei grossen Firmen führt dies zu wechselnden IPs (Round Robin Proxy)
• Single point of failure! (Kompromittierung, Angriff, rechtliche Anforderungen)

Mixes

Ein Mix vertauscht und dechiffriert die erhaltenen Datenpakete.

Ein Mix entschlüsselt hüllenweise Daten aus einem Stream, wobei er sie im Kommunikationskanal beliebig austauscht, so dass man hinterher nicht mehr sagen kann, welcher Plaintext zu welchem Ciphertext gehört (Permutation).

Nach dem Chaum-Model für Mixes (1981) verschlüsselt ein Client eine Nachricht für eine Mixerkette dreimal, so dass am Ende gilt:

Jeder der Mix-Server in der Kette hat dann einen Schlüssel für die jeweils äusserste Hülle der Verschlüsselung. Solange nur ein einziger der Server die Permutation wie gewünscht ausführt, bleibt die Funktionalität der Mixerkette erhalten, und niemand kann sagen, welcher Plaintext zu welchem Ciphertext gehört.

Vorteile:

• Daten- und Kanalanonymität gegeben
• Ein einziger vertrauenswürdiger Host in der Kette reicht um die Sicherheit aufrechtzuerhalten

Nachteile:

• Interaktivität stark eingeschränkt (laggy)
• Fokus von Mixerketten lag auf eMail und anderen Anwendungen, die hohe Latenzzeiten tolerieren
• Jede Ebene von Nachrichten erfordert teure Public-Key-Kryptographie
• Keine benutzerfreundliche Implementation vorhanden

First Generation Onion Routing

In diesem Modell schleudert ein Rechner ein Onion-Paket mit Onion-Routinginformationen (siehe später) in das Netz hinaus (eine sogenannte onion). Diese wird dann von eine Reihe Rechnern geroutet und tritt schliesslich aus dem Netz wieder aus, um den Zielrechner als normales Datenpaket zu erreichen. Hierbei waren jedoch einige Probleme noch nicht bedacht:

• Die verwendeten Router waren nicht durch irgendeine Instanz als vertrauenswürdig einstufbar
• Bei jedem Paket ergab sich erneut die Möglichkeit, die Identität des Senders festzustellen
• immernoch teure Public-Key-Krypto

Das Prinzip des Onion Routers

Geschichte

Der Onion-Router (Tor) implementiert die 2nd Generation Onion Routing-Spezifikation. Die Idee war hierbei, die Vorteile von Mixes und Proxies zu verbinden und somit zu einem Modell zu kommen, in dem die teure Public-Key-Kryptographie auf ein Minimum reduziert wurde. Die Designidee wäre somit wie folgt:

• Verwendung (teurer) Public-Key-Kryptographie um den Anonymisierungskreislauf aufzubauen
• Verwendung (billigerer) symmetrischer Kryptographie um Daten zu übertragen
• Verteilte Vertrauensverhältnisse wie bei Mixes

Funktion

Ein Tor-Client baut eine Verbindung über 3 verschiedene Server auf, wobei jeder eine Verschlüsselungsschicht auflöst.

Als Erstes nach dem Start etabliert der Tor-Client eine Art Kreislauf für die Daten durch das Tor-Netzwerk. Er wählt hierbei aus dem Tor-Directory zufällig 3 verschiedene Nodes aus. Er baut dann zur ersten Node (der Entry-Node) eine TCP-Verbindung auf, authentisiert diese kryptographisch und handelt einen symmetrischen Sitzungsschlüssel aus. Dann veranlasst er die Entry-Node, eine Verbindung mit dem zweiten Server, der Middle-Node, aufzunehmen. Er handelt einen neuen Sitzungsschlüssel aus und lässt eine Verbindung zum letzten Server, der sogenannten Exit-Node, aufbauen, In der entstehenden Situation erhält jede Node nur für sie verschlüsselte Daten, die wiederum für die nachfolgende Node verschlüsselte Daten enthält. Somit begrenzt sich das Wissen einer jeden Node lediglich darauf, von welcher Vorgängernode sie die Daten zu welcher Nachfolgenode schicken soll. Der Ursprung des Datenstromes sowie das Ziel ist nur der Entry- bzw. der Exit-Node bekannt.

Über den Kreislauf werden dann Verbindungen zu verschiedenen Endpunkten aufgebaut.

Auf der Clientseite arbeitet der Tor-Client im Prinzip als Socks-Proxy. Man kann mit Socks-Clients über Tor Verbindungen zu verschiedenen Servern im Internet aufbauen, genau so wie das mit jedem anderen Socks-Proxy der Fall wäre. Dabei veranlasst der Tor-Client die Exit-Node über den angelegten Kreislauf, eine Verbindung zum gewünschten Zielhost aufzubauen.

Die Kreisläufe wechseln alle 10 Minuten, doch die Verbindungen werden einen Kreislauf aus Sicherheitsgründen nie verlassen, da sich jedesmal wenn eine Verbindung auf einem Kreislauf aufgebaut wird für einen Angreifer die Chance erigbt, durch Zeitdifferenzanalysen (timing attacks) herauszufinden, zu welchem Client eine Verbindung gehört.

Achtung, DNS!

Eine Gefahr für die Anonymität des Benutzers geht durch entfleuchende DNS-Anfragen aus. Die Protokolle Socks4A und Socks5 unterstützen beide Verbindungen zu Hostnamen, doch manche Clients lösen dennoch wie beim alten Socks4 die Hostnamen selbst auf.

Wenn nun ein Benutzer eine DNS-Anfrage für www.google.ch stellt, und anschliessend eine Verbindung durch das Tor-Netzwerk macht, ist es wohl relativ offensichtlich, mit wem er eine Verbindung initiieren will...

(etwas) Abhilfe sollte ein öffentlicher DNS-Server schaffen. Dann sieht der eigene ISP die Request zumindest nicht! Die Anfrage dauert dann zwar ein paar Sekunden, aber es sollte halt jedem selbst überlassen sein!

Hier findet man eine Liste mit freien, öffentlichen DNS-Servern: http://www.tech-faq.com/lang/de/public-dns-servers.shtml

Was auch ganz witzig ist, dass eine ganze Menge DNS-Server großer Firmen schlecht bzw. falsch konfiguriert sind und diese auch verwendet werden können! Aber ACHTUNG, dies ist unter Umständen eine Straftat!

Wer sind die Nodes?

Damit die Clients die Tor-Nodes auch finden können, gibt es eine Art Verzeichnisdienst. Es gibt im Moment 2 Verzeichnisserver im Tor-Netz, Moria1 und Moria2. Die Public Keys für diese beiden Rechner befinden sich im Tor-Quellcode und sind somit als preshared keys die oberste Vertrauensinstanz.

Das Verzeichnis selbst ist dezentralisiert gespeichert. Jeder Tor-Router hält eine Kopie des Verzeichnisses vor, welche von einem der beiden Verzeichnisserver digital signiert wurde. Somit kann man von jedem beliebigen Server das Verzeichnis abrufen, ohne dabei in Gefahr zu laufen, dass es sich dabei um eine manipulierte Kopie handeln könnte.

Somit obliegt es den Verzeichnisservern, ob es einem Router erlaubt wird, in das offizielle Tor-Netzwerk aufgenommen zu werden. Somit kann man einen sogenannten Sibyl-Angriff verhindern, ohne dabei Menschen dazu einsetzen zu müssen. Gleichzeitig wird eine Übernahme des Netzes verhindert, indem es nicht trivial möglich ist, eine grosse Menge an korrupten Routern in das Netz zu schleusen.

Versteckte Dienste

Alice kommuniziert mit Bob über den ausgehandelten Rendezvouzpunkt.

Die Idee von versteckten Diensten ist, dass Alice mit Bob eine Verbindung aufbauen kann, ohne dabei zu erfahren, wer Bob ist und wo er sich befindet, oder was seine IP-Addresse ist.

Versteckte Dienste sind

• Von überall erreichbar, wo irgendeine Form von Verbindung zum Internet möglich ist (NAT-Traversal, funktionieren sogar durch HTTP-Proxies)
• Zensurresistent
• Resistent gegenüber DoS-Angriffen
• gegen physikalische Angriffe gesichert (naja, man findet sie halt nicht)

Wenn sich also Bob nun entscheidet, einen versteckten Dienst anzubieten, dann trägt er das in die Konfiguration seines Tor-Clients ein. Der baut dann Verbindungen zu einigen sogenannten Einführungspunkten auf. Dann meldet er seinen Dienst mitsamt der Liste der Einführungspunkte im Tor-Verzeichnis an. Er ist dann durch den Hashwert seines Public-Keys als versteckter Dienst identifizierbar.

Wenn Alice nun eine Verbindung mit Bob aufbauen will, wählt sie einen der Einführungspunkte aus der Verzeichnisliste aus und sendet diesem den Nicknamen eines beliebigen Tor-Routers, der als Rendezvouspunkt fungieren soll. Zusammen damit sendet sie irgendeine Form von Authentisierung durch den Einführungspunkt zu Bob. Bob entscheidet dann, ob er mit Alice reden will, und verbindet ebenfalls zum Rendezvouzpunkt. Dieser kümmert sich dann um den Datenaustausch.

Probleme

Akzeptanz ist ein grösseres Problem der Tor-Benutzer. So verweigert zum Beispiel die englischsprachige Wikipedia, wegen Vandalismus gesperrte Exit-Nodes wieder zu entsperren, so dass das Editieren der englischen Wikipedia über das Tor-Netzwerk unmöglich ist. Die deutsche und französische Wikipedia hingegen akzeptieren das Editieren von Seiten mit Tor und sind relativ zuvorkommend, was das Entsperren von Exit-Nodes betrifft. Es geht auch eine Bitte um, dass man vor dem Sperren bitte in's Tor-Directory schauen mag. Als Gründe dafür wurde u.A. angeführt, dass Leute sich so trauen, Insider-Informationen auf der Wikipedia zu hinterlassen, oder kontroverse Meinungen einzubringen, und dass ein Medium, das auf Diskussion ausgelegt ist, von Anonymität profitiert und mit deren Nachteilen fertigwerden muss.

Abgesehen von diesem Akzeptanzproblem gibt es noch ein paar technische Probleme des Tor-Prinzips:

• Ein Angreifer, der Kontrolle über grosse Teile des Internets hat, kann durch statistische Laufzeitanalysen Korellationen zwischen bei Benutzern ausgehenden Daten und den Daten, die die Exit-Nodes verlassen, herstellen
• Da Tor die Kreisläufe nur alle 10 Minuten wechselt, ist es durchaus möglich, Korrelationen zwischen nonymen und anonymen Verbindungen zu erstellen
• Ein Angreifer, der im Tor-Netz selbst sitzt, kann einen versteckten Dienst finden indem er ihn solange aufruft bis er als Node direkt vor dem Service gewählt wird. Bedingung für diesen Angriff ist, dass der versteckte Dienst nicht selbst auf einem Tor-Router läuft.

Designfragen

Die folgenden Designfragen sind in Bezug auf Tor noch nicht geklärt:

• Padding
• UI vs. kein UI? (Es gibt einen UI-Design-Wettbewerb)
• AS-Level-Pfade und OSPF-ähnliche Algorithmen?
• Zufällige Pfadlängen?
• China?

Zahlen und Fakten

• Das Netzwerk läuft ununterbrochen seit Oktober 2003.
• 320 verfügbare exit nodes in 32 Ländern
• Basiert auf Freiwilligen (anders als das Freenet)
• ungefähr 50'000 Benutzer... (Wer kann das schon sagen? Es ist ein Anonymitätssystem!)
• Nodes bearbeiten zwischen 1 und 100 GB Traffic per Tag (Penrose: 16)
• Netzwerk war noch nie komplett down
• Einfacher Server/Client in einem Programm (~40'000 Zeilen Code)
• Läuft als normaler Benutzer, braucht keinen Root-Zugriff, keine speziellen Berechtigungen, passt in ein BSD jail
• Flexible Exit-Policies erlauben es, festzulegen, was für Verbindungen ein Host erlaubt, wenn er als exit node verwendet würde
• Es gibt Tor-Server, die auf X-Boxen laufen
• Es gibt Tor-Server, die auf Linksys-Routern laufen

Tor installieren

• Code ist frei verfügbar (BSD-Lizenz)
• Spezifikation offengelegt

Installation von Tor

Als einfachste Installationsvariante kann man Tor zum Ausprobieren für den lokalen Rechner installieren. Dabei muss man lediglich das für das Betriebssystem bestimmte Paket installieren oder Tor von Hand kompilieren. (Auf kompliziertere Installationen wie im Jail oder als Server oder hidden service werde ich an dieser Stelle nicht eingehen.)

Debian Linux/Ubuntu Linux/Debian *BSD/GNU Hurd:

 % apt-get install tor

NetBSD/DragonFlyBSD/Thundrix Linux:

 % cd /usr/pkgsrc/net/tor && make install

FreeBSD/OpenBSD/MirBSD:

 % cd /usr/ports/net/tor && make install

Wenn das verwendete System kein ansprechendes Paketmanagement hat oder dieses Tor nicht mitsieht, kann man auch pkgsrc auf dem Rechner installieren und Tor daraus installieren.

Anschliessend braucht man Tor einfach nur zu starten (Beispiel: NetBSD):

 % /etc/rc.d/tor start

Nun kann man als Socks4a- oder Socks5-Server jeweils localhost:9050 eintragen und Tor verwenden.

Privoxy für Webbrowser

Da Mozilla Firefox für den DNS-Angriff anfällig ist, empfiehlt sich für den Einsatz mit Tor sowieso die Installation von Privoxy, da dieser Proxy von Haus aus verräterische Daten aus den HTTP-Headern filtert. Die Installation erfolgt analog zu Tor:

Debian Linux/Ubuntu Linux/Debian *BSD/GNU Hurd:

 % apt-get install privoxy

NetBSD/DragonFlyBSD/Thundrix Linux:

 % cd /usr/pkgsrc/www/privoxy && make install

FreeBSD/OpenBSD/MirBSD:

 % cd /usr/ports/www/privoxy && make install

Dann sollte man die /etc/privoxy/config folgendermassen editieren:

• Eine Zeile einfügen: forward-socks4a / localhost:9050 . (mit dem Punkt)
• Die Zeile mit logfile logfile auskommentieren
• Die Zeile mit jarfile jarfile auskommentieren

(Wenn wir unsere Privatsphäre schützen wollen, ist es wohl nicht zu vermessen anzunehmen, dass wir keine Logfiles behalten wollen.)

Wir starten dann privoxy neu:

 % /etc/rc.d/privoxy restart

Nun braucht man nur noch dem Browser zu sagen, dass man den HTTP-Proxy 127.0.0.1 mit dem Port 8118 verwenden will.

Als Test sollte man nun versuchen, das Hidden Wiki aufzurufen. Gelingt dies, ist der Browser richtig konfiguriert. Gelingt es nicht, ist es wahrscheinlich, dass entweder die DNS-Anfragen immer noch nicht über Tor ausgeführt werden, oder gar die Verbindung überhaupt nicht über Tor läuft.

Socat für SSH

Um die SSH über Tor laufen zu lassen, kann man zum Beispiel das Programm socat verwenden. Dazu müssen wir es zuerst installieren:

Debian Linux/Ubuntu Linux/Debian *BSD/GNU Hurd:

 % apt-get install socat

NetBSD/DragonFlyBSD/Thundrix Linux:

 % cd /usr/pkgsrc/net/socat && make install

FreeBSD/OpenBSD/MirBSD:

 % cd /usr/ports/net/socat && make install

Anschliessend müssen wir der SSH beibringen, Tor zu verwenden. Dafür editieren wir wahlweise für einen einzelnen Benutzer die ~/.ssh/config oder für alle Benutzer die /etc/ssh/ssh_config und fügen folgende Formulierung ein:

 Host *
   ProxyCommand socat STDIO SOCKS4A:127.0.0.1:%h:%p,socksport=9050

Wahlweise, wenn man nur die .onion-Nodes über Tor erreichen will, reicht auch der folgende Eintrag:

 Host *.onion
   ProxyCommand socat STDIO SOCKS4A:127.0.0.1:%h:%p,socksport=9050

Nun kann man ausprobieren, ob die SSH tut wie sie soll:

 % ssh -l anonymous oxdjh4bmutfxv2ba.onion

Das Passwort lautet sarahiscute, und Cone bittet darum, dass nicht allzusehr randaliert wird.

Weblinks

• Offizielle Tor-Website
• The Hidden Wiki - Liste mit interessanten .onion-Services
• Tor FAQ on noreply.org
• Torifying HOWTO - wie man verschiedene Anwendungen zur Zusammenarbeit zwingt
• Privoxy
• Tor-Verzeichnis (eine lesbare Variante)