de/volunteer.wml (02e020667) - tor-webwml.git

volunteer.wml

## translation metadata
# Based-On-Revision: 9834
# Last-Translator: jens@kubieziel.de, peter@palfrader.org

#include "head.wmi" TITLE="Mithelfen"

<h2>Drei Sachen, die jeder tun kann</h2>

<ol>
  <li>Bitte �berlege dir,
    einen <a href="<page docs/tor-doc-server>">Server zu
    betreiben</a>, damit das Netzwerk weiter w�chst.</li>
  <li>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.</li>
  <li>Wir suchen nach Sponsoren und Geldgebern. Wenn du die Ziele von Tor magst
    und es n�tzlich findest, <a href="<page donate>">nimm dir einen Moment Zeit
    und spende, um die weitere Entwicklung zu unterst�tzen</a>. Wenn du Firmen,
    <abbr title="Non-Governmental Organisations">NGO</abbr>s oder andere
    Organisationen, die Sicherheit in ihrer Kommunikation ben�tigen, kennst,
    lasse sie �ber uns wissen.</li>
  </ol>

<a id="Usability"></a>
<h2><a class="anchor" href="#Usability">unterst�tzende Anwendungen</a></h2>

<ol>
  <li>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.).
  <ul>
    <li>Wir m�ssen <a
    href="http://wiki.noreply.org/noreply/TheOnionRouter/TSocksPatches">all
    unsere Patches f�r tsocks</a> einspielen und einen Fork
    betreuen. Wir w�rden diesen auch hosten, wenn du m�chtest.</li>
    <li>Wir sollten das Programm dsocks von Dug Song patchen, so dass es
    das Kommando <code>mapaddress</code> von der Controllerschnittstelle
    nutzt. Somit verschwenden wir nicht einen gesamten Round-trip
    innerhalb von Tor, um die Aufl�sung vor der Verbindung zu
    machen.</li>
    <li>Wir m�ssen unser <kbd>torify</kbd>-Skript so umgestalten, dass
    es erkennt, welches tsocks oder dsocks installiert ist und dieses
    dann richtig aufruft. Das bedeutet wahrscheinlich, dass deren
    Schnittstellen vereinheitlich werden m�ssen und f�hrt wahrscheinlich
    dazu, dass Code zwischen beiden geteilt werden muss oder dass eines
    komplett nicht mehr benutzt wird.</li>
  </ul></li>
  <li>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 <a href="<page gui/index>">Torschnittstelle</a>
    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 <a href="<svnsandbox>contrib/">contrib</a>? Das w�re
  eine gute M�glichkeit f�r den <a href="<page gui/index>">Tor GUI
  Wettbewerb</a>.</li>
  <li>Wir haben eine Vielzahl von Wegen, um
    das <a
    href="http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#ChooseEntryExit">Tornetzwerk
    in einem bestimmten Land zu verlassen</a>. 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�d, die
  <code>.country.blossom</code>-Hostnamen mitschneidet und dann das
  richtige tut.</li>
  <li>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?</li>
  <li>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 <a
    href="http://archives.seul.org/or/talk/Dec-2004/msg00086.html">Beitrag
    </a> und den <a
    href="http://archives.seul.org/or/talk/Jan-2005/msg00007.html">Followup</a>
    f�r mehr Details an.</li>
</ol>

<a id="Documentation"></a>
<h2><a class="anchor" href="#Documentation">Dokumentation</a></h2>

<ol>
  <li>Wir h�ren, dass Tornutzer diversen anonymit�tsbrechenden
  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?</li>
  <li>Gibt es eine komplette Seite mit Plugins, welche die komplette
  Funktionalit�t von Privoxy f�r Firefox 1.5+ ersetzen?</li>
  <li>Bitte hilf Matt Edman mit der Dokumentation und HOWTOs f�r
  seinen <a href="http://vidalia-project.net/">Vidalia</a>.</li>
  <li>Kommentiere und dokumentiere unsere <a
    href="http://wiki.noreply.org/wiki/TheOnionRouter/TorifyHOWTO">Liste
    von Programmen, die durch Tor geroutet werden k�nnen</a>. </li>
  <li>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.</li>
  <li>Wir haben eine riesige
    Liste <a href="<page support>">potentiell n�tzlicher Programme,
    die eine Schnittstelle zu Tor haben</a>. Welche sind in welchen
    Situationen gut? Bitte hilf uns, diese zu testen und dokumentiere
    die Ergebnisse.</li>
  <li>Hilf, die Webseite und die Dokumentation in andere Sprachen zu
  �bersetzen. Schaue dir die <a href="<page translation>">Richtlinien
  zur �bersetzung</a> an, wenn du gern helfen m�chtest. Wir brauchen
  auch Leute, um die existierenden italienischen, franz�sischen und
  schwedischen �bersetzungen weiter zu betreuen. Einen �berblick gibt
  es bei der <a href="<page translation-status>">Statusseite der
  �bersetzungen</a>.</li>
  <li>
  </ol>

<a id="Coding"></a>
<h2><a class="anchor" href="#Coding">Programmierung und Design</a></h2>

<p>M�chtest du deinen Google Summer of Code verbringen, an Tor zu arbeiten?
Gro�artig. <a
href="http://wiki.noreply.org/noreply/TheOnionRouter/SummerOfCode">Lies mehr
�ber Tor und GSoC</a> und schaue, ob eine der untenstehenden Ideen dir
gef�llt.</p>

<ol>
  <li>Torserver funktionieren unter Windows XP nicht sehr gut. Wir
  verwenden auf Windows den standardm��igen <code>select</code>-Systemaufruf.
  Dies bereitet gerade auf mittelgro�en Servern <a
  href="http://wiki.noreply.org/noreply/TheOnionRouter/WindowsBufferProblems">Probleme</a>.
  Wahrscheinlich sollten wir hier besser Overlapped I/O nutzen. Eine L�sung ist,
  <a href="http://www.monkey.org/~provos/libevent/">libevent</a> beizubringen, Overlapped I/O statt <code>select()</code> zu w�hlen
  und Tor dann an die neue libevent-Schnittstelle anzupassen.</li>
  <li>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.</li>
  <li>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
  Existerver, der mich zur IP-Adresse:Port weitergibt?". Die DNSBL-Schnittstelle
  wird wahrscheinlich hunderte von Anfragen pro Minute bekommen. Daher sind hier
  intelligente Algorithmen gefragt. <a
  href="<svnsandbox>doc/contrib/torbl-design.txt">Hier</a> kannst du mehr dazu
  lesen.</li>
  <li>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.</li>
  <li>Hilf Mike Perry bei der <a
  href="http://tor.eff.org/svn/torflow/">TorFlow</a>-Bibliothek. Es ist eine
  Pythonbibliothek, die das <a
  href="http://tor.eff.org/svn/torctl/doc/howto.txt">Tor Controller Protokoll
  </a> nutzt, um mit Tor eine Vielzahl von Verbindungen zu schaffen, diese zu
  messen und Anomalien festzustellen.</li>
  <li>Wir brauchen eine Messung von <a
  href="http://www.pps.jussieu.fr/~jch/software/polipo/">Polipo</a> und <a
  href="http://www.privoxy.org/">Privoxy</a>. 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?</li>
  <li>Es w�re gro�artig, wenn es eine Live-CD mit den aktuellsten Versionen von
  Tor, Polipo oder Privoxy, Firefox, Gaim+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.</li>
  <li>In Beug 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.</li>
  <li>Wir sollten damit anfangen unser <a href="<page
  documentation>#DesignDoc">gegen Blockierungen gesch�tztes Design</a> zu
  implementieren. Dies beinhaltet die Ausarbeitung des Designs, die
  Modifizierung diverser Teile von Tor, die Arbeit an einer <a
  href="http://vidalia-project.net/">GUI</a>, die intuitiv ist und die Planung
  f�r den Einsatz.</li>
  <li>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 <a
  href="#Research">Eintrug unten</a>, um Details zu dieser Aufgabe zu entdecken.
  Wenn es fertig ist, k�nntest du helfen ein Papier dazu zu schreiben.</li>
  <li>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 <tt>.onion</tt>-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.</li>
  <li>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?</li>
  <li>Eine Sicherheitsanalyse mit
    "<a href="http://en.wikipedia.org/wiki/Fuzz_testing">Fuzz</a>"
    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!</li>
  <li>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 <a
    href="http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#TransportIPnotTCP">Liste
    von Gr�nden</a>, 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 <a
  href="<svnsandbox>doc/100-tor-spec-udp.txt">Spezifikation f�r Tor
  und UDP</a> &mdash; bitte lass uns wissen, wenn damit etwas nicht
  stimmt.</li>
  <li>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.</li>
</ol>

<a id="Research"></a>
<h2><a class="anchor" href="#Research">Forschung</a></h2>

<ol>
  <li>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
    observieren sie den Verkehr des Torclients. W�hrend sie
    beobachten, wie der Client die Daten empf�ngt, 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 <a
    href="http://freehaven.net/anonbib/#timing-fc2004">defensives
    Verwerfen</a> anwenden. Wir k�nnten auch k�nstliche Versp�tungen
    einarbeiten. Welchen Einfluss haben diese Massnahmen und wie gro�
    ist der Einfluss auf die Benutzbarkeit?</li>
  <li>Eine weitere Angriffsm�glichkeit (end-to-end traffic
    confirmation attack) basiert darauf, dass der verkehr zwischen
    Alice und Bob beobachtet wird. Durch den <a
    href="http://freehaven.net/anonbib/#danezis:pet2004">Vergleich
    der Signaturen des Netzverkehrs kann man herausfinden, on man
    denselben Stream verfolgt</a>. 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?</li>
  <li>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
    <a href="http://freehaven.net/anonbib/#feamster:wpes2004">autonome
    System sowohl beim Eingangs- wie auch beim Ausgangspfad
    erscheint</a>. 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?</li>
  <li>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.</li>
  <li>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 <a
    href="http://www.psc.edu/networking/projects/hpn-ssh/theory.php">Experiment
    mit dem SSH-Durchsatz</a> gut zu funktionieren. Wir m�ssen das
    messen und verbessern und bei guten Resultaten Tor �berholen.</li>
  <li>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 "Hilf
    China"-Button 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 <a
    href="http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#China"
    >Eintrag in der FAQ</a> und lies dann <a
    href="http://freehaven.net/anonbib/topic.html#Communications_20Censorship"
    >die Zunsurwiderstandssektion der AnonBib</a>.
    </li>
  <li>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.</li>
   <li>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.</li>
  </ol>

<p><a href="<page contact>">Lass uns wissen</a>, wenn du bei einem
  dieser Punkte Fortschritte gemacht hast.</p>

</div>

#include <foot.wmi>

tor-webwml.git

- forgot to add the GSoC-part