tor-webwml.git

1) ## translation metadata
2) # Based-On-Revision: 8183
3) # Last-Translator: bogdandr_at_op . pl
4) 
5) #include "head.wmi" TITLE="Wolontariusze" CHARSET="UTF-8"
6) 
7) <div class="main-column">
8) 
9) <!-- PUT CONTENT AFTER THIS TAG -->
10) <h2>Cztery rzeczy, które każdy może zrobić już teraz:</h2>
11) <ol>
12) <li>Prosimy rozważyć <a href="<page docs/tor-doc-server>">uruchomienie
13)  serwera</a>, by wspomóc rozwój sieci Tor'a.</li>
14) <li>Spójrz na <a href="<page gui/index>">Konkurs na GUI dla Tor'a</a> i
15)  daj swój wkład w uczynienie interfejsu i używalności lepszymi. Darmowa koszulka za
16)  każdy wkład!</li>
17) <li>Rozpowiadaj o systemie Tor swoim znajomym. Spraw, by uruchomili serwer.
18)  Spraw, by uruchomili usługi ukryte. Spraw, by mówili o systemie Tor swoim znajomym.</li>
19) <li>Szukamy funduszy i sponsorów. Jeśli podobają ci się cele Tor'a,
20)   <a href="<page donate>">poświęć chwilę, by złożyć dotację, by wspomóc przyszły rozwój Tor'a</a>.
21)   Jeśli znasz jakieś firmy, organizacje pozarządowe, agencje lub inne organizacje, które
22)   są zainteresowane bezpieczną komunikacją, daj im znać o nas.</li>
23) </ol>
24) 
25) <a id="Bugs"></a>
26) <h2><a class="anchor" href="#Bugs">Błędy krytyczne</a></h2>
27) <ol>
28) <li>Serwery Tor'a nie są aktualnie stabilne na Windows XP, gdyż próbujemy uzywać
29)  setek gniazd, a zdaje się, że jądro Windowsa nie jest w stanie tyle obsłużyć. <a
30)  href="http://wiki.noreply.org/noreply/TheOnionRouter/WindowsBufferProblems">Prosimy,
31)  pomóż nam rozwiązać ten problem!</a> Prawdopodobnie najlepszym rozwiązaniem jest
32)  nauczyć bibliotekę libevent, jak używać nakładającego się I/O zamiast select() w
33)  Windows, a potem przystosować Tor'a do nowego interfejsu libevent.</li>
34) </ol>
35) 
36) <a id="Usability"></a>
37) <h2><a class="anchor" href="#Usability">Aplikacje Wspomagające</a></h2>
38) <ol>
39)  <li>Potrzebujemy dobrych sposobów na przechwytywanie żądań DNS, żeby nie
40)  "przeciekały" do lokalnych obserwatorów, podcza gdy my chcemy zachować anonimowość.
41)  (Dzieje się tak, gdyż aplikacja wysyła żądanie DNS przed przejściem przez serwer
42)  Proxy SOCKS.)</li>

43) <li><ul>

44) <li>Musimy <a
45)  href="http://wiki.noreply.org/noreply/TheOnionRouter/TSocksPatches">zastosować
46)  nasze wszystkie łaty tsocks do kodu</a> i utrzymywać nową gałąź. Możemy ją hostować, jeśli chcesz.</li>
47) <li>Powinniśmy załatać program "dsocks" Dug'a Song'a, by używał komend
48)  <i>mapaddress</i> Tor'a z interfejsu kontroli, żeby nie marnować przejścia
49)  całej trasy w Torze, robiąc rozwiązywanie adresów przed połączeniem.</li>
50) <li>Musimy sprawić, by nasz skrypt <i>torify</i> wykrywał, który z programów
51)  tsocks lub dsocks jest zainstalowany, i odpowiednio je uruchamiał. To
52)  prawdopodobnie oznacza zunifikowanie ich interfejsów i w grę może wchodzić
53)  dzielenie kodu między nimi lub całkowita rezygnacja z jednego z nich.</li>

54) </ul></li>

55) <li>Ludzie, którzy uruchomili serwer Tor'a mówią nam, że chcę dać jedną
56)  przepustowość łącza dla Tor'a (BandwidthRate) w czasie pewnej części dnia,
57)  a inną w innych częściach dnia. Zamiast programować to w Torze, powinniśmy mieć
58)  mały skrypt, który łączy się przez <a href="<page gui/index>">Tor Controller Interface</a>,
59)  i wykonuje SETCONF by zmienić przepustowość. Być może ten skrypt byłby uruchamiany
60)  z cron'a, a może byłby uśpiony aż do właściwego momentu i wtedy wykonywał swoją
61)  pracę (to by raczej było bardziej przenośne). Czy ktoś mógłby napisać taki
62)  skrypt za nas, a my byśmy go umieścili w katalogu <a href="<svnsandbox>contrib/">contrib/</a>?
63)  To byłby dobry wkład w <a href="<page gui/index>">Konkurs na GUI dla Tor'a</a>.</li>
64) <li>Tor może <a
65)  href="http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#ChooseEntryExit">wychodzić
66)  z sieci Tor'a z podanego węzła</a>, ale powinniśmy móc podać tylko kraj i mieć coś,
67)  co automatycznie za nas wybierze węzeł. Najlepszym kandydatem jest pobranie także
68)  katalogu Blossom i uruchomienie lokalnego klienta Blossom, który pobrałby swój katalog w
69)  sposób bezpieczny (poprzez Tor i sprawdzając jego podpis), przechwycałby nazwy
70)  hostów <tt>.country.blossom</tt>  i robił to, co trzeba.</li>
71) <li>A mówiąc o danych geolokacyjnych, ktoś powinien narysować mapę Ziemi z
72)  zaznaczonym każdym serwerem Tor'a. Dodatkowe punkty, jeśli mapa bęzdie się
73)  aktualizować w miarę jak sieć rośnie i się zmienia. Niestety, łatwy sposób na
74)  dokonanie tego to wysłanie wszystkich danych do Google, w celu narysowania
75)  przez nich taj mapy. Jak bardzo to uderza w prywatność i czy mamy jakieś inne
76)  dobre wyjścia?</li>
77) </ol>
78) 
79) <a id="Documentation"></a>
80) <h2><a class="anchor" href="#Documentation">Dokumentacja</a></h2>
81) <ol>
82) <li>Słyszeliśmy, że użytkownicy Tor'a mogą paść ofiarami ataków
83)  łamiących ich anonimowość ze strony JavaScript'u, Javy, ActiveX'a, Flash'a itp.,
84)  jeśli ich nie wyłączą. Czy są jakieś wtyczki/rozszerzenia (jak NoScript dla
85)  Firefox'a), które ułatwiają panowanie nad tym ryzykiem? Jakie to dokładnie ryzyko?
86)  </li>
87) <li>Czy istnieje kompletny zestaw wtyczek/rozszerzeń, który zastąpi całą
88)  funkcjonalność Privoxy w Firefoksie 1.5+? Podobno Tor jest o wiele szybszy, gdy
89)  nie używa się Privoxy.</li>
90) <li>Proszę pomóc Matt'owi Edman'owi z dokumentacją i dokumentami jak-to-zrobić do
91)  jego projektu <a href="http://vidalia-project.net/">Tor Controller</a>.</li>
92) <li>Przejrzyj i udokumentuj
93)  <a href="http://wiki.noreply.org/wiki/TheOnionRouter/TorifyHOWTO">naszą
94)  listę programów</a>, które można skonfigurować do współpracy z Tor'em.</li>
95) <li>Potrzebujemy lepszej dokumentacji do dynamicznego przechwytywania połączeń
96)  i wysyłania ich przez Tor'a. tsocks (Linux), dsocks (BSD),
97)  i freecap (Windows) zdają się być dobrymi kandydatami.</li>
98) <li>Mamy ogromną listę <a href="http://wiki.noreply.org/noreply/TheOnionRouter/SupportPrograms">potencjalnie

99)  użytecznych programów, które współpracują z Tor'em</a>. Które z nich są

100)  przydatne w jakich sytuacjach? Proszę pomóż nam je testować i zapisuj
101)  swoje wyniki.</li>
102) <li>Pomóż przetłumaczyć stronę WWW i dokumentację na inne języki. Spójrz na
103)  <a href="<page translation>">wskazówki do
104)  tłumaczenia</a>, jeśli chcesz pomóc. Potrzebujemy też ludzi do opieki nad
105)  istniejącymi tłumaczeniami: włoskim, francuskim i szwedzkim - zobacz
106)  <a href="<page translation-status>">stan tłumaczeń</a>.</li>
107) </ol>
108) 
109) <a id="Coding"></a>
110) <h2><a class="anchor" href="#Coding">Programowanie i Projektowanie</a></h2>
111) <ol>
112) <li>W tej chwili deskryptory usług ukrytych są przechowywane na zaledwie
113)  kilku serwerach katalogowych. To źle dla prywatności i wydajności. By to
114)  polepszyć, będziemy musieli uczynić deskryptory usług ukrytych jeszcze
115)  mniej prywatnymi, gdyż będziemy musieli je skopiować w wiele miejsc.
116)  Idealnie byłoby całkowicie oddzielić system przechowywania/pobierania od
117)  serwerów katalogowych Tor'a. Pierwszą rzeczą jest to, że musimy zaprojektować
118)  nowy format deskryptora usługi ukrytej tak, by a) dla wygody był w postaci ASCII,
119)  a nie binarnej b) przechowywać listę punktów przedstawiania w postaci zaszyfrowanej,
120)  chyba że zna się adres <tt>.onion</tt>, by katalog nie mógł ich pobrać, c)
121)  pozwolić katalogom na weryfikację znacznika czasu i podpisu na deskryptorze
122)  usługi ukrytej, żeby nie mogły zostać oszukane poprzez podanie im fałszywych.
123)  Po drugie, każdy wiarygodny system przechowywania sprawdzi się, dopóki
124)  umożliwia autentyfikowane aktualizacje, ale według naszych informacji,
125)  żaden zaimplementowany kod typu DHT (z dystrybuowaną tablicą haszowaną) nie
126)  obsługuje autentyfikowanych aktualizacji.</li>
127) <li>Serwery wyjściowe z sieci Tor muszą wysyłać wiele żądań DNS w sposób
128)  równoległy. Ale funkcja gethostbyname() jest słabo zaprojektowana --- zatrzymuje
129)  działanie programu dopóki nie skończy przetwarzać żądania --- wymaga więc
130)  osobnego wątku lub procesu. Dlatego Tor jest zmuszany uruchamiać wiele
131)  wątków wyłącznie dla DNS. Istnieją jakieś asynchroniczne biblioteki DNS, ale
132)  zawierają one błędy i zostały porzucone. Czy są wśród nich jakieś stabilne,
133)  szybkie, łatwe i będące wolnym oprogramowaniem? (Pamiętaj, że Tor używa
134)  OpenSSL, a OpenSSL jest (prawdopodobnie) niezgodny z GPL, więc biblioteki na
135)  licencji GPL odpadają.) Jeśli tak (lub jeśli możemy to sprawić), powinniśmy
136)  zintegrować je do Tor'a. Spójrz na <a
137)  href="http://archives.seul.org/or/talk/Sep-2005/msg00001.html">wiadomość
138)  Agl'a</a>, by poznać jedno potencjalne podejście. Zobacz też
139)  <a href="http://daniel.haxx.se/projects/c-ares/">c-ares</a> i
140)  <a href="http://www.monkey.org/~provos/libdnsres/">libdnsres</a>.
141) </li>
142) <li>Tor 0.1.1.x zawiera obsługę sprzętowych akcelelatorów kryptograficznych,
143)  poprzez OpenSSL. Ale nikt tego jeszcze nie przetestował. Czy ktoś chce
144)  zdobyć kartę i powiadomić nas, jak to działa?</li>
145) <li>Ponieważ serwer Tor'a muszą przechować i podać dalej każdą komórkę,
146)  którą obsługują, serwery o wysokiej przepustowości używają wiele
147)  megabajtów pamięci na same bufory. Potrzebujemy lepszej heurystyki do
148)  określenia, kiedy skurczyć/rozszerzyć bufory. Może to powinno być zaprojektowane
149)  podobnie jak bufory w jądrze Linuksa, gdzie jest wiele mniejszych buforów, które
150)  łączą się wzajemnie, zamiast używać monolitycznych buforów?</li>
151) <li>Zaimplementować żądania odwrotne DNS wewnątrz Tor'a (już podane w
152)  Sekcji 5.4 pliku <a href="<svnsandbox>doc/tor-spec.txt">tor-spec.txt</a>).</li>
153) <li>Dokonać analizy bezpieczeństwa Tor'a z <a
154)  href="http://en.wikipedia.org/wiki/Fuzz_testing">"fuzz"</a>. Sprawdzić, czy
155)  istnieją jakieś dobre biblioteki "fuzz", których nam potrzeba. Zdobądź sławę
156)  gdy wydamy nową wersję dzięki Tobie!</li>
157) <li>Jak trudno jest zmienić bind'a lub serwer Proxy DNS tak, by kierował swoje
158)  żądania do Tor'a poprzez nasz <a
159)  href="http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#CompatibleApplications">rozszerzenie
160)  socks - tor-resolve</a>? dsocks już to robi na BSD. A może konwertować zapytania
161)  do DNS z UDP na TCP i wysyłać je przez Tor'a?</li>
162) <li>Tor używa TCP do transportu i TLS do szyfrowania transmisji. To jest
163)  ładne i proste, ale oznacza to, że wszystkie komórki na łączu zostają
164)  opóźnione, gdy pojedynczy pakiet zostanie utracony, co oznacza, że rozsądnie
165)  obsługiwać możemy tylko strumienie TCP. Mamy <a
166)  href="http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#TransportIPnotTCP">listę
167)  powodów, dla których nie przenieśliśmy się na UDP</a>, ale byłoby dobrze
168)  skrócić tę listę. Mamy też proponowaną <a
169)  href="<svnsandbox>doc/tor-spec-udp.txt">specyfikację dla Tor'a i
170)  UDP</a> &mdash; proszę dać znać, co z nią jest nie tak.</li>
171) <li>Jesteśmy wcale niedaleko od obsługi adresów IPv6 jako docelowych (na węzłach
172)  wyjściowych). Jeśli mocno ci zależy na IPv6, to jest to chyba najlepszy punkt
173)  startu.</li>
174) </ol>
175) 
176) <a id="Research"></a>
177) <h2><a class="anchor" href="#Research">Badania</a></h2>
178) <ol>
179) <li>"Atak na odciski palców stron WWW" (website fingerprinting attack): sporządź listę kilkuset
180)  popularnych stron WWW, ściągnij ich strony i zrób listę "podpisów"
181)  dla każdej z nich. Potem obserwuj ruch sieciowy klienta Tor'a. Jak
182)  patrzysz na odbierane przez niego dane, szybko zgadujesz, którą
183)  (jeśli w ogóle) on odbiera. Po pierwsze, jak bardzo ten atak jest
184)  efektywny? Potem zacznij badać sposoby obrony: na przykład, moglibyśmy
185)  zmienić rozmiar komórki Tor'a z 512 na 1024 bajty, moglibyśmy użyć
186)  technik dopełniających, jak <a
187)  href="http://freehaven.net/anonbib/#timing-fc2004">odrzucanie obronne (defensive dropping)</a>,
188)  lub moglibyśmy dodać opóźnienia w ruchu. Jak wielki wpływ mają te
189)  rozwiązania i jak wielki wpływ na używalność (używając odpowiedniego
190)  sposobu mierzenia) ma udana obrona w każdym z przypadków?
191) </li>
192) <li>"Atak potwierdzenia w ruchu nadawca-odbiorca" (end-to-end traffic confirmation attack):
193)  obserwując ruch od Alicji do Boba, możemy <a
194)  href="http://freehaven.net/anonbib/#danezis:pet2004">porównać
195)  sygnatury ruchu i przekonać się, że obserwujemy ciągle ten sam strumień danych</a>.
196)  Jak na razie, Tor przyjmoje to jako pewnik i zakłada, że ten atak jest
197)  trywialny we wszystkich przypadkach. Po pierwsze, czy tak rzeczywiście jest?
198)  Jak wiele ruchu/danych o jakim rozkładzie jest potrzebne, by przeciwnik
199)  upewnił się, że wygrał? Czy są jakieś sytuacje (np. nie wysyłanie wiele daych),
200)  które spowolniłyby atak? Czy jakieś dopełenienia transmisji lub inne sposoby
201)  kształtowania działają lepiej od innych?
202)  </li>
203) <li>"Atak stref trasowania" (routing zones attack): większość literatury
204)  mówi o ścieżce sieciowej między Alicją a jej węzłem wejściowym (i między
205)  węzłem wyjściowym a Bobem) jako o pojedynczej ścieżce na jakimś grafie.
206)  W rzeczywisctości, ścieżka przemierza wiele systemów autonomicznych (SA), i <a
207)  href="http://freehaven.net/anonbib/#feamster:wpes2004">często zdarza się, że
208)  ten sam SA pojawia się zarówno na ścieżce wejściowej i wyjściowej</a>.
209)  Niestety, by dokładnie przewidzieć, czy podany czworobok
210)  Alicja-wejście-wyjście-Bob jest niebezpieczny, musielibyśmy ściągnąć
211)  całą strefę trasowania internetu i dokonać na niej czasochłonnych operacji.
212)  Czy są jakieś praktyczne aproksymacje, jak np. unikanie adresów IP z tej
213)  samej sieci /8?
214)  </li>
215) <li>Tor nie działa za dobrze, gdy serwery mają asymetryczne łącze
216)  (np. kablówka czy DSL). Ponieważ Tor wykonuje oddzielne połączenia między
217)  każdym skokiem, jeśli przychodzące bajty są przysyłane dobrze, a wychodzące
218)  są wyrzucane, mechanizmy push-back w TCP nie transmitują tej informacji
219)  z powrotem do strumienia przychodzącego. Być może Tor powinien odkryć, gdy
220)  wyrzuca dużo pakietów wychodzących, i ograniczyć strumienie przychodzące,
221)  by sam tym regulować? Można sobie wyobrazić schemat działania, w którym
222)  najpierw wybieramy niski limit przepustowości, powoli go zwiększając aż do
223)  chwili w której zaczęlibyśmy tracić pakiety - wtedy nastąpiłoby cofnięcie się.
224)  Potrzebujemy kogoś dobrze znającego sieci by to zasymulował i pomógł
225)  zaprojektować rozwiązania; musimy zrozumieć stopień degradacji wydajności i
226)  użyć tego argumentu jako motywacji do ponownego rozpatrzenia transportu UDP.
227)  </li>
228) <li>Powiązanym tematem jest kontrola zatorów. Czy nasz dotychczasowy projekt
229)  okaże się wystarczający, gdy będziemy mieli duży ruch? Może powinniśmy
230)  poeksperymentować z oknami o zmiennym rozmiarze zamiast z oknami o stałym?
231)  To zdawało się działać nieźle w <a
232)  href="http://www.psc.edu/networking/projects/hpn-ssh/theory.php">eksperymencie
233)  przepustowości SSH</a>. Będziemy musieli mierzyć i podkręcać, i być może
234)  wykonać poprawki, jeśli wyniki okażą się dobre.
235)  </li>
236) <li>Aby umożliwić dysydentom w innych krajach używanie Tor'a bez bycia
237)  zablokowanym przez zaporę ogniową w ich kraju, potrzebujemy sposobu na
238)  zdobycie dziesiątek tysięcy serwerów pośredniczących, nie zaledwie kilkuset.
239)  Wyobrażamy sobie GUI klienta Tor'a, które na górze ma przycisk "Pomóż Chinom",
240)  który otwiera port i przekierowuje kilka kB/s ruchu do sieci Tor. (Kilka kB/s
241)  nie powinno być dużym kłopotem i nie będzie wiele spraw o nadużycia, gdyż
242)  nie będą to węzły wyjściowe.) Ale jak rozpowszechniać listę tych
243)  klientów-wolontariuszy do dobrych dysydentów automatycznie w taki sposób, który
244)  nie pozwoli krajowym zaporom ogniowym przechwycić i zliczyć ich? To prawdopodobnie
245)  musi działać poziomie zaufania ludzkiego. Spójrz na nasz <a
246)  href="http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#China">wpis w FAQ</a>
247)  o tym, a potem przeczytaj <a
248)  href="http://freehaven.net/anonbib/topic.html#Communications_20Censorship">sekcję w anonbib o
249)  przeciwstawianiu się cenzurze</a>.</li>
250) <li>Obwody Tor'a są budowane po jednym elemencie na raz, więc teoretycznie
251)  możemy uczynić, aby część strumieni wychodziła z drugiego węzła, część z

252)  trzeciego itd. To wydaje się dobre, bo ogranicza zbiór strumieni wychodzących,