datenschleuder98/artikel/torbridges.tex

%\useclass{datenschleuder}
\begin{DSarticle}[
        runninghead=Tororists,
author={Moritz, <moritz@zwiebelfreunde.de>},
title={We Need More Tororists},
DSabstract={Der ehemalige NSA-Analyst Thomas Drake forderte ``We need more Tororists'' auf dem letzten Chaos Communication Congress 29C3. [1] Hierfür erntete er großen Applaus. Höchste Zeit, erneut einen Blick auf das Anonymisierungswerkzeug Tor zu werfen.}
]

Anonymisierung ist nicht gleich Verschlüsselung. Dank langsam aber stetig um sich greifender Verschlüsselungsverfahren stützt sich die Arbeit von Geheimdiensten heutzutage immer weniger auf den Inhalt von Kommunikation, als auf die Erfassung und Analyse von Beziehungsstrukturen selbst: Wer hat mit wem wie lange und wie häufig kommuniziert? Studien aus den Jahren 2008 [2] und 2010 [3] nutzen Verfahren aus der künstlichen Intelligenz und Sprachverarbeitung, um im verschlüsselten Datenstrom von Voice-over-IP-Gesprächen Sätze zu identifizieren, mit einer Erkennungsrate von durchschnittlich 50\% und für einige häufige Wörter mit über 90\% Trefferquote. Eine weitere Studie beschäftigt sich mit der Erkennung abgerufener Inhalte auf Webseiten, anhand der Größe und den Zeitabständen zwischen den einzelnen Requests. [4] Bei der Anonymisierung von Kommunikation geht es hingegen darum, den Kommunikationspfad selbst zu verschleiern, es also Angreifern zu erschweren, überhaupt nachvollziehen zu können, wer mit wem wann Informationen austauscht. Angreifer können prinzipiell auf jedem Abschnitt der Wegstrecke zwischen Sender und Empfänger lauern: Sie können gezielt den Sender oder den Empfänger überwachen, oder einen oder mehrere der dazwischen liegenden Kommunikationseinrichtungen.

\section{Mixes}
Der Mathematiker David Chaum formulierte 1981 ein grundlegendes Modell für anonyme Kommunikation via E-Mail. [5] Ein ``Mix'' wird beschrieben als ein Mailserver, der Mails nicht sofort weiterreicht, sondern eine Weile ``anstaut'' und dann in anderer Reihenfolge weitergibt. Eine ``Mix-Kaskade'', also mehrere solcher Mailserver hintereinander, verschleiern so effektiv den eigentlichen Sender und Empfänger. Chaum beschreibt auch Ideen für anonymisierte Rückantworten. Mit einigen Ausnahmen wie Andreas Pfitzmanns Mixes für ISDN beschäftigte sich der Forschungsbereich in der Folge die nächsten 20 Jahre vor allem mit diesem Bereich, der verzögerten anonymisierten Kommunikation (``high latency anonymity'', Anonymität mit hoher Latenz). Eine schöne, aktuelle und gut lesbare Einführung in die später Remailer genannten Technologien hat Tom Ritter für das Crypto Project geschrieben. [6]
%FIXME---GRAFIK---

\section{Onion Routing}
Onion Routing als Begriff wurde 1996 von Forschern der US Navy geprägt. [7] Die Idee ist recht simpel: Statt direkt zu kommunizieren, schaltet man Proxies (``Stellvertreter'') dazwischen. Damit ein einzelner Proxy die übertragenen Inhalte nicht mit Sender und Empfänger korrelieren kann, wählt man mindestens zwei solcher Proxies, und verschlüsselt wie folgt: Der erste Proxy, später in der Literatur ``entry node'' genannt, sieht den Sender und weiß, an welchen zweiten Proxy er das verschlüsselte Paket weiterreichen soll – kennt aber weder Inhalt noch Zieladresse. Der letzte Proxy, später ``exit node'' genannt, spricht mit dem eigentlichen Empfänger, kann aber nicht nachvollziehen, woher die Anfrage ursprünglich stammt, da er sie nicht direkt vom Sender erhalten hat. Die gegebenenfalls dazwischen liegenden weiteren Proxies reichen nur verschlüsselte Inhalte weiter. Der Sender präpariert die eigentlichen Inhalte also für den gesamten Pfad und legt so pro Proxy eine Schicht an Verschlüsselung um diese Inhalte – ähnlich den Schichten einer Zwiebel.
%FIXME---GRAFIK---

Im Gegensatz zu Mixes wird also auf eine Verzögerung und Vermischung von Paketen verzichtet. Der wesentliche Vorteil ist, daß sich Onion Routing somit für Dienste wie Web, XMPP und sogar VoIP eignet, die auf niedrigere Latenz angewiesen sind. Der große Nachteil ist, daß das Verfahren keinen Schutz vor ``Ende-zu-Ende-Traffickorrelation'' bietet: Wird sowohl in das Anonymisierungsnetz eingehender Verkehr als auch aus dem Anonymisierungsnetz austretender Verkehr überwacht, lässt sich die Anonymisierung aushebeln. Eine gute Übersicht über aktive und passive Verfahren findet sich im Torproject-Blog. [8]

Trotz der offensichtlich ``besseren'' Anonymisierung durch Mixes und hohe Latenz sieht man das Remailer-Modell heute größtenteils als gescheitert an: Es ist für viele Nutzer und Einsatzzwecke nicht geeignet, und auch das beste Anonymisierungsverfahren hilft nichts, wenn die Nutzer fehlen. Nur dann nämlich kann ein ``Untertauchen in der Masse'' gewährleistet sein. [9] Spannend bleibt das Feld aber durchaus, neuere Ansätze wie das ``Alpha-Mixing'' wollen beide Verfahren verschmelzen. Aber dazu an anderer Stelle oder in einer Fortsetzung mehr. [10]

\section{Tor: Der Prototyp mit 500.000 Nutzern täglich}
Natürlich wollte man sich nicht mit theoretischer Forschung zufriedengeben, bereits 1996 gab es erste Prototypen. Tor wurde dann 2004 als ``Second Generation Onion Routing'' vorgestellt und seitdem beständig weiterentwickelt. Auf die einzelnen Änderungen im Protokoll einzugehen wäre zu umfangreich für diesen Artikel, einen guten Einblick in die Details bieten drei Blog-Artikel von 2012. [11] Was als weiterer Prototyp und als Forschungsspielfeld gedacht war, wurde bald zu einem auch für reale Szenarios eingesetzten Werkzeug. Auch für die Forschung braucht man möglichst echte Daten als Grundlage. Tor versteht sich auch heute noch als ein Forschungsprojekt, jedes Jahr werden neue Papers veröffentlicht, die sich mit Tor auseinandersetzen.

An der Grundidee von Tor hat sich im Laufe der Jahre nichts geändert: Ein generischer Proxy nimmt lokal Anwendungsverkehr entgegen, schleust ihn durch das Tor-Netzwerk und gibt Antworten an die Anwendung zurück. Tor kann dabei immer nur ein Baustein zur anonymen Kommunikation sein. In den ersten Jahren war den Anwendern, zumeist aus unseren Kreisen, klar, daß Ende-zu-Ende-Verschlüsselung und umsichtige Nutzung dazu gehört. Tor manipuliert den Inhalt der Kommunikation nicht – es ist wenig hilfreich, wenn im Datenstrom selbst identifizierende Merkmale enthalten sind. Inzwischen haben auch eine Menge unbedarfter Nutzer berechtigtes Interesse an Anonymisierung, weshalb im Dunstkreis von Tor weitere Entwicklungen entstanden sind, um Nutzer zu schützen. Kursierten lange Zeit Anleitungen, um einen Browser einigermaßen zu härten, damit nicht z.B. externe Plugins wie Java oder Flash von Webseiten eingesetzt werden können um lokale Eigenschaften zu sammeln und zu übertragen, versuchte man es zuletzt erst mit einer Browser-Extension (TorButton) und, nachdem klar wurde daß man leider den Browsern einige gefährliche Dinge (noch) nicht per Extension abgewöhnen kann, mit einem speziell gepatchten Firefox. Chromium eignet sich als Basis momentan nicht, andere Browser schon gar nicht, weil sie nicht Open Source sind.

Eine weitere hilfreiche Extension, die vom EFF und Tor-Entwicklern betreut wird, ist ``HTTPS Everywhere'', im Tor Browser integriert und auch als als eigenständige Extension wichtig: Umfangreiche Regelsätze bringen den Browser dazu, HTTPS-gesicherte Verbindungen zu Webseiten zu bevorzugen. Leider ist es ja immer noch gang und gäbe, ungesicherte Protokolle über Tor oder beispielsweise in offenen WLANs einzusetzen. Bei Tor ist dies besonders problematisch: Da der letzte Proxy, der „exit node“, die ursprüngliche Anfrage ins Internet absetzt, kann er Inhalte mitschneiden (Nicht: den Absender identifizieren, es sei denn, der Inhalt selbst lässt Rückschlüsse zu, wie etwa Login-Informationen). Man munkelt ja, daß ein solcher Mitschnitt zur Gründung von WikiLeaks geführt hat\ldots Die Überzeugungsarbeit geht weiter. Immerhin hat Facebook inzwischen TLS sowohl für die Webseite als auch für den Chat auf XMPP-Basis eingeführt. Lange genug hats gedauert.

Anonymisierung ist über die Jahre zu einem umfangreichen Ökosystem geworden. Die Torproject-Website listet aktuell über 35 Komponenten, die alle um Mitarbeit werben. [12] Einige davon wurden auf dem 29C3 vorgestellt, der einstündige Vortrag sei jedem ans Herz gelegt, der tiefer in die Materie einsteigen will. [13]

\section{Internetzensur und gegenseitige Aufrüstung}
Immer interessanter wurde Tor auch als effektives Werkzeug zur Zensurumgehung, die heutzutage mehr und mehr um sich greift – auch weil Internetzugang langsam in alle möglichen und unmöglichen Weltregionen sickert. Zunächst einmal bieten die öffentlich zugänglichen Tor-Proxies (``Tor Relays'') eine große Anzahl an erreichbaren IPs, und eingehende Verbindungen werden ja sowieso bereits designmässig verschlüsselt. Da der letzte Proxy in der Kette, der ``exit (relay)'', hoffentlich irgendwo wenig oder gar nicht zensiert steht, bietet Tor schon von klein auf einen freien und schwer überwachbaren Internetzugang. Und eine Anonymisierung des Kommunikationspfades liegt im Regelfall durchaus im Interesse derjenigen, die von Zensur betroffen sind. Auch dann, wenn sie am anderen Ende ``nur'' eine aus anderen Gründen negativ zu beurteilende zentralisierte US-Plattform wie Facebook erreichen wollen\ldots

Ohne ins Detail zu gehen, wird ein Probleme deutlich: Damit Tor auf Clientseite einen Pfad durch das Tor-Netz bestimmen und die Pakete entsprechend verschlüsseln kann, müssen alle beteiligten Relays, also deren IP-Adresse, Port und Public Key, für die Verschlüsselung öffentlich bekannt sein. Das macht es Zensoren relativ leicht, Tor zu blockieren: Man besorge sich regelmässig die Liste aller Torknoten und blockiere ausgehende Verbindungen dorthin. Bonuspunkt, wenn der entsprechende Teilnehmeranschluss für genauere Beobachtungen geflagged wird\ldots Prompt liefern westliche und östliche Firewall-Hersteller entsprechende Regelsätze aus, die dann in repressiven Staaten und genauso repressiven Unternehmen zum Einsatz kommen. Oft auch gar nicht bewusst, sondern weil der Admin bequem den Haken setzt und ``gut ist''.

Das erste und universelle Design gegen eine solche Blockade sind ``Tor Bridges'', 2007 eingeführt. Tor Bridges sind Relays, die nicht im öffentlichen Verzeichnis gelistet werden. Sie lassen sich dem eigenen Tor Client manuell beibringen, und dienen als alternative Einstiegspunkte ins Tor-Netz (als ``entry node''). Wie kommt man als Nutzer nun an Bridges, und das, ohne dem Zensor alle Bridge-Adressen auf dem Tablett zu liefern? Ein Bridge-Betreiber kann wählen, ob die eigene Bridge automatisch verteilt werden soll (etwa per Webformular, Email oder [echte] soziale Netze), oder ob er selbst für eine Weitergabe sorgen will. Limitierungen wie ein CAPTCHA und die Herausgabe von immer nur einer Handvoll Adressen sollen dafür sorgen, daß ein Zensor nicht einfach an eine große Menge an Bridges herankommt.

Als nächster Schritt im Zensurwettrüsten blieb den Zensoren und Filter-Herstellern der etwas ressourcenintensivere Weg, sich die Pakete genauer anzuschauen (Deep Packet Inspection). Tor versucht zwar, den Verbindungsaufbau einigermaßen wie den gängiger Browser aussehen zu lassen, ganz verhindern lässt sich aber eine Erkennung der Pakete nicht. China legte bald eine erstaunliche Methode nach, um Torverbindungen zu erkennen: Wird ein generischer TLS-Handshake erkannt, verbindet sich die Große Böse Firewall aktiv mit der Zieladresse und spricht dabei das Tor-Protokoll. Antwortet der Relay, kappen sie die Verbindungen und blockieren die Ziel-IP für einige Zeit. [14] Egal wie sehr man also den Handshake anpasst, China muss sich nur den Gegebenheiten anpassen und das jeweils aktuelle ``Tor sprechen''. Ein dauerhafterer Weg, eine Erkennung zu erschweren, führte zur Entwicklung der sogenannten ``pluggable transports''. 

Die Idee hinter ``pluggable transports'' ist, verschiedene erweiterbare Verschleierungsalgorithmen über die Verbindung zu legen und so eine Erkennung per DPI zu erschweren. Idealerweise entstehen so im Laufe der Zeit möglichst vielfältige Methoden der Verschleierung. Experimentell gibt es beispielsweise den SkypeMorph-Transport, der Tor-Verkehr in Skype-Pakete einbettet. [15] Dabei sinkt zwar die Datenrate, eine Blockade von Tor ohne Seiteneffekte wie z.B. auf Skype sind dann auf Firewallseite nicht mehr auszuschließen. StegoTorus ist ein generisches Framework und bringt ein steganographisches Modul, das dann ``wie HTTP aussieht''.

Zum Einsatz kommen aktuell die einfachen und effizienten Verfahren ``obfs2'' und ``obfs3''. Es gibt ein fertiges Paket mit Tor Browser, Tor und eben einem ``pluggable transport'' der diese Protokolle spricht (Obfsproxy Bundle, [16]), und bislang hat kein Land geschafft, diese Verbindungen zu blockieren (das wird aber sicher kommen). 

Auch China sollten diese Methoden Probleme bereiten. Kann man den Verbindungsaufbau nicht mehr eindeutig Tor zuordnen, müss(t)en sie aktive Tests für praktisch alle Verbindungen überhaupt durchführen.

\section{Nutzerzahlen}
Auf der Metrics-Seite gibt es aktuelle Zahlen zum Netzwerk und zu den Nutzern aus den verschiedenen Ländern. [17] Ende Januar 2013 waren es grob geschätzt 500.000 tägliche sich direkt verbindende Nutzer, die führenden Länder waren dabei USA, Italien, Deutschland, Spanien, Frankreich, Iran, Brasilien und Russland (in absteigender Reihenfolge). Iran wird da bald rausfliegen, da sie inzwischen Tor und Bridges blockieren (Das Obfsproxy-Bundle funktioniert noch wunderbar). Bridge-Nutzer sah Tor im Januar 2013 etwa 25.000 täglich, führende Länder hier Iran, Italien, USA, Syrien, China, Spanien und Frankreich.
Auch die Zahl der Relays im Tor-Netz nimmt langsam aber stetig zu. Im Januar 2013 gab es etwa 3000 Relays und 1000 Bridges. Die Gesamtkapazität betrug rund 23 Gbit. Dabei fallen knapp über 30\% der (wesentlichen) Exitkapazität auf die USA, 27\% auf Deutschland, 11\% auf Schweden, gefolgt von 3\% auf Dänemark. [18]

\section{Wer betreibt das Tor-Netz?}
Die Basis einer erfolgreichen Anonymisierung ist Diversität, je vielfältiger die Nutzer, desto besser. Allerdings gilt dies auch auf Betreiberseite, denn wie bereits erwähnt, kann ein Angreifer die Anonymität aushebeln, wenn er gleichzeitig eingehenden und ausgehenden Verkehr überwachen kann, oder wenn er ``entry node'' und ``exit node'' gar selbst betreibt. Wichtig ist also neben einer breiten geographischen Verteilung eine hohe Anzahl unabhängiger Betreiber, und daß der Datenverkehr über viele Provider läuft.

Traditionell spielt der CCC dabei keine unwesentliche Rolle. Momentan läuft über 20\% des Exittraffics über einen Provider in Deutschland (AS39138 rrbone), administriert wird der Server vom CCC e.V. Die Bandbreite wird gebraucht: Je langsamer das Anonymisierungsnetz, desto mehr Nutzer springen ab und wählen unsicherere Alternativen. Allerdings sind über 20\% in den Händen einer einzelnen Organisation, eines einzelnen Providers und eines Landes aus genannten Gründen ungünstig.

Zweitgrößter Betreiber von Tor Exits ist der vom mir ins Leben gerufene gemeinnützige Verein Zwiebelfreunde e.V. mit seiner Plattform \url{torservers.net} – ebenfalls in Deutschland beheimatet. Dank Eurer Spenden und der Unterstützung durch die Wau-Holland-Stiftung pumpen wir momentan etwa 4 Gbit/s, verteilt auf mehrere Provider in die unterschiedlichen Ländern.

Ich würde mir wünschen, daß sich mehr Gruppierungen aktiv am Betrieb beteiligen würden. Es wäre ein Leichtes, auf dem Mitgliedsformular eines Hackerspaces die Möglichkeit zur regelmäßigen Zusatzspende für Exits vorzusehen. Der Hackerspace Noisebridge macht das mit dem Projekt NoiseTor, speziell dafür gegründete Organisationen nach Zwiebelfreunde-Vorbild entstehen oder existieren momentan in Frankreich (Nos Oignons), Schweden (DFRI), Luxemburg (Frënn vun der Ënn), Schweiz (Swiss Privacy Foundation) und Holland. Schon ein wenig schade, daß wir das in den Erfas bislang nicht hinkriegen. Sollte sich lokal niemand finden, der die Administration übernimmt, oder reichen die Geldbeträge nicht aus, kann man die Spenden immer noch an andere Organisationen weitergeben (aber natürlich wäre das nicht ganz im Sinne der Aktion). Hilfreich sind für potentielle Betreiber die ``Tor Exit Guidelines'', die ich im Laufe der Zeit zusammengetragen habe. [19] Ich helfe gerne auch persönlich weiter, wenn es konkrete Fragen gibt.

Potentielle Sponsoren wurden bislang von Torproject abgewiesen, weil die Anzahl möglicher vertrauenswürdiger Betreiber nicht ausgereicht hat, um Geldmittel sinnvoll zu verteilen. Bald wird es die Möglichkeit geben, finanzielle Unterstützung zu erhalten. An der Diskussion darüber kann man sich gerne beteiligen. [20]

Es gibt sicher unter Euch auch einige mit Kontakten in die ISP-Branche. Übrige Kapazitäten verteilen wir gerne unter den existierenden Organisationen, und der ISP muss sich über eventuelle Haftungsfragen keine Sorgen machen, wenn wir das übernehmen.

Mit dem Tor Cloud-Projekt existiert eine einfache Möglichkeit, ganz ohne Geldeinsatz und ohne technisches Vorwissen Bridges hochzuziehen: Amazon bietet ein Jahr kostenlose Nutzung ihrer Infrastruktur, ein fertiges Betriebssystemabbild wird zur Verfügung gestellt. [21] Für einen dauerhaften Betrieb von Bridges und Relays eigenen sich billige VPS-Provider, wie sie beispielsweise bei LowEndBox vorgestellt werden. [22]

\section{Referenzen}
Hier stehen ganz viele Referenzen
%\begin{thebibliography}
%    \bibitem {1}
%%        [1] Enemies of the State: What Happens When Telling the Truth about Secret US Government Power Becomes a Crime. Vortrag 27.12.2012 Chaos Communication Congress Hamburg. \url{https://events.ccc.de/congress/2012/Fahrplan/events/5338.en.html}
%%        [2] Ballard, L.;  Coull, S.E.;  Monrose, F.;  Masson, G.M.: Spot Me if You Can: Uncovering Spoken Phrases in Encrypted VoIP Conversations, IEEE Symposium on Security and Privacy, May 2008. http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=4531143
%%        [3] Wright, C.; Ballard, L.; Coull, S.; Monrose, F; Masson, G.: Uncovering Spoken Phrases in Encrypted Voice over IP Conversations, ACM Transactions on Information and System Security, Dez 2010. https://dl.acm.org/citation.cfm?doid=1880022.1880029
%%        [4] zum Beispiel vorgestellt auf dem 27C3: Herrmann, D.: Contemporary Profiling of Web Users - On Using Anonymizers and Still Get Fucked. Vortrag 27.12.2010 Chaos Communication Congress Berlin. https://events.ccc.de/congress/2010/Fahrplan/events/4140.en.html
%%        [5] Chaum, D.: Untraceable Electronic Mail, Return addresses, and Digital Pseudonyms. Communications of the ACM, Feb 1981. https://dl.acm.org/citation.cfm?id=358563
%%        [6] Tom Ritter: What is a Remailer? und weitere Artikel. Jan 2013. https://crypto.is/blog/
%%        [7] Goldschlag, D.; Reed, G.; Syverson, P.: Hiding Routing Information. Springer-Verlag LLNCS 1174, Mai 1996. http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=569678
%%        [8] Dingledine, R.: "One cell is enough to break Tor's anonymity". Feb 2009. https://blog.torproject.org/blog/one-cell-enough
%%        [9] Dingledine, R.; Matthewson, N.: Anonymity Loves Company: Usability and the Network Effect. Proceedings of the Fifth Workshop on the Economics of Information Security. 2006. http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.61.510
%%        [10] Dingledine, R.; Serjantov, A.; Syverson, P.: Blending different latency traffic with alpha-mixing. Proceedings of the 6th international conference on Privacy Enhancing Technologies. 2006. https://dl.acm.org/citation.cfm?id=2166535
%%       [11] Matthewson, N.: Top changes in Tor since the 2004 design paper (Part 1). Okt 2012. https://blog.torproject.org/blog/top-changes-tor-2004-design-paper-part-1
%%[12] Tor: Volunteer https://www.torproject.org/getinvolved/volunteer.html.en
%%[13] The Tor Software Ecosystem. Vortrag 28.12.2012 Chaos Communication Congress 29C3. https://events.ccc.de/congress/2012/Fahrplan/events/5306.en.html
%%[14] Wilde, T.: Knock Knock Knockin' on Bridges' Doors. Jan 2012. https://blog.torproject.org/blog/knock-knock-knockin-bridges-doors
%[15] Moghaddam, H.; Li, B.; Derakhshani, M.; Goldberg, I.: SkypeMorph: protocol obfuscation for Tor bridges. Proceedings of the 2012 ACM conference on Computer and communications security. 2012. https://dl.acm.org/citation.cfm?id=2382210
%[16] Torproject: Obfsproxy https://www.torproject.org/projects/obfsproxy.html.en
%[17] Tor Metrics Portal https://metrics.torproject.org/
%[18] Tor Compass https://compass.torproject.org/
%[19] Tor Exit Guidelines https://trac.torproject.org/projects/tor/wiki/doc/TorExitGuidelines
%[20] Call for discussion: turning funding into more exit relays. Jan 2013. https://lists.torproject.org/pipermail/tor-relays/2013-January/001827.html
%[21] Tor Cloud https://cloud.torproject.org/
%[22] Low End Box Cheap VPS Hosting http://www.lowendbox.com/
%\end{thebibliography}

\end{DSarticle}