git.schokokeks.org
Repositories
Help
Report an Issue
tor-webwml.git
Code
Commits
Branches
Tags
Suche
Strukturansicht:
932a2bcad
Branches
Tags
bridges
docs-debian
jobs
master
press-clips
tor-webwml.git
de
volunteer.wml
- german translation update
Jens Kubieziel
commited
932a2bcad
at 2007-04-03 11:30:21
volunteer.wml
Blame
History
Raw
## translation metadata # Based-On-Revision: 9921 # Last-Translator: jens@kubieziel.de, peter@palfrader.org #include "head.wmi" TITLE="Mithelfen" <div class="main-column"> <!-- PUT CONTENT AFTER THIS TAG --> <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 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 (<a href="http://tor.eff.org/svn/torflow/TODO">TODO</a>). 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> — 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>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="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><!-- #main --> #include <foot.wmi>