Skip to content

Mit Tor die Zensur umgehen

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.

Disclaimer an E-Mails

Das Thema Disclaimer an E-Mails ist wahrscheinlich vielen von euch hinlänglich bekannt. Heute bekam ich eine E-Mail mit einem doch sehr interessanten Disclaimer:

From: foobar
Date: Wed, 5 Dec 2007 12:13:45 +0100 (CET)
To: jens
Subject: Information des FRZ

;; This buffer is for notes you don’t want to save, and for Lisp evaluation.
;; If you want to create a file, visit that file with C-x C-f,
;; then enter the text in that file’s own buffer.

Hallo,

wir wurden heute von ...

Ich glaube, da muss jemand noch lernen, mit dem Emacs E-Mails zu schreiben. ;-)

cronjob