Solltest du Besitzer eines Apple iPhones sein, dann kannst du dich freuen. Denn es ist jemandem gelungen, Tor auf das iPhone zu portieren. In einer Nachricht an die Tor-Mailingliste beschreibt er, dass fast keine Änderungen nötig waren und bietet dort den Patch an. Wie üblich, reicht es, das Tor.app einfach ins app-Verzeichnis einzuwerfen und man bekommt nach seinen Worten eine funktionierende Anwendung aus Privoxy und Tor. Na dann, viel Spass beim Surfen. 
Der Beitrag von Netzpolitik, 24C3-Preview, erinnert mich daran, dass ich langsam meine Reiseplanungen beenden sollte. Der Fahrplan ist schon eine Weile online und mein Vortrag To be or I2P findet am 2007-12-29 um 17:15 Uhr (nach dem heutigen Stand) statt.
Der Vortrag dreht sich um I2P, eine Anonymisierungslösung. Ich werde darin einige Grundlagen zur Funktionsweise von I2P erzählen und auch einige Programme vorstellen. Das Ziel ist es, die Hacker aufmerksam zu machen und vielleicht neue Nutzer/Entwickler zu gewinnen. Für den Vortrag habe ich auch eine anonyme eepsite eingerichtet. Dort findet ihr momentan den Abtract zu meinem Vortrag. Später kommen dort die Vortragsfolien und vielleicht weitere Informationen hin. Ihr könnt mich auch über I2P-Mail erreichen. Aufgrund der Funktionsweise von I2P werden die obigen Links nicht sofort gehen. Hierfür müsst ihr erst I2P installieren und einrichten.
Tim Pritlove und Constanze Kurz haben einen Ausblick auf den Congress in der Sendung 58 des Chaosradio Express gegeben. Dort stellen die beiden verschiedene Vorträge vor und ihr bekommt einen Überlick, welche Vorträge sich für euch lohnen und welche nicht.
Alles in allem ist der Congress jedes Jahr eine lohnende Angelegenheit. Ich freue mich, nach meiner letztjährigen Pause, dieses Jahr wieder in Berlin zu sein. Vielleicht wird der Besucherrekord ein weiteres Mal geknackt.
Wenn man mit Datenschützern über die aktuelle Lage der Überwachung diskutiert, hört man hin und wieder das Gleichnis vom Frosch im heißen Wasser. Demnach springt ein Frosch, wenn man ihn in heißes Wasser setzt, sofort raus. Sollte das Wasser kalt sein und langsam erhitzt werden, so bleibt der Frosch sitzen und wird gekocht. Bei der Überwachung tritt nun eine ähnliche Situation ein. Die Maßnahmen werden Schritt für Schritt (Stichwort: Salamitaktik) eingeführt und jeder hat genug Zeit, sich an die einzelnen Maßnahmen zu gewöhnen. Daher fehlen die großen Proteste wie vor 20 Jahren.
Bei Stefan las ich von einem Video, welches das obige Gleichnis umsetzt. Ich finde es in der Tat auch sehr sehenswert:
Steven J. Murdoch schreibt heute im Blog Light Blue Touchpaper (Securitygruppe der Informatiker an der Universität Cambridge), dass seine Promotionsarbeit veröffentlicht wurde. Sie trägt den Titel Covert channel vulnerabilities in anonymity systems (Schwachstellen über verdeckte Kanäle in Anonymitätsdiensten). Der Bericht umfasst etwa 120 Seiten plus Literatur und enthält einige bereits bekannte Angriffe gegen Tor (Low-Cost traffic analysis of Tor, Hot or Not: Revealing Hidden Services by their Clock Skew etc.). Aus meiner Sicht ist das Dokument für alle interessant, die sich für die Theorie hinter Anonymisierungsdiensten interessieren.
Steven hat mir auch bei einigen Fragen zu seinen Forschungen und mir freundlicherweise auch eine Grafik aus seiner Promotionsarbeit zur Verfügung gestellt. Hierfür möchte ich ihm auch nochmal an dieser Stelle danken.
siehe auch Angriffspotentiale gegen Anon-Plattformen über böse Kommunikationskanäle im Ravenhorst
Beim Artikel zu Picidae hatte ich in den Kommentaren versprochen, etwas zur Umgehung der Zensur mittels Tor zu schreiben. Heute ist es nun soweit.
Tor ist ja per se schon gut geeignet, um unbeobachtet zu kommunizieren. Jedoch könnten Angreifer auf die Idee kommen, einfach die Kommunikation über Tor zu blockieren und schon funktioniert dieser Kanal nicht mehr. Die Schwachstellen, die hierfür gern benutzt werden, sind die öffentlich verfügbaren Verzeichnisserver. Denn jeder Client muss sich von dort aktuelle Informationen über die verfügbaren Tor-Server herunterladen. Wenn die Verbindung zu allen der fünf Verzeichnisserver geblockt wird, dann hat der Client keine Informationen und kann auch keine Verbindung aufbauen. Der Angreifer könnte auch die Verzeichnisinformationen runterladen und die IP-Adressen der einzelnen Tor-Server extrahieren (awk ‘/^router/ { print $3 }’ /var/lib/tor/cached-routers). Jetzt kann die Verbindung zu den Rechnern gezielt über den Paketfilter gesperrt werden. Ein dritter Weg liegt in der Prüfung des HTTP-Verkehrs. Tor lädt die Verzeichnisinformationen über HTTP herunter. Somit kann man gezielt Verbindungsanfragen sperren. In der Praxis filtern viele auf den String “tor”. Diese Maßnahme lässt sich am einfachsten umgehen. In den neueren Tor-Versionen gibt es eine Option TunnelDirConns. Sobald diese auf 1 gesetzt wird, lädt der Tor-Client die Verzeichnisinformationen über HTTPS herunter und der Filter läuft ins Leere.
Die beiden zuerst beschriebenen Fälle sind etwas komplizierter. Seit diesem Jahr arbeiten die Entwickler daran, Mechanismen zur Lösung des Problems in Tor einzuarbeiten. Die Theorie basiert auf folgendem Design. Die ursprüngliche Idee stammt vom JAP und wurde für Tor weiterentwickelt. Der Grundgedanke besagt, dass man sich nicht direkt mit dem Netzwerk verbindet, sondern Hilfen, so genannte Brückenserver, benutzt. Diese nehmen eine Anfrage entgegen und leiten sie dann an das Tor-Netzwerk weiter. Für einen effektiven Schutz gegen Zensur ist es wichtig, dass die Brückenserver nicht als solche erkannt werden. Das Tor-Projekt geht verschiedene Wege. Zum einen muss ein Brückenserver nicht in einem zentralen Verzeichnis registriert sein. Das heißt, ihr könnt zu Hause selbst einen aufsetzen, von dem nur ihr wisst und gebt die Adresse des Servers an Freunde weiter. Ein dritter sieht nur eine SSL-Verbindung zu dem Server und kann nicht sagen, welche Inhalte transportiert werden. Wenn du dich entscheidest, den Brückenserver bei einem Verzeichnisserver anzumelden, wird von seiten des Projektes viel getan, um dessen Identität zu verschleiern. Details findet ihr in dem oben erwähnten Designdokument.
Wenn ihr einen Brückenserver ausprobieren wollt, reicht es, die Option UseBridges in der torrc auf 1 zu setzen. Solltet ihr einen speziellen Server nutzen wollen, dann kommt noch die Zeile Bridge 12.34.56.78:9009 hinzu. Sie legt fest, dass der Brückenserver auf der IP-Adresse 12.34.56.78 auf Port 9009 erreichbar ist. Wenn ihr den Fingerprint des Servers könnt, schreibt diesen hinter die IP-Adresse. Nun kommuniziert Tor immer über den Brückenserver. Damit sollte es einem Angreifer nicht mehr so ohne Weiteres möglich sein, eure Kommunikation mit Tor zu stören.
Momentan sind Brückenserver nur im experimentellen Code von Tor enthalten. Soweit ich das mitbekommen habe, wird diese in den nächsten Wochen freigegeben und der Code fließt in die stabile Version mit ein.