Tor: Zum Projekt beitragen

Laufender Bedarf:

Wir benötigen Nutzer, wie dich, die Tor gern ausprobieren möchten und den Entwicklern über Fehler oder fehlende Eigenschaften berichten.
Bitte überlege dir auch, ob du nicht einen Server betreiben möchtest, um das Netzwerk weiter wachsen zu lassen.
Weiterhin benötigen besonders Leute, die Programmiererfahrung mit Windows haben, um einen Exitknoten auf Windows zu betreiben und uns beim Suchen von Fehlern zu helfen.
Betreibe einen versteckten Service und lege dort interessante Inhalte ab!
Erzähl deinen Freunden von dem Projekt! Bringe sie dazu selbst Server zu betreiben. Bringe sie dazu selbst versteckte Services zu betreiben. Bringe sie dazu, es ihren Freunden weiterzuerzählen.
Was muss noch dokumentiert werden? Was ist falsch dokumentiert?
Schaue auf die Webseite der Electronic Frontier Foundation. Mehr Spenden an die EFF bedeutet mehr Freiheit in der Welt, eingeschlossen die Entwicklung von Tor

Wir haben auch viele Aufgaben: kurzfristige Aufgaben, die sehr hilfreich wären, wenn sie jemand in Angriff nimmt. Damit könnten wir uns mehr auf Tor konzentrieren.

Schriftliche Aufgaben:

Möchte jemand helfen, diese Webseite zu betreuen, mit der Dokumentation weiterhelfen oder unsere TODO-Listen verwalten und Fehlerberichte bearbeiten?
Eventuell haben wir zuviel Dokumentation. Sie ist zuweit verteilt und dadurch doppelt vorhanden. Kannst du uns helfen, das zu konsolidieren?
Hilf uns die Webseite und die Dokumentation in andere Sprachen zu übersetzen. Schau dir die Übersetzungsrichtlinien an, wenn du helfen möchtest. (Beispiele: Französisch und Persisch)
Bitte schreibe Einträge im FAQ Wiki und wenn du eine Antwort auf eine unbeantwortete Frage weisst, beantworte sie einfach.

Aufgaben bei Paketen:

Wir suchen immer bessere Installationsprogramme für Windows. Seziell wäre es großartig, wenn jemand unser NSIS-basiertes Installationsprogramm erweitern könnte, um auch FreeCap und Privoxy einzubinden.
Unser OS X Paket bietet keine Deinstallationsoption an. Gibt es Programme, die weniger saugen und Möglichkeiten zur Deinstallation haben? Dies ist eine immer größer werdende Belastung.

Organisatorische und Anwendungstestaufgaben:

Wir haben hier eine Liste von potentiell nützlichen Programmen, die du eventuell mit Tor verwenden willst. Weiterhin haben wir ein Torify HOWTO. Kann diese jemand ausprobieren, die Erklärungen vereinfachen, sie dort erweitern, wo es notwendig ist, sie besser dokumentieren und sie alles in allem nützlich machen?

Programmier- und Projektaufgaben:

Wir benötigen jemanden, der eine grafische Oberfläche oder ein Kontrollprogramm schreiben kann und die Konfiguration übernimmt. Schaue die unsere Kontrollspezifikation zu den Details und das rudimentäre Kontrollscript in Python an. Nein, wir wissen nicht, wie die Schnittstelle derzeit am besten aussehen sollte. Du kannst jede Lizenz nutzen, die du möchtest, wobei wir die BSD oder vielleicht die GPL empfehlen würden. Wir können dir auch nur dann helfen, wenn deine Lizenz den DFSG entspricht.
Hin und wieder fragen uns Leute, die einen Server betreiben, dass sie zu einer bestimmten Tageszeit eine Limitierung der Bandbreite möchten. Anstatt dies direkt innerhalb von Tor zu implementieren, sollten wir lieber ein kleines Skript haben, dass über das Tor Controller Interface kommuniziert und eine entsprechende Änderung übernimmt. Vielleicht sollte das dann via Cron laufen oder es ist nur zu bestimmten Zeiten aktiv und macht dann die Änderungen. Kann das jemand für uns schreiben und wir packen es dann nach tor/contrib/?
Möchte jemand einen Patch beisteuern, so dass wir das als NT-Service betreiben können? Oder das wir in den Systemtray kommen?
Eine gute (portable, schnelle, saubere, BSD-freie) asynchrone DNS-Bibliothek wäre wirklich gut. Dann müssen wir unsere DNS-Threads nicht zu gethostbyname forken.
Kann jemand einen Blick auf Martins Squid und Tor Seite werfen und diese so erneuern, dass es Tors RedirectExit Konfigurationsoption mit benennt?
Schaue dir die TODO-Liste und HACKING-Dateien in der Tordistribution für weitere Ideen an.

Sicherheitsaufgaben: Wir brauchen Leute, um die Implementation anzugreifen und diese von Fehlern zu befreien. Weiterhin muss auch das Design einer Kontrolle unterzogen werden.

Wir benötigen jemanden für fuzz. Gibt es gute Bibliotheken für unser Anliegen? Was sind die ersten Schritte? Erarbeite dir Ruhm und Ehre, wenn wir wegen dir eine neue Version herausbringen!
Fingerprintingattacken (Back et al, Hintz). Abwehr schliesst große Paketgrößen, abwehrendes Verwerfen, etc. mit ein. Wie gut funktioniert dieser Ansatz?
Die Ende-zu-Ende Verkehrsbestätigungsattacke. Wir müssen weitentfernte Dummies mehr studieren. Wieviel Verkehr mit welcher Art von Verteilung wird für den Angreifer benötigt, um sicherzustellen, dass er gewonnen hat?
Es ist nicht schwer, Torserver oder Verzeichnisserver durch Denial of Service in die Knie zu zwingen. Sind Rätsel hier die richtige Antwort? Welche andere Ansätze existieren hier?
Welche schützenswerte Informationen dringen durch Privoxy? Sind andere HTML-Filter besser?

Designeraufgaben:

Die Prozessorlast auf Servern ist hoch, weil Clients immer neue Verbindungskanäle aufmachen wollen, was Public-Key-Kryptografie erfordert. Eventuelle Verteidigungsstrategien sind: Verwenden von Hilfsknoten (bestimmte Eingangsknoten). Die Anzahl der Createzellen, die per Sekunde bearbeitet werden, begrenzen. Clients fehlgeschlagene Verbindungen ein paar mal neu versuchen lassen. Die Nutzung von Kryptografie in Hardware, wenn das verfügbar ist.
Wir befürchten, dass unsere Server nicht wirklich gut funktionieren, wenn die Server eine asymmetrische Bandbreite besitzen. Denn Tor hat einzelne TCP-Verbindungen zwischen jedem Punkt. Wenn nun die hereinkommenden Bytes problemlos eintreffen und die ausgehenden verworfen werden, überträgt der TCP-Pushback-Mechanismus diese Information nicht zu den einkommenden Datenströmen. Vielleicht sollte Tor selbst herausfinden, wenn es eine Menge an ausgehenden Paketen verwirft und die hereinkommenden Pakete begrenzen, um diesen Mangel zu beheben? Wir benötigen jemanden, mit Ahnung von Netzwerken, um dies zu simulieren und eine Designlösung zu erarbeiten.
Derzeit werden die Beschreibungen für versteckte Services bei den Verzeichnisservern gespeichert. Aber ein verlässliches, verteiltes Speichersystem würde helfen (z.B. ein DHT, das authentifizierte Updates erlaubt). Könnte jemand die besten Optionen verifizieren und entscheiden, ob diese gut genug sind?
Wie schwer ist es, BIND oder einen DNS-Proxy zu patchen, um die Anfragen über unsere tor-resolve-Erweiterung umzuleiten? Was wäre, wenn die UDP-Anfragen in TCP-Anfragen geändert werden und dann durch Tor geschickt werden?
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.

Schaue mal im #tor IRC-Kanal auf irc.oftc.net vorbei oder schreibe eine E-Mail an tor-volunteer@freehaven.net, wenn du helfen möchtest!