tor-webwml.git

1) ## translation metadata

2) # Based-On-Revision: 9231

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>Trzy 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>Rozpowiadaj o systemie Tor swoim znajomym. Spraw, by uruchomili serwer.
15)  Spraw, by uruchomili usługi ukryte. Spraw, by mówili o systemie Tor swoim znajomym.</li>
16) <li>Szukamy funduszy i sponsorów. Jeśli podobają ci się cele Tor'a,

17)   <a href="<page donate>">poświęć chwilę, by złożyć dotację, aby wspomóc przyszły rozwój Tor'a</a>.

18)   Jeśli znasz jakieś firmy, organizacje pozarządowe, agencje lub inne organizacje, które
19)   są zainteresowane bezpieczną komunikacją, daj im znać o nas.</li>
20) </ol>
21) 
22) <a id="Bugs"></a>
23) <h2><a class="anchor" href="#Bugs">Błędy krytyczne</a></h2>
24) <ol>

25) <li>Serwery Tor'a nie są aktualnie stabilne na Windows XP, gdyż próbujemy używać

26)  setek gniazd, a zdaje się, że jądro Windowsa nie jest w stanie tyle obsłużyć. <a
27)  href="http://wiki.noreply.org/noreply/TheOnionRouter/WindowsBufferProblems">Prosimy,
28)  pomóż nam rozwiązać ten problem!</a> Prawdopodobnie najlepszym rozwiązaniem jest
29)  nauczyć bibliotekę libevent, jak używać nakładającego się I/O zamiast select() w
30)  Windows, a potem przystosować Tor'a do nowego interfejsu libevent.</li>
31) </ol>
32) 
33) <a id="Usability"></a>
34) <h2><a class="anchor" href="#Usability">Aplikacje Wspomagające</a></h2>
35) <ol>
36)  <li>Potrzebujemy dobrych sposobów na przechwytywanie żądań DNS, żeby nie

37)  "przeciekały" do lokalnych obserwatorów, podczas gdy chcemy zachować anonimowość.

38)  (Dzieje się tak, gdyż aplikacja wysyła żądanie DNS przed przejściem przez serwer
39)  Proxy SOCKS.)</li>

40) <li><ul>

41) <li>Musimy <a
42)  href="http://wiki.noreply.org/noreply/TheOnionRouter/TSocksPatches">zastosować
43)  nasze wszystkie łaty tsocks do kodu</a> i utrzymywać nową gałąź. Możemy ją hostować, jeśli chcesz.</li>
44) <li>Powinniśmy załatać program "dsocks" Dug'a Song'a, by używał komend
45)  <i>mapaddress</i> Tor'a z interfejsu kontroli, żeby nie marnować przejścia

46)  całej trasy w Torze, wykonując rozwiązywanie adresów przed połączeniem.</li>

47) <li>Musimy sprawić, by nasz skrypt <i>torify</i> wykrywał, który z programów
48)  tsocks lub dsocks jest zainstalowany, i odpowiednio je uruchamiał. To
49)  prawdopodobnie oznacza zunifikowanie ich interfejsów i w grę może wchodzić
50)  dzielenie kodu między nimi lub całkowita rezygnacja z jednego z nich.</li>

51) </ul></li>

52) <li>Ludzie, którzy uruchomili serwer Tor'a mówią nam, że chcę dać jedną
53)  przepustowość łącza dla Tor'a (BandwidthRate) w czasie pewnej części dnia,
54)  a inną w innych częściach dnia. Zamiast programować to w Torze, powinniśmy mieć
55)  mały skrypt, który łączy się przez <a href="<page gui/index>">Tor Controller Interface</a>,
56)  i wykonuje SETCONF by zmienić przepustowość. Być może ten skrypt byłby uruchamiany
57)  z cron'a, a może byłby uśpiony aż do właściwego momentu i wtedy wykonywał swoją
58)  pracę (to by raczej było bardziej przenośne). Czy ktoś mógłby napisać taki
59)  skrypt za nas, a my byśmy go umieścili w katalogu <a href="<svnsandbox>contrib/">contrib/</a>?

60)  To byłby dobry wkład w <a href="<page gui/index>">Konkurs na GUI dla Tor'a</a>.
61) 	 <!-- We have a good script to adjust stuff now, right? -NM -->
62)  </li>

63) <li>Tor może <a
64)  href="http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#ChooseEntryExit">wychodzić
65)  z sieci Tor'a z podanego węzła</a>, ale powinniśmy móc podać tylko kraj i mieć coś,
66)  co automatycznie za nas wybierze węzeł. Najlepszym kandydatem jest pobranie także
67)  katalogu Blossom i uruchomienie lokalnego klienta Blossom, który pobrałby swój katalog w
68)  sposób bezpieczny (poprzez Tor i sprawdzając jego podpis), przechwycałby nazwy
69)  hostów <tt>.country.blossom</tt>  i robił to, co trzeba.</li>
70) <li>A mówiąc o danych geolokacyjnych, ktoś powinien narysować mapę Ziemi z
71)  zaznaczonym każdym serwerem Tor'a. Dodatkowe punkty, jeśli mapa bęzdie się
72)  aktualizować w miarę jak sieć rośnie i się zmienia. Niestety, łatwy sposób na
73)  dokonanie tego to wysłanie wszystkich danych do Google, w celu narysowania
74)  przez nich taj mapy. Jak bardzo to uderza w prywatność i czy mamy jakieś inne
75)  dobre wyjścia?</li>
76) </ol>
77) 
78) <a id="Documentation"></a>
79) <h2><a class="anchor" href="#Documentation">Dokumentacja</a></h2>
80) <ol>
81) <li>Słyszeliśmy, że użytkownicy Tor'a mogą paść ofiarami ataków
82)  łamiących ich anonimowość ze strony JavaScript'u, Javy, ActiveX'a, Flash'a itp.,
83)  jeśli ich nie wyłączą. Czy są jakieś wtyczki/rozszerzenia (jak NoScript dla

84)  Firefox'a), które ułatwiają panowanie nad tym ryzykiem? Jakie dokładnie jest to ryzyko?

85)  </li>
86) <li>Czy istnieje kompletny zestaw wtyczek/rozszerzeń, który zastąpi całą
87)  funkcjonalność Privoxy w Firefoksie 1.5+? Podobno Tor jest o wiele szybszy, gdy
88)  nie używa się Privoxy.</li>
89) <li>Proszę pomóc Matt'owi Edman'owi z dokumentacją i dokumentami jak-to-zrobić do

90)  jego projektu Tor Controller i <a href="http://vidalia-project.net/">Vidalia</a>.</li>

91) <li>Przejrzyj i udokumentuj
92)  <a href="http://wiki.noreply.org/wiki/TheOnionRouter/TorifyHOWTO">naszą
93)  listę programów</a>, które można skonfigurować do współpracy z Tor'em.</li>
94) <li>Potrzebujemy lepszej dokumentacji do dynamicznego przechwytywania połączeń
95)  i wysyłania ich przez Tor'a. tsocks (Linux), dsocks (BSD),

96)  i freecap (Windows) zdają się być dobrymi kandydatami, jako że lepiej
97)  używałyby naszej nowej cechy TransPort.</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) 

128) <li>Tor 0.1.1.x zawiera obsługę sprzętowych akcelelatorów kryptograficznych,
129)  poprzez OpenSSL. Ale nikt tego jeszcze nie przetestował. Czy ktoś chce
130)  zdobyć kartę i powiadomić nas, jak to działa?</li>
131) <li>Ponieważ serwer Tor'a muszą przechować i podać dalej każdą komórkę,
132)  którą obsługują, serwery o wysokiej przepustowości używają wiele
133)  megabajtów pamięci na same bufory. Potrzebujemy lepszej heurystyki do
134)  określenia, kiedy skurczyć/rozszerzyć bufory. Może to powinno być zaprojektowane
135)  podobnie jak bufory w jądrze Linuksa, gdzie jest wiele mniejszych buforów, które
136)  łączą się wzajemnie, zamiast używać monolitycznych buforów?</li>
137) <li>Dokonać analizy bezpieczeństwa Tor'a z <a
138)  href="http://en.wikipedia.org/wiki/Fuzz_testing">"fuzz"</a>. Sprawdzić, czy
139)  istnieją jakieś dobre biblioteki "fuzz", których nam potrzeba. Zdobądź sławę
140)  gdy wydamy nową wersję dzięki Tobie!</li>
141) <li>Tor używa TCP do transportu i TLS do szyfrowania transmisji. To jest
142)  ładne i proste, ale oznacza to, że wszystkie komórki na łączu zostają
143)  opóźnione, gdy pojedynczy pakiet zostanie utracony, co oznacza, że rozsądnie
144)  obsługiwać możemy tylko strumienie TCP. Mamy <a
145)  href="http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#TransportIPnotTCP">listę
146)  powodów, dla których nie przenieśliśmy się na UDP</a>, ale byłoby dobrze
147)  skrócić tę listę. Mamy też proponowaną <a
148)  href="<svnsandbox>doc/tor-spec-udp.txt">specyfikację dla Tor'a i
149)  UDP</a> &mdash; proszę dać znać, co z nią jest nie tak.</li>
150) <li>Jesteśmy wcale niedaleko od obsługi adresów IPv6 jako docelowych (na węzłach
151)  wyjściowych). Jeśli mocno ci zależy na IPv6, to jest to chyba najlepszy punkt
152)  startu.</li>
153) </ol>
154) 
155) <a id="Research"></a>
156) <h2><a class="anchor" href="#Research">Badania</a></h2>
157) <ol>
158) <li>"Atak na odciski palców stron WWW" (website fingerprinting attack): sporządź listę kilkuset
159)  popularnych stron WWW, ściągnij ich strony i zrób listę "podpisów"
160)  dla każdej z nich. Potem obserwuj ruch sieciowy klienta Tor'a. Jak
161)  patrzysz na odbierane przez niego dane, szybko zgadujesz, którą
162)  (jeśli w ogóle) on odbiera. Po pierwsze, jak bardzo ten atak jest
163)  efektywny? Potem zacznij badać sposoby obrony: na przykład, moglibyśmy
164)  zmienić rozmiar komórki Tor'a z 512 na 1024 bajty, moglibyśmy użyć
165)  technik dopełniających, jak <a
166)  href="http://freehaven.net/anonbib/#timing-fc2004">odrzucanie obronne (defensive dropping)</a>,
167)  lub moglibyśmy dodać opóźnienia w ruchu. Jak wielki wpływ mają te
168)  rozwiązania i jak wielki wpływ na używalność (używając odpowiedniego
169)  sposobu mierzenia) ma udana obrona w każdym z przypadków?
170) </li>
171) <li>"Atak potwierdzenia w ruchu nadawca-odbiorca" (end-to-end traffic confirmation attack):
172)  obserwując ruch od Alicji do Boba, możemy <a
173)  href="http://freehaven.net/anonbib/#danezis:pet2004">porównać
174)  sygnatury ruchu i przekonać się, że obserwujemy ciągle ten sam strumień danych</a>.

175)  Jak na razie, Tor przyjmuje to jako pewnik i zakłada, że ten atak jest

176)  trywialny we wszystkich przypadkach. Po pierwsze, czy tak rzeczywiście jest?
177)  Jak wiele ruchu/danych o jakim rozkładzie jest potrzebne, by przeciwnik
178)  upewnił się, że wygrał? Czy są jakieś sytuacje (np. nie wysyłanie wiele daych),
179)  które spowolniłyby atak? Czy jakieś dopełenienia transmisji lub inne sposoby
180)  kształtowania działają lepiej od innych?
181)  </li>
182) <li>"Atak stref trasowania" (routing zones attack): większość literatury
183)  mówi o ścieżce sieciowej między Alicją a jej węzłem wejściowym (i między
184)  węzłem wyjściowym a Bobem) jako o pojedynczej ścieżce na jakimś grafie.
185)  W rzeczywisctości, ścieżka przemierza wiele systemów autonomicznych (SA), i <a
186)  href="http://freehaven.net/anonbib/#feamster:wpes2004">często zdarza się, że
187)  ten sam SA pojawia się zarówno na ścieżce wejściowej i wyjściowej</a>.
188)  Niestety, by dokładnie przewidzieć, czy podany czworobok
189)  Alicja-wejście-wyjście-Bob jest niebezpieczny, musielibyśmy ściągnąć
190)  całą strefę trasowania internetu i dokonać na niej czasochłonnych operacji.
191)  Czy są jakieś praktyczne aproksymacje, jak np. unikanie adresów IP z tej
192)  samej sieci /8?
193)  </li>
194) <li>Tor nie działa za dobrze, gdy serwery mają asymetryczne łącze
195)  (np. kablówka czy DSL). Ponieważ Tor wykonuje oddzielne połączenia między
196)  każdym skokiem, jeśli przychodzące bajty są przysyłane dobrze, a wychodzące
197)  są wyrzucane, mechanizmy push-back w TCP nie transmitują tej informacji
198)  z powrotem do strumienia przychodzącego. Być może Tor powinien odkryć, gdy
199)  wyrzuca dużo pakietów wychodzących, i ograniczyć strumienie przychodzące,
200)  by sam tym regulować? Można sobie wyobrazić schemat działania, w którym
201)  najpierw wybieramy niski limit przepustowości, powoli go zwiększając aż do
202)  chwili w której zaczęlibyśmy tracić pakiety - wtedy nastąpiłoby cofnięcie się.
203)  Potrzebujemy kogoś dobrze znającego sieci by to zasymulował i pomógł
204)  zaprojektować rozwiązania; musimy zrozumieć stopień degradacji wydajności i
205)  użyć tego argumentu jako motywacji do ponownego rozpatrzenia transportu UDP.
206)  </li>
207) <li>Powiązanym tematem jest kontrola zatorów. Czy nasz dotychczasowy projekt
208)  okaże się wystarczający, gdy będziemy mieli duży ruch? Może powinniśmy
209)  poeksperymentować z oknami o zmiennym rozmiarze zamiast z oknami o stałym?
210)  To zdawało się działać nieźle w <a
211)  href="http://www.psc.edu/networking/projects/hpn-ssh/theory.php">eksperymencie
212)  przepustowości SSH</a>. Będziemy musieli mierzyć i podkręcać, i być może
213)  wykonać poprawki, jeśli wyniki okażą się dobre.
214)  </li>
215) <li>Aby umożliwić dysydentom w innych krajach używanie Tor'a bez bycia
216)  zablokowanym przez zaporę ogniową w ich kraju, potrzebujemy sposobu na
217)  zdobycie dziesiątek tysięcy serwerów pośredniczących, nie zaledwie kilkuset.
218)  Wyobrażamy sobie GUI klienta Tor'a, które na górze ma przycisk "Pomóż Chinom",
219)  który otwiera port i przekierowuje kilka kB/s ruchu do sieci Tor. (Kilka kB/s
220)  nie powinno być dużym kłopotem i nie będzie wiele spraw o nadużycia, gdyż
221)  nie będą to węzły wyjściowe.) Ale jak rozpowszechniać listę tych
222)  klientów-wolontariuszy do dobrych dysydentów automatycznie w taki sposób, który
223)  nie pozwoli krajowym zaporom ogniowym przechwycić i zliczyć ich? To prawdopodobnie
224)  musi działać poziomie zaufania ludzkiego. Spójrz na nasz <a
225)  href="http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#China">wpis w FAQ</a>
226)  o tym, a potem przeczytaj <a
227)  href="http://freehaven.net/anonbib/topic.html#Communications_20Censorship">sekcję w anonbib o
228)  przeciwstawianiu się cenzurze</a>.</li>
229) <li>Obwody Tor'a są budowane po jednym elemencie na raz, więc teoretycznie
230)  możemy uczynić, aby część strumieni wychodziła z drugiego węzła, część z

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

232)  które dany serwer może zobaczyć. Ale jeśli chcemy by każdy strumień był
233)  bezpieczny, "najkrótsza" ścieżka powinna, według naszego bieżącego rozumowania,

234)  składać się z co najmniej 3 elementów, więc inne będą jeszcze dłuższe.

235)  Musimy zbadać ten kompromis wydajność/bezpieczeństwo.
236)  </li>
237) <li>Nie jest trudno wykonać atak DoS na serwery Tor'a lub serwery katalogowe.

238)  Zagadki dla klientów (?) (client puzzles) są właściwą odpowiedzią? Jakie są