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

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 wäre, libevent beizubringen, Overlapped I/O statt select() zu wählen. Tor muss dann an die neue libevent-Schnittstelle angepasst werden. Christian King hat einen guten Anfang gemacht.
Wie können wir die Incognito LiveCD leichter zu warten, verbessern und zu dokumentieren machen?
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 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.
Du magst keinen von den obigen Punkten? Schaue dir die weiteren Pläne für weitere Ideen an.

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.