Tor: Mithelfen

Drei Sachen, die jeder tun kann

Bitte überlege dir, einen Server zu betreiben, damit das Netzwerk weiter wächst.
Erzähl es deinen Freunden! Bringe sie dazu, auch Server zu betreiben. Bringe sie dazu, auch versteckte Services zu betreiben. Bringe sie dazu, es wieder ihren Freunden zu erzählen.
Wir suchen nach Sponsoren und Geldgebern. Wenn du die Ziele von Tor magst und es nützlich findest, nimm dir einen Moment Zeit und spende, um die weitere Entwicklung zu unterstützen. Wenn du Firmen, NGOs oder andere Organisationen, die Sicherheit in ihrer Kommunikation benötigen, kennst, lasse sie über uns wissen.

unterstützende Anwendungen

Wir brauchen einen guten Weg, um DNS-Abfragen abzufangen, damit diese nicht an einen lokalen Beobachter dringen, während wir versuchen, anonym zu bleiben. (Dies passiert, weil die Anwendung selbst DNS-Anfragen stellt, anstatt diese über Tor zu leiten.).
- Wir müssen all unsere Patches für tsocks einspielen und einen Fork betreuen. Wir würden diesen auch auf unserem Server mit anbieten, wenn du möchtest.
- Wir sollten das Programm dsocks von Dug Song patchen, so dass es das Kommando mapaddress von der Controllerschnittstelle nutzt. Somit verschwenden wir nicht einen gesamten Round-trip innerhalb von Tor, um die Auflösung vor der Verbindung zu machen.
- Wir müssen unser torify-Skript so umgestalten, dass es erkennt, welches tsocks oder dsocks installiert ist und dieses dann richtig aufruft. Das bedeutet wahrscheinlich, dass deren Schnittstellen vereinheitlicht werden müssen und führt wahrscheinlich dazu, dass Code zwischen beiden geteilt werden muss oder dass eines komplett nicht mehr benutzt wird.
Leute, die einen Server betreiben, teilen uns immer wieder mit, dass sie BandwidthRate in Abhängigkeit von der Uhrzeit setzen wollen. Anstatt das direkt in Tor zu implementieren, sollten wir lieber ein kleines Skript haben, das über die Torschnittstelle spricht und ein setconf macht, um die Änderungen herbeizuführen. Natürlich würde es durch Cron ausgeführt oder es schläft eine bestimmte Zeit und macht dann die Änderungen. Kann das jemand für uns schreiben und wir packen das dann nach contrib? Das wäre eine gute Möglichkeit für den Tor GUI Wettbewerb.
Wir haben eine Vielzahl von Wegen, um das Tornetzwerk in einem bestimmten Land zu verlassen. Aber all diese Wege brauchen den Namen eines speziellen Torservers. Es wäre schön, wenn man nur ein Land angeben muss und automatisch wird ein Server ausgewählt. Der beste Weg ist wahrscheinlich, Blossoms Verzeichnis herunterzuladen und einen lokalen Blossomclient laufen zu lassen, der die Verzeichnisse sicher lädt, die .country.blossom-Hostnamen mitschneidet und dann das richtige tut.
Wenn wir gerade bei Geolocation sind, wäre es schön, wenn jemand eine Karte anfertigt, die die Standorte der Torserver anzeigt. Bonuspunkte gibt es, wenn es sich bei Änderungen am Netzwerk auf den neuesten Stand bringt. Der leichteste Weg, um dies zu erreichen, wäre alle Daten zu Google zu schicken und diese machen dann die Karte für uns. Wie sehr beeinflusst dies die Privatsphäre und haben wir noch andere gute Optionen?
Tor bietet anonyme Verbindungen. Wenn du jedoch verschiedene Pseudonyme haben möchtest (z.B. rufst du desöfteren zwei Webseiten auf und wenn das jemand weiß, kann er auf dich schliessen.), unterstützen wir das nicht sehr gut. Wir sollten einen guten Ansatz und eine Schnittstelle zur Handhabung von pseudonymen Profilen finden. Schaue dir den Beitrag und den Followup für mehr Details an.

Dokumentation

Wir hören, dass Tornutzer diversen Attacken von Javascript, Java, ActiveX, Flash etc. zu Opfer fallen. Gibt es da draußen gute Plugins (wie NoScript für den Firefox), die es den Nutzern erleichtern, diese Risiken zu meistern? Was ist exakt das Risiko?
Gibt es eine komplette Seite mit Plugins, welche die komplette Funktionalität von Privoxy für Firefox 1.5+ ersetzen?
Bitte hilf Matt Edman mit der Dokumentation und HOWTOs für seinen Vidalia.
Kommentiere und dokumentiere unsere Liste von Programmen, die durch Tor geroutet werden können.
Wir brauchen bessere Dokumentation für Programme, die dynamisch in Verbindungen eingreifen und diese durch Tor schicken. Für Linux und Windows scheinen tsocks (Linux), dsocks (BSD), und freecap gute Kandidaten.
Wir haben eine riesige Liste potentiell nützlicher Programme, die eine Schnittstelle zu Tor haben. Welche sind in welchen Situationen gut? Bitte hilf uns, diese zu testen und dokumentiere die Ergebnisse.
Hilf, die Webseite und die Dokumentation in andere Sprachen zu übersetzen. Schaue dir die Richtlinien zur Übersetzung an, wenn du gern helfen möchtest. Wir brauchen auch Leute, um die Seiten in Arabisch oder Farsi zu übersetzen. Einen Überblick gibt es bei der Statusseite der Übersetzungen.

Programmierung und Design

Torserver funktionieren unter Windows XP nicht sehr gut. Wir verwenden auf Windows den standardmäßigen select-Systemaufruf. Dies bereitet gerade auf mittelgroßen Servern Probleme. Wahrscheinlich sollten wir hier besser Overlapped I/O nutzen. Eine Lösung ist, libevent beizubringen, Overlapped I/O statt select() zu wählen und Tor dann an die neue libevent-Schnittstelle anzupassen.
Weil die Torserver jede Zelle speichern und weitergeben müssen, brauchen die Torserver mit hoher Bandbreite Dutzende Megabyte an Speicher. Wir benötigen bessere Heuristiken, wenn die Buffer zu verkleinern/vergrößern sind. Wahrscheinlich sollte dies nach dem Bufferdesign des Linuxkernels modelliert werden. Dort gibt es kleinere Buffer, die sich gegenseitig verbinden.
Wir brauchen eine offizielle zentrale Seite, die die Frage "Ist das die Adresse eines Torservers" beantwortet. Es sollte diverse Schnittstelle, wie ein Webformular und DNSBL-ähnliche Abfrage, bieten. Es kann aktuelle Informationen bieten, indem es einen lokalen Spiegel der Verzeichnisinformationen anlegt. Du bekommst Bonuspunkte, wenn es aktiv die Exitserver testet, wie die IP-Adresse ist. Der schwierige Punkt ist, das die Eigenschaft, Exitserver zu sein, nicht einfach mit ja oder nein zu beantworten ist. Daher ist die Frage eher: "Ist diese IP-Adresse ein Exiterver, der mich zur IP-Adresse:Port weitergibt?". Die DNSBL-Schnittstelle wird wahrscheinlich Hunderte von Anfragen pro Minute bekommen. Daher sind hier intelligente Algorithmen gefragt. Hier kannst du mehr dazu lesen.
Manchmal stürzen Torserver ab oder die Computer, auf denen das Programm läuft, verschwinden vom Netz. Manche Betreiber von Tor haben Interesse geäußert, an einem Service teilzunehmen, der in regelmäßigen Abständen prüft, ob der jeweilige Torserver noch läuft und Mails versendet, falls das nicht der Fall ist. Eventuell möchte jemand ein paar CGI-Skripte und Webseiten schreiben and einen wget-hack oder etwas komplexeres wie Nagios für das Monitoring machen? Die erste Version sollte nur den Directoryport prüfen. Beispielsweise könnte das Programm durch die Netzwerkstatusseite nach der richtigen IP-Adresse sowie Port schauen und dann nach der "/tor/server/authority"-Seite.
Wir brauchen ein verteiltes Testgerüst. Bisher haben wir Unittests. Es wäre großartig, ein Skript zu haben, welches ein Tornetzwerk startet und dort für einige Zeit testet, ob die Erneuerungen funktionieren.
Hilf Mike Perry bei der TorFlow-Bibliothek (TODO). Es ist eine Pythonbibliothek, die das Tor Controller Protokoll nutzt, um mit Tor eine Vielzahl von Verbindungen zu schaffen, diese zu messen und Anomalien festzustellen.
Wir brauchen eine Messung von Polipo und Privoxy. Ist Polipo wirklich schneller, wenn man die Verlangsamung durch Tor mit einrechnet? Behandelt Polipo die Webseiten korrekter als Privoxy? Gibt es Probleme mit der Stabilität bei den häufig genutzten Plattformen?
Es wäre großartig, wenn es eine Live-CD mit den aktuellsten Versionen von Tor, Polipo oder Privoxy, Firefox, Pidgin+OTR usw. gäbe. Es gibt hier zwei Herausforderungen: Zum einen muss das System dokumentiert werden und zum anderen müssen wir herausfinden, wie das leicht zu pflegen ist. Es sollte nicht so schnell obsolet werden, wie AnonymOS. Bonuspunkte gibt es, wenn die CD auf eine kleine CD (50MB) passt.
In Bezug auf das CD-Image sollten wir auch an einer sicheren und gut dokumentierten USB-Variante für Tor und unterstützete Anwendungen arbeiten. Der schwierige Teil ist zu entscheiden, welche Konfigurationen sicher sind, diese Entscheidungen zu dokumentieren und etwas zu schaffen, das leicht zu pflegen ist.
Wir sollten damit anfangen unser gegen Blockierungen geschütztes Design zu implementieren. Dies beinhaltet die Ausarbeitung des Designs, die Modifizierung diverser Teile von Tor, die Arbeit an einer GUI, die intuitiv ist und die Planung für den Einsatz.
Wir brauchen ein flexibles Gerüst, um Ende-zu-Ende Attacken des Netzverkehrs zu simulieren. Viele Forscher haben Simulatoren geschaffen, die ihre Intuition, ob ein Angriff oder Verteidigung funktioniert, unterstützt. Können wir einen Simulator bauen, der offen und gut dokumentiert ist? Dies wird eine Menge neuer Forschung anregen. Schaue auch auf den Eintrag unten, um Details zu dieser Aufgabe zu entdecken. Wenn es fertig ist, könntest du helfen, eine Veröffentlichung dazu zu schreiben.
Momentan werden die Deskriptoren der versteckten Services nur auf einigen wenigen Verzeichnisservern gespeichert. Dies ist schlecht für die Privatsphäre und die Robustheit. Um mehr Robustheit zu erlangen, sollten wir die privaten Daten aus den Deskriptoren entfernen, um diese auf verschiedenen Plätzen spiegeln zu können. Idealerweise hätten wir gern ein Speicher-/Backupsystem, das verschieden zu den Verzeichnisservern ist. Das erste Problem ist, das wir Format für die versteckten Services schaffen müssen, welches a) ASCII statt binär ist, b) die Liste der Introductionpoints verschlüsselt, solange man nicht die .onion-Adresse kennt und c) den Verzeichnissen erlaubt, den Zeitstempel und die Signatur eines Deskriptors zu verifizieren, so dass diese nicht mit falschen überrumpelt werden. Zweitens wird es jedes verteilte Speichersystem tun, solange es authentifizierte Updates erlaubt.
Torversionen ab 0.1.1.x unterstützen Cryptohardwarebeschleuniger via OpenSSL. Bisher hat das niemand getestet. Möchte jemand gern eine Karte haben und schauen, ob das funktioniert?
Eine Sicherheitsanalyse mit "Fuzz" machen. Herausfinden, ob es da draußen gute Bibliotheken dafür gibt. Gewinne Ruhm und Ehre, wenn wir nur wegen dir ein neues Release herausbringen!
Tor nutzt TCP für den Transport und TLS für die Verschlüsselung der Verbindungen. Dies ist einfach. Es bedeutet aber auch, dass alle Zellen Verspätungen erfahren, wenn nur ein Paket verworfen wird. Daher können wir nur bedingt TCP-Streams unterstützen. Es gibt eine Liste von Gründen, warum wir nicht zu Transport per UDP gewechselt sind. Es wäre schön, wenn diese Liste kürzer werden würde. Wir haben auch eine Spezifikation für Tor und UDP — bitte lass uns wissen, wenn damit etwas nicht stimmt.
Wir sind nicht weit davon entfernt, Unterstützung für IPv6 bei Exitknoten zu haben. Falls du dich stark um IPv6 kümmerst, ist das wahrscheinlich der Platz, um zu starten.

Forschung

Die Fingerprintattacken gegen Webseiten machen eine Liste von einigen wenigen populären Webseiten, laden die Inhalte herunter und machen einen Satz von Signaturen für jede Seite. Danach beobachten sie den Verkehr des Torclients. Währenddessen gelangen sie schnell zu einer Vermutung, welche Seite gerade besucht wird. Wie effektiv ist dieser Angriff bezüglich der aktuellen Codebasis von Tor? Beginne danach Verteidigungsmöglichkeiten auszuloten. Wir könnten beispielsweise die Zellgröße von 512 Bytes auf 1024 Bytes anheben und Techniken wie defensives Verwerfen anwenden. Wir könnten auch künstliche Verspätungen einarbeiten. Welchen Einfluss haben diese Massnahmen und wie groß ist der Einfluss auf die Benutzbarkeit?
Eine weitere Angriffsmöglichkeit (end-to-end traffic confirmation attack) basiert darauf, dass der Verkehr zwischen Alice und Bob beobachtet wird. Durch den Vergleich der Signaturen des Netzverkehrs kann man herausfinden, on man denselben Stream verfolgt. Bis jetzt akzeptiert Tor dies als Fakt und nimmt an, dass dies in allen Fällen trivial ist. Ist das wahr? Wieviel Verkehr von welcher Sorte braucht man, um sicher zu sicher, dass es funktioniert? Gibt es Szenarien, die die Attacke ausbremsen? Funktioniert Padding besser als anderes?
Die Attacke auf die Routingzonen ist der Netzpfad zwischen Alice und dem Eingangsknoten (bzw. zwischen dem Exitknoten und Bob). In der Literatur wird dies als einfache Verbindung auf einem Graph dargestellt. In der Praxis durchquert der Pfad viele autonome Systeme. Es ist nicht ungewöhnlich, dass dasselbe autonome System sowohl beim Eingangs- wie auch beim Ausgangspfad erscheint. Um nun herauszufinden, ob ein spezielles Alice-, Eingangs-, Ausgangs-, Bobviereck gefährlich ist, müssten wir die gesamte Routingzone des Internet herunterladen und Operationen darauf ausführen. Gibt es praktische Abschätzungen, die die Arbeit erleichtern können?
Andere Fragen in der Forschung, die die geografische Verteilung betreffen, betrachten einen Kompromiss zwischen der Wahl einer effizienten Route und einer zufälligen Route. Wirf einen Blick auf das Positionspapier von Stephen Rollyson. Es diskutiert, wie man langsame Leitungen auschalten kann, ohne die Anonymität zu stark einzuschränken. Die Begründungen machen einen guten Eindruck, brauchen aber noch mehr Arbeit.
Tor funktioniert nicht sehr gut, wenn Server eine asymmetrische Bandbreite (Kabel oder DSL) haben. Tor hat separate TCP-Verbindungen zwischen jedem Hop. Wenn nun die einkommenden Pakete gut ankommen und die ausgehenden alle verworfen werden, übertragen die die TCP-Pushback-Mechanismen diese Informationen nicht gut hin zu den eingehenden Verbindungen. Eventuell sollte Tor feststellen, wenn eine Menge an ausgehenden Verbindungen verworfen werden und dann die eigehenden Verbindungen selbst herunterregeln? Ich könnte mir ein Schema vorstellen, wo wir ein konservatives Ratelimit suchen und das langsam vergrößern, bis Pakete verworfen werden. Wir brauchen jemanden, der sich gut mit Netzwerken auskennt, um dies zu simulieren und eine Lösung zu finden. Wir müssen die Erosion in der Performance verstehen und das als Motivation für Transport per UDP verstehen.
Ein verwandtes Thema ist die Kontrolle bei Netzüberlastung. Ist unser Design ausreichend, um hohe Netzlast auszuhalten? Vielleicht sollten wir mit Fenstern von variabler Größe experimentieren? Das schien im Experiment mit dem SSH-Durchsatz gut zu funktionieren. Wir müssen das messen und verbessern und bei guten Resultaten Tor überholen.
Damit Dissidenden in fernen Ländern Tor nutzen können, ohne von der Firewall des Landes geblockt zu werden, brauchen wir einen Weg, um zehntausende von Relays zu bekommen anstatt nur einigen hundert. Wir können uns eine GUI vorstellen, die einen "Tor for Freedom"-Button (Tor für die Freiheit) hat. Dieser öffnet einen Port und verteilt ein paar Kilobyte Traffic ins Tornetzwerk. Wie verteilen wir eine Liste dieser Freiwilligen in einer automatischen Art und Weise? Dies muss so passieren, dass die Firewalls auf Landesebene diese nicht erkennen. Wahrscheinlich muss das auf einem Niveau persönlichen Vertrauens funktionieren. Siehe unseren Designdokument hierzu sowie den Eintrag in der FAQ und lies dann die Zensurwiderstandssektion der AnonBib.
Tor-Verbindungen werden schrittweise aufgebaut, ein Knoten nach dem anderen. Also haben wir theoretisch die Möglichkeit, manche Ströme schon nach dem zweiten Knoten die Tor-Wolke verlassen zu lassen, andere nach dem dritten Knoten, und so weiter. Dies erscheint nett, weil es die Menge der austretenden Ströme, welcher ein bestimmter Server sieht, begrenzt. Wenn wir diesen Strom jedoch sicher haben wollen, dann, laut unserer aktuellen Logik, sollte der kürzeste Pfad mindestens 3 Knoten lang sein. Das heisst, die anderen Ströme wären noch länger. Wir müssen diese Performance/Sicherheitsabwägung untersuchen.
Es ist nicht schwer, DoS Angriffe auf Tor-Server oder Tor-Verzeischnisserver erfolgreich durchzuführen. Sind Client-Puzzles die richtige Anwort? Welche anderen praktischen Herangehensweisen gibt es? Bonuspunkte, wenn diese mit dem aktuellen Tor-Protokoll abwärtskompatibel sind.

Lass uns wissen, wenn du bei einem dieser Punkte Fortschritte gemacht hast.