Sechs Sachen, die jeder tun kann

1. Wir brauchen Nutzer wie dich, um Tor zu probieren und lass die Entwickler über jeden Bug wissen, den du findest.
2. Bitte überlege dir, einen Server zu betreiben, damit das Netzwerk weiter wächst.
3. Wir benötigen Leute mit Programmiererfahrung unter Windows. Sie sollen einen Exitknoten unter Windows betreiben und uns beim Debuggen helfen.
4. Betreibe einen versteckten Service und fülle ihn mit interessanten Inhalten.
5. 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.
6. Überlege dir, der Electronic Frontier Foundation beizutreten. Mehr Zuwendungen an die EFF bedeuten mehr Freiheit für die Welt, eingeschlossen die Entwicklung von Tor.

Aufgaben beim Programmieren

• Derzeit hat Tor eine eingebaute Unterstützung für AES. Denn als wir mit dem Projekt starteten hatte OpenSSL keine/kaputte Unterstützung. Nunmehr hat sich die Situation verbessert und wir sollten die Dinge so ändern, dass wir nur das eingebaute AES nutzen, wenn OpenSSL das nicht unterstützt.
• 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.
• Wie funktionieren die ulimits auf Win32? Wir haben speziell bei älteren Versionen Probleme, dass die Leute keine Dateideskriptoren, Verbindung zum Buffer, etc. mehr haben. (Wir sollten WSAENOBUFS nutzen, wie es gebraucht wird, einen Blick auf den Registryeinträge MaxConnections, MaxUserPort und TcpTimedWaitDelay werfen. Weiterhin sollten wir einen Weg bieten, diese Einstellung nach Wunsch zu treffen. Schaue dir auch Bug 98 an.)
• Identitätsschlüssel auf der Platte verschlüsseln und einen Schutz per Passphrase für diese implementieren. Derzeit werden diese nur als Klartext gespeichert.
• Reverse DNS implementieren (schon spezifiziert)
• configure.in sollte mit Kompilieren für andere Architekturen umgehen können
• NULL_REP_IS_ZERO_BYTES auf 1 setzen
• with-ssl-dir sollte die Suche nach SSL deaktivieren
• Die Bewahrung des Rufes nach Reboots von Clients oder Verzeichnisservern beibehalten.
• Unterstützung für EGD oder nicht-OS-basierte Entropiequellen hinzufügen
• Implementierung eines Passwortschutzes für den Identitätsschlüssel
• Implementierung eines Weges, dass autoconf die Sachen nach ~./tor installiert
• Serverbeschreibung ändern, um das Loglevel zu beschreiben
• Unterstützung für Clients einfügen, um Server, die zuviel Logs schreiben, zu umgehen
• Entdeckung separater Knoten, um nützliche Erweiterungen zu aktivieren
  • SetServerStatus hinzufügen, um den Status der verifizierten/laufenden Knoten zu adjustieren
  • NoDownload Option hinzufügen, um unnötige Downloads des Verzeichnisses zu vermeiden
• Exitknoten durch Metadaten (z.B. Land) wählen
• Den Cpuworker nutzen
  • hidserv-Deskriptoren signieren (und verifizieren)
  • intro/rend-Anfragen signieren (und verifizieren)
  • Routerdeskriptoren signieren (und verifizieren)
  • Verzeichnisse signieren (und verifizieren)
  • TLS-Handshake vollziehen
• Pool der Buffergröße: Die maximale Größe für alle Buffer alloziieren, nicht eine maximale Größe für jeden Buffer. Somit müssen wir nicht so schnell aufgeben, wenn das Netz überlastet ist.
• Alternative Versionen von crypto.c und tortls.c hinzufügen, um libnss und libgcrypt+gnutls zu nutzen.
• Das Installationsprogramm auf Windows so erweitern, dass es Freecap und/oder Privoxy mit einschliesst
• Mit der Mac OSX Installation und Deinstallation umgehen
• Eine GUI oder anderes Controllerprogramm entwickeln, das die Konfiguration usw. übernimmt. Schaue dir unsere Kontrollspezifikation (engl.) für weitere Details an. Weiterhin kannst du einen Blick auf das rudimentäre Python-Kontrollskript werfen.
  • Eine Schnittstelle für das Kontrollprogramm entwerfen. Du kannst jede Lizenz verwenden, die du möchtest. Wir empfehlen die BSD-Lizenz oder die GPL und wir können auch nur aushelfen, wenn die Lizenz den DFSG entspricht.
  • Leute, die einen Server betreiben, teilen uns immer wieder mit, dass sie BandwidthRate in Teilen des Tages setzen wollen und eine andere BandwidthRate an anderen Teilen des Tages. Anstatt das direkt in TOR zu implementieren, sollten wir lieber ein kleines Skript haben, das über die TOR-Schnittstelle 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 tor/contrib?
• Eine gute (portable, schnelle, saubere, BSD-freie) asynchrone DNS-Bibliothek entwickeln, so dass wir nicht DNS-Workerthreads forken müssen um gethostbyname() zu machen

Herausforderungen in der Dokumentation

• Serverinstruktionen für Windows und Mac OSX schreiben
• Den Wikieintrag Portforwarding verbessern und klären
• Dokumentieren, wie man Exitknotencaching macht: Anknüpfen an Squid oder einen anderen Webproxy, der Caching macht
• Mithilfe bei der Betreuung der Webseite: Code, Inhalte, CSS und generelles Layout
• Hilfe bei der Dokumentation
• Hilfe beim Konsolidieren der Dokumentation. Wir haben wahrscheinlich zuviel Dokumentation. Es ist zu weit verteilt und dupliziert sich selbst.
• Hilfe bei der Übersetzung der Webseite und der Dokumentation in andere Sprachen. Schaue dir die Übersetzungsrichtlinien an, wenn du gern helfen möchtest. (Beispiele: Französisch, Persisch und Vietnamesisch)
• Wenn du eine Frage hast, die zum FAQ Wiki hinzugefügt werden sollte, schreibe diese mit rein und beantworte sie, wenn möglich.
• Wenn du die Antwort zu einer Frage im Wiki weisst, beantworte sie bitte.
• Schaue dir Martins Squid- und Torseite an und bringe sie bezüglich der RedirectExit-Option auf den neuesten Stand.

Aufgaben beim Testen

• Testen, warum manche der Torserver DNS-Resolver haben, die unbekannte Adressen nach 127.0.0.1 auflösen
  • Die Server identifizieren, bei denen dies auftritt
  • Den Fehler finden und es in BIND, djbdns oder dementsprechenden Daemon beheben
• Herausfinden, wie man Webproxygateways aufsetzt, um normale Anwender Zugang zu den versteckten Services zu bieten (Das wurde schon ein paarmal gemacht, aber niemand hat uns den Code geschickt.)
• Etwas über Freecap vs. Privoxy in Win32-Clients herausfinden.
• Eine Liste von Programmen, die mit Tor funktionieren, schaffen und evaluieren
• 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!
• Fingerprintattacken gegen Webseiten (Back et al., Hintz). Verteidigung dagegen schliesst eine Anhebung der Zellgröße, Verwerfen (dropping) zur Verteidgung usw. mit ein. Wie gut funktioniert dies?
• Die Ende-zu-Ende-Attacke. Wir müssen Dummies über große Weiten zusammen mit Trafficshaping mehr studieren. Wieviel Traffic von welcher Verteilungssorte wird gebraucht, bevor der Angreifer sicher sein kann, dass er gewonnen hat?
• Herausfinden, welche sensiblen Informationen durch Privoxy hindurchdringen
• Herausfinden, ob es bessere HTML-Säuberer als Privoxy gibt

Forschungsaufgaben

• Arrangieren eines Management der Mitgliedschaft für die Unabhängigkeit
  • Verteidigung gegen verschiedene gefälschte Identitäten ohne den Flaschenhals Mensch
  • Wie kann man eine zufällige Auswahl an Knoten finden?
  • Wie handhabt man Empfehlungen der Knotenliste?
  • Betrachte inkrementelle Wechsel: Ein Peer-to-Peertor mit nur 50 Nutzern hat andere Anonymitätswünsche als einer mit 10.000 Nutzern und sollte anders behandelt werden.
• Vergünstigungen an Relays und Exitknoten
• Dissidenden erlauben, durch Tor zu relayen
• Mit Systemen mit mittlerer Latenz experimentieren. Wie beeinflussen diese die Benutzbarkeit und Sicherheit?
• Verstehen, wie stark Fingerprintattacken sind und mit Wegen, diese zu umgehen, experimentieren.
• Praktische Abschätzungen, um Eingangs- und Exitknoten in unterschiedlichen Routingzonen zu wählen
• Eine optimale Abwanderungsquote für Helferknoten finden. Wie sicher ist das?
• Freenet-Gnunet/Timing-delay-Argumente angreifen
• Ist das Austeigen aus der Mitte eines Circuit immer eine schlechte Idee?
• IPv6-Unterstützung (für Exitadressen)
  • Fall für die Spezifikation: Wenn eine IPv4- und IPv6-Adresse zurückgegeben wird, welche soll genutzt werden?
  • Zum Policycode hinzufügen
  • tor_gethostbyname nach tor_getaddrinfo verschieben
  • Alles das, was uint32_t als IP-Adresse nutzt, so ändern, dass es einen generalisierten Adressstruct nutzt
  • Relayzelltypen ändern, dass sie die neuen Adressen akzeptieren
  • Ein Flag zu serverdesc hinzufügen, die bestimmt, ob IPv6 genutzt wird
• tsocks patchen
• Freecap (oder anderes) so ändern, dass es das macht, was wir wollen
• Proxies für andere Protokolle als HTTP
• Wir müssen bessere Standardkonfigurationen für Privoxy verteilen.
• Privoxy wird nicht mehr betreut und saugt. Wir brauchen etwas besseres.
• Ein DNS-Proxy würde dazu führen, dass SOCKS4/5-Applikationen gut funktionieren
• SOCKS-Unterstützug zu mehr Anwendungen hinzufügen
• Informationen über versteckte Services auf der Platte speichern: Verzeichnisserver vergessen die Deskriptoren, wenn sie neu starten
• Es ist nicht schwer, einen Torserver oder Verzeichnisserver einem Denial-of-Service zu unterziehen. Sind Puzzles die richtige Antwort? Welche anderen praktikablen Möglichkeiten gibt es hier?
• Die Load der Server-CPU ist hoch, da der Client ständig nach neuen Verbindungen fragt. Das nutzt Public-Key-Kryptografie. Eventuelle Verteidigungen schliessen die Benutzung von Helferknoten, Limitierung der Anzahl der neu zu schaffenden Zellen pro Sekunde, nochmaliger Versuch einer gescheiterten Verbindung, Implementierung von SSL-Sitzungen und die Nutzung von Hardwarekrypto mit ein.
• Wir befürchten, dass die Server bei assymetrischen Bandbreite nicht gut funktionieren. 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!