de/volunteer.wml (dae28b905) - tor-webwml.git

volunteer.wml

## translation metadata
# Based-On-Revision: 13843
# 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="https://wiki.torproject.org/noreply/TheOnionRouter/TSocksPatches">all
    unsere Patches f�r tsocks</a> einspielen und einen Fork
    betreuen. Wir w�rden diesen auch auf unserem Server mit anbieten, 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 vereinheitlicht 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 <var>BandwidthRate</var> 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 <a href="<page gui/index>">Torschnittstelle</a>
    spricht und ein <code>setconf</code> 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="https://wiki.torproject.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�dt, 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>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="https://wiki.torproject.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 Seiten in Arabisch oder Farsi zu �bersetzen. Einen
  �berblick gibt
  es bei der <a href="<page translation-status>">Statusseite der
  �bersetzungen</a>.</li>
  </ol>

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

<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="https://wiki.torproject.org/noreply/TheOnionRouter/WindowsBufferProblems">Probleme</a>.
  Wahrscheinlich sollten wir hier besser Overlapped I/O nutzen. Eine L�sung
  w�re, <a href="http://www.monkey.org/~provos/libevent/">libevent</a>
  beizubringen, Overlapped I/O statt <code>select()</code> zu w�hlen. Tor muss
  dann an die neue libevent-Schnittstelle angepasst werden. Christian King hat
  <a href="https://tor-svn.freehaven.net/svn/libevent-urz/trunk/">einen guten
  Anfang</a> gemacht.</li>
  <li>Wie k�nnen wir die <a
  href="http://anonymityanywhere.com/incognito/">Incognito LiveCD</a> leichter
  zu warten, verbessern und zu dokumentieren machen?</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
r href="https://www.torproject.org/svn/torflow/">TorFlow</a>-Bibliothek (<a
  href="https://www.torproject.org/svn/torflow/TODO">TODO</a>). Es ist eine
  Pythonbibliothek, die das <a
  href="https://www.torproject.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 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">Eintrag unten</a>, um Details zu dieser Aufgabe zu entdecken.
  Wenn es fertig ist, k�nntest du helfen, eine Ver�ffentlichung  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="https://wiki.torproject.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>
  <li>Du magst keinen von den obigen Punkten? Schaue dir die <a
  href="<svnsandbox>doc/design-paper/roadmap-future.pdf">weiteren Pl�ne</a> f�r
  weitere Ideen an.</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
    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 <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>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 <a
    href="http://swiki.cc.gatech.edu:8080/ugResearch/uploads/7/ImprovingTor.pdf">Positionspapier</a>
    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.</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 "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 <a href="<page
  documentation>#DesignDoc">Designdokument hierzu</a> sowie den <a
    href="https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#BlockingResistance"
    >Eintrag in der FAQ</a> und lies dann <a
    href="http://freehaven.net/anonbib/topic.html#Communications_20Censorship"
    >die Zensurwiderstandssektion 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

- translated volunteer page (removed many resolved issues)