Der Tor-Speed

Immer wieder höre ich mir – im Zeitalter von "fetten" Breitbandanbindungen – verständliches Gemecker über die niedrigere Geschwindigkeit beim anonymisierten Websurfen mit Tor an. Mir persönlich ist das Nebensache, mal abgesehen von den auftretenden Fehlschlägen bei der Namensauflösung von einzelnen Adressen, weil z. B. der Exit Node bzw. dessen DNS überlastet ist.

Aber ein Blick auf die Interna des "Tor Netzwerks" sollten jedem Meckerer klar machen, dass es bei einer Browser Verbindung über Tor nun mal nicht mit einer vorherigen Abfrage bei einem DNS-Server und dem nachfolgenden "direkten" und unverschlüsselten Abrufen von Inhalten getan ist, wobei ja auch dort eine "direkte" Verbindung zwischen Clientrechner und Website eher die Ausnahme ist. Im Normalfall werden die Anfragen und Abrufe über mehrere Router, Gateways usw. transportiert, wobei die beteiligten Rechner im Gegensatz zum Tor Netz meistens aus leistungsstarken Maschinen mit guten Anbindungen bestehen und eben nicht aus Privatrechnern mit den gängigen Internetanbindungen, auf denen oft zeitgleich anderen Verbindungen abgewickelt werden.

Das Tor Netz ist höchst unterschiedlich: Man findet dort Tor Router, die auf leistungsstarken Rechnern mit Standleitungen großer Bandbreite laufen, aber auch den kleinen Kauf-PC, der gerade mal die geforderten 20 kilobytes Minimum für Tor abzwacken kann. Manche Tor Nodes können für die Namensauflösung der angefragten Adressen auf gute DNS-Anbindungen zurückgreifen, manche eben nicht. Tor Router laufen auf Linuxmaschinen, die genug gleichzeitige TCP-Verbindungen öffnen können oder auf Windowsrechnern, die von Microsoft künstlich beschränkt wurden und erst einmal selbst gepatcht werden müssen. Einige Tor Nodeadmins aktualisieren ihre Tor Version regelmäßig, um an möglichen Verbesserungen bezüglich Verbindungen, Namensauflösung und Geschwindigkeit teilzuhaben, andere Admins lassen ihre Nodes mit veraltenen Tor Versionen vor sich hin dümpeln.

Bei allen Vorgängen spielt bei Tor die Verschlüsselung eine große Rolle – angefangen bei der ersten Verbindung vom lokalen Tor Proxy zum ersten Kontaktnode im Tor Netz, über die Aushandelung von Schlüsseln bis zur Ver- und Entschlüsselung der transportierten Daten zwischen allen drei Tor Routern, die pro Anfrage beteiligt sind. Das bedeutet "Arbeit" – sowohl auf der eigenen Maschine, als auch auf allen Tor Routern – also Zeitaufwand.
Kleine Übung: Man nehme eine dicke Zwiebel, löse die Schalen so von außen nach innen, dass jede Schale unbeschädigt bleibt und füge anschließend die Zwiebel wieder mit allen Schalen zusammen.

Und last but not least seid Ihr nicht alleine da draußen. Ein Tor Node hat vielleicht gerade einmal zehn Verbindungen, während zeitgleich ein anderer Tor Node Hunderte von Verbindungen abzuwicklen hat. Es gibt Tor "Nutzer", die sich mit dem Abruf von Webseiten oder E-Mails zufrieden geben und es gibt Nutzer, die jedes Videofile und jedes Programm megabyteschwer über die "Leitungen" des Tor Netzes heruntersaugen.

Trotzdem ein paar Tipps am Ende, die hier zu einer teilweisen Verbesserung (die wird in einem Netz wie Tor immer relativ bleiben) der Geschwindigkeit beigetragen haben:

• Statt der stabilen Version wird die aktuelle Entwicklerversion von Tor heruntergeladen und eingesetzt.
• Für Firefox wird die Erweiterung Fasterfox installiert, mit der man mit ein paar Klicks auf "Optimiert" oder "Turbo" die Einstellungen ändern bzw. verbessern kann, die sich auf die Performance und Netzwerkfunktionen von Firefox auswirken.
• Es wird die aktuelle 3.0.5-Beta von Privoxy heruntergeladen und eingesetzt, die u. a. die Konfigurationsoption forwarded-connect-retries n für die Privoxy Konfigurationsdatei config[.txt] bietet und angibt, wie oft (mit n = 1-3 würde ich testen) Privoxy einen erneuten Verbindungsversuch unternimmt, wenn eine weitergeleitete Verbindung fehlschlägt, sich also auch auf die Weiterleitungen zum Tor Proxy bezieht:
  forwarded-connect-retries is mainly interesting for socks4a connections, where Privoxy can't detect why the connections failed. The connection might have failed because of a DNS timeout in which case a retry makes sense, but it might also have failed because the server doesn't exist or isn't reachable. In this case the retry will just delay the appearance of Privoxy's error message.

Ansonsten: Benutzt Tor wie es ist oder lasst es bleiben. Wählt selbst Eure Prioritäten: Dauernder Zeitgewinn und Speed oder Schutz vor Profiling, Data-Mining und Vorratsspeicherung. Und wer das nächste Mal meckert, bekommt den Tor-Speed Link vor den Latz geknallt.