TOR umprogrammieren – High Speed TOR

Könnt ihr euch noch an den Artikel erinnern, bei dem wir TOR durch die Konfigurationsdatei torrc schneller gemacht haben? Den Artikel könnt ihr jetzt in die Tonne kloppen :) Ich habe seit über 1 Monat einen eigenen TOR-Clienten laufen, mit dem ich (selbst mit Standard-Config) um einiges schneller unterwegs bin, als mit allen anderen Mitteln.

Wir haben ja schon alles versucht um TOR schneller zu machen. Wir haben nicht nur die Config geändert (sogar zweimal), sondern ich habe ja auch schon Tests mit Prozessprioritäten gemacht, bei dem ich sogar im Kontakt mit den TOR-Entwicklern stand. Aber das alles hat mich irgendwie nicht glücklich gemacht. Nicht so sehr wie der Geschwindigkeitsboost, den ich jetzt durch kleine Änderungen am Quelltext erreicht hab :)

Jaaa, NOM NOM NOM, jetzt gibt es wieder was leckeres :D Aber bevor wir uns der Praxis widmen, erst ein bisschen Theorie. Wir müssen ja wissen wie TOR funktioniert, bevor wir Änderungen dran vornehmen. Außerdem hat die ganze Sache einen winzigen Haken, den man unbedingt verstehen sollte. Ist aber nicht so kompliziert, versprochen :)

Also, wie funktioniert TOR eigentlich? Ich hab mal mit meinen Bruder gequatscht, und dabei ist aufgefallen, dass er zwar wusste, was TOR ist und was es ungefähr macht, aber er hatte ein Kernkonzept nicht verstanden, das erheblich zur Sicherheit von TOR beiträgt. Also, jedes mal, wenn man eine Verbindung durch das TOR-Netzwerk aufbaut, werden 3 Router im Netzwerk ausgewählt, durch denen die Verbindung durchgeht:

So, der Webserver weiß jetzt nicht, wer die Internetseite aufruft. Er sieht nur den Router 3. Mit dem kann er aber wenig anfangen, da selbst der Router 3 nicht weiß, wer eigentlich ursprünglich die Seite aufruft. Das dürfte soweit geläufig sein. Wichtig ist jetzt noch, dass die Verbindung verschlüsselt ist. Und zwar _mehrfach_ asymmetrisch zwischen den einzelnen Routern (wer asymmetrische Verschlüsselung nicht kennt sollte sich mein Paper reinziehen um zu verstehen _wie_ sehr sicher es ist).

Das heißt, wenn wir eine Verbindung aufbauen, sucht unsere TOR-Software sich 3 Router aus, nimmt dazu die öffentlichen Schlüssel der Router (Paper: Magie der asymmetrischen Verschlüsselung) und verschlüsselt es zunächst mit dem Schlüssel von Router 3, das dann mit dem Schlüssel von Router 2 und zuletzt das dann auch noch mit dem öffentlichen Schlüssel von Router 1. Es ist also 3-fach asymmetrisch verschlüsselt :)

Dieses 3-fach verschlüsselte Paket wird zunächst an Router 1 geschickt, der die erste „Verschlüsselungsschicht“ mit seinem privaten Schlüssel entschlüsseln kann und es dann „nur noch“ 2-fach verschlüsselt weiter an Router 2 schickt. Der macht das gleiche mit seinem Schlüssel und schickt das 1-fach verschlüsselte Paket an Router 1, der es dann zuletzt entschlüsselt und unverschlüsselt wie ein einfacher Client an den Webserver schickt.

Das ist eigentlich total genial :) Schauen wir uns jetzt mal an was der Router 1 von dem ganzen Verbindungsaufbau sieht. Bei ihm kommt ein Paket an, den er mit dem eigenen Schlüssel entschlüsselt. Er weiß nicht, ob er jetzt der mittlere Router oder der erste Router ist, das kann er nicht erkennen. Er entpackt das Paket einfach nur mit seinem Schlüssel, sieht da eine Nachricht an wem er es weitersenden soll und das macht er dann auch. Das entschlüsselte Paket ist immernoch verschlüsselt und sieht jetzt komplett anders aus. Er hat keine Ahnung was da drin steht und kann nicht feststellen, ob es jetzt von uns erstellt oder nur weitergeleitet wurde. Er schickt einfach nur ein Paket weiter.

Gut, das ist die Grundidee die wir kennen müssen um weiter zu machen. Man nennt jeden einzelnen Router TOR-intern einen „Hop“ (englisch für Sprung), wir haben also 3 Hops in unserer Verbindung. Diese Hops kosten Zeit. Hehe :) Also, wenn Router 2 mit nem 56K-Modem online ist und die ganze Zeit Pakete entschlüsseln und weiterleiten muss, dann ist dieser Hop eine Bremse in unserer Verbindung. Und glaubt mir, nicht wenige der Router im TOR-Netzwerk verhalten sich fehlerhaft oder haben nicht gerade die Performance, die man sich in der westlichen Zivilisation wünscht.

Okay :) Für unser Unterfangen wäre es vielleicht sinnvoll die Anzahl der Hops runterzuschrauben. Zunächst einmal, bevor wir das machen, müssen wir uns anschauen was dabei passiert und ob die Sicherheit unserer Anonymität nicht vielleicht kaputt geht. Also, Zwei Hops, malen wir dat mal auf:

Schaut doch ganz gut aus :) Aber büßen wir dabei nicht an Sicherheit ein? Naja, eigentlich… nö! :D Die Entwickler haben 3 Hops gewählt, damit Leute, die einzelne Router kontrollieren, nicht die ganze Verbindung aufhebeln können ;) 3 Hops sind Standard! Also wird keiner erwarten, dass jemand nur 2 Hops verwendet :D

Nehmen wir bei unserem 2-Hops Beispiel mal an, der Router 1 will die Verbindung aufhebeln. Er weiß alles über was er empfangen, entschlüsselt und weitergesendet hat. Dann wird er aber nicht sehr weit kommen, weil sein Vorgänger-Router (der eigentlich keiner ist, weil wir das sind) nicht ihm gehört! :) Bei heißen Diskussionen über die TOR-Sicherheit wurde immer wieder festgestellt, dass man mindestens den 1. und 3. Router kontrollieren muss um überhaupt eine Chance zu haben, die Verbindung auszuhebeln. Hehe, aber bei der 2-Hop Technik geht das ja nicht =D

Natürlich solltet ihr wissen dass ihr am Arsch seid, wenn jemand weiß, dass man mit nur 2 Hops fährt und derjenige Router 1 kontrolliert. Aber das tut ja keiner :)

Gut, das war die technische Sichtweise der Sicherheit. Jetzt werden wir mal realistisch. Schon vor 5 Jahren hat der Chaos Computer Club bei einem Meeting zum Betreiben von TOR-Routern beschrieben wie gegen Delikte vorgegangen werden, die vom TOR-Netzwerk ausgehen. In den meisten Fällen wird einfach festgestellt, dass das TOR-Netzwerk verwendet wurde und dann wird nicht weiter nachgeforscht, da das Netzwerk ja eh als unknackbar angesehen wird. Jetzt mal ernsthaft, wenn bei mir irgendwelche Kiddies SQL-Injection auszuprobieren und ich als Hostnamen tor-exit-router35-readme.formlessnetworking.net sehe, was soll man machen?! :)

Okay, gehen wir mal weiter und nehmen wir mal an ein Geheimdienst will was gegen uns ausrichten. Die haben mit Sicherheit einige TOR-Server am laufen die komplett geloggt werden. Aber denkt ihr wirklich, dass sie deren ganze Energie und Informationen über deren Projekte, Server und Macht preisgeben, nur um jemanden vor Gericht zu stellen der sich in ein E-Mail Account von irgendeinem Politiker eingeloggt hat? Nee, das ist noch nie vorgekommen und das wird es auch nicht ;)

Fazit: Solange im TOR-Netzwerk 3 Hops Standard sind, sind wir mit 2 Hops sicher unterwegs.

Okay, machen wir uns an die Arbeit. Als erstes sollten wir es schaffen TOR korrekt zu kompilieren und auszuführen. Danach können wir ja beliebige Änderungen vornehmen und sie vergleichen. Es gibt auf der Projektseite von TOR eine Textdatei, die beschreibt, wie man es unter Windows kompiliert. Einfach mal „compile TOR“ bei Google eintippen und dann findet man’s schon (neben meinem Video, das mittlerweile bei Google ganz oben angezeigt wird :P).

Das Problem, das besteht, ist, dass MinGW gerne mal ein paar Sachen ändert und der Compiler dann dann rumzickt. Ich selber musste 2 Änderung am OpenSSL-Quellcode vornehmen. In der Datei openssl-0.9.8l\include\openssl\e_os2.h Zeile 267 das static löschen (rot markiert):

[...]
#ifdef OPENSSL_EXPORT_VAR_AS_FUNCTION
# define OPENSSL_IMPLEMENT_GLOBAL(type,name)			     \
	extern type _hide_##name;				     \
	type *_shadow_##name(void) { return &_hide_##name; }	     \
	static type _hide_##name
# define OPENSSL_DECLARE_GLOBAL(type,name) type *_shadow_##name(void)
# define OPENSSL_GLOBAL_REF(name) (*(_shadow_##name()))
#else
[...]

und in der Datei openssl-0.9.8l\crypto\engine\eng_all.c die Referenzen in Zeile 78, 81, 84, 87, 90, 93, 96 und 99 entfernen (rot markiert):

[...]
#ifndef OPENSSL_NO_STATIC_ENGINE
#ifndef OPENSSL_NO_HW
#ifndef OPENSSL_NO_HW_4758_CCA
 ENGINE_load_4758cca();
#endif
#ifndef OPENSSL_NO_HW_AEP
 ENGINE_load_aep();
#endif
#ifndef OPENSSL_NO_HW_ATALLA
 ENGINE_load_atalla();
#endif
#ifndef OPENSSL_NO_HW_CSWIFT
 ENGINE_load_cswift();
#endif
#ifndef OPENSSL_NO_HW_NCIPHER
 ENGINE_load_chil();
#endif
#ifndef OPENSSL_NO_HW_NURON
 ENGINE_load_nuron();
#endif
#ifndef OPENSSL_NO_HW_SUREWARE
 ENGINE_load_sureware();
#endif
#ifndef OPENSSL_NO_HW_UBSEC
 ENGINE_load_ubsec();
#endif
#endif
#if !defined(OPENSSL_NO_GMP) && !defined(OPENSSL_NO_HW_GMP)
	ENGINE_load_gmp();
[...]

Mit diesen Ausnahmen konnte ich TOR exakt nach der Beschreibung der Textdatei kompilieren. Hier ist mal ein Video, bei dem man mir bei der Arbeit zusehen kann. Das Video musste ich fix schneiden, deswegen haltet mal lieber die Pause-Taste bereit :P

[...]
/********************************* circuitbuild.c **********************/

/** How many hops does a general-purpose circuit have by default? */
#define DEFAULT_ROUTE_LEN 3

/* Circuit Build Timeout "public" structures. */

/** Precision multiplier for the Bw weights */
#define BW_WEIGHT_SCALE   10000
#define BW_MIN_WEIGHT_SCALE 1
#define BW_MAX_WEIGHT_SCALE INT32_MAX
[...]