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

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...

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

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)

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:

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

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