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!