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

volunteer.wml

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

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

<h2>Vier 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>

<ol>
  <li>Tor server laufen im Moment auf Windows XP nicht
  stabil, weil wir versuchen, hunderte von Sockets
  zu verwenden, und der Windows-Betriebssystemkern anscheinend
  nicht in der Lage ist, damit umzugehen.
  <a href="http://wiki.noreply.org/noreply/TheOnionRouter/WindowsBufferProblems">Bitte
  hilf uns, das Problem zu l�sen!</a> Wahrscheinlich ist es die
  beste L�sung, libevent beizubringen, dass sie �berlappendes I/O
  statt <code>select()</code> auf Windows nutzt und danach Tor auf die
  neue libevent-Schnittstelle zu adaptieren.</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>
  </ol>

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

<ol>
  <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>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>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/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

- corrected typo, thanks to thal