Trzy rzeczy, które każdy może zrobić już teraz:
- Prosimy rozważyć uruchomienie
serwera, by wspomóc rozwój sieci Tora.
- Rozpowiadaj o systemie Tor swoim znajomym. Spraw, by uruchomili serwer.
Spraw, by uruchomili usługi ukryte. Spraw, by mówili o systemie Tor swoim znajomym.
- Szukamy funduszy i sponsorów. Jeśli podobają ci się cele Tora,
poświęć chwilę, by złożyć dotację, aby wspomóc przyszły rozwój Tora.
Jeśli znasz jakieś firmy, organizacje pozarządowe, agencje lub inne organizacje, które
są zainteresowane bezpieczną komunikacją, daj im znać o nas.
- Potrzebujemy dobrych sposobów na przechwytywanie żądań DNS, żeby nie
"przeciekały" do lokalnych obserwatorów, podczas gdy chcemy zachować anonimowość.
(Dzieje się tak, gdyż aplikacja wysyła żądanie DNS przed przejściem przez serwer
Proxy SOCKS.)
- Sprawy z Tsocks/dsocks:
- Musimy zastosować
nasze wszystkie łaty tsocks do kodu i utrzymywać nową gałąź. Możemy ją hostować, jeśli chcesz.
- Powinniśmy załatać program "dsocks" Duga Songa, by używał komend
mapaddress Tora z interfejsu kontroli, żeby nie marnować przejścia
całej trasy w Torze, wykonując rozwiązywanie adresów przed połączeniem.
- Musimy sprawić, by nasz skrypt torify wykrywał, który z programów
tsocks lub dsocks jest zainstalowany, i odpowiednio je uruchamiał. To
prawdopodobnie oznacza zunifikowanie ich interfejsów i w grę może wchodzić
dzielenie kodu między nimi lub całkowita rezygnacja z jednego z nich.
- Ludzie, którzy uruchomili serwer Tora mówią nam, że chcą dać jedną
przepustowość łącza dla Tora (BandwidthRate) w czasie pewnej części dnia,
a inną w innych częściach dnia. Zamiast programować to w Torze, powinniśmy mieć
mały skrypt, który łączy się przez Tor Controller Interface,
i wykonuje SETCONF by zmienić przepustowość. Być może ten skrypt byłby uruchamiany
z crona, a może byłby uśpiony aż do właściwego momentu i wtedy wykonywał swoją
pracę (to by raczej było bardziej przenośne). Czy ktoś mógłby napisać taki
skrypt za nas, a my byśmy go umieścili w katalogu contrib/?
To byłby dobry wkład w Konkurs na GUI dla Tora.
- Tor może wychodzić
z sieci Tora z podanego węzła, ale powinniśmy móc podać tylko kraj i mieć coś,
co automatycznie za nas wybierze węzeł. Najlepszym kandydatem jest pobranie także
katalogu Blossom i uruchomienie lokalnego klienta Blossom, który pobrałby swój katalog w
sposób bezpieczny (poprzez Tor i sprawdzając jego podpis), przechwycałby nazwy
hostów .country.blossom i robił to, co trzeba.
- A mówiąc o danych geolokacyjnych, ktoś powinien narysować mapę Ziemi z
zaznaczonym każdym serwerem Tora. Dodatkowe punkty, jeśli mapa będzie się
aktualizować w miarę jak sieć rośnie i się zmienia. Niestety, łatwy sposób na
dokonanie tego to wysłanie wszystkich danych do Google, w celu narysowania
przez nich taj mapy. Jak bardzo to uderza w prywatność i czy mamy jakieś inne
dobre wyjścia?
- Słyszeliśmy, że użytkownicy Tora mogą paść ofiarami ataków
łamiących ich anonimowość ze strony JavaScriptu, Javy, Active'a, Flasha itp.,
jeśli ich nie wyłączą. Czy są jakieś wtyczki/rozszerzenia (jak NoScript dla
Firefoksa), które ułatwiają panowanie nad tym ryzykiem? Jakie dokładnie jest to ryzyko?
- Czy istnieje kompletny zestaw wtyczek/rozszerzeń, który zastąpi całą
funkcjonalność Privoxy w Firefoksie 1.5+? Podobno Tor jest o wiele szybszy, gdy
nie używa się Privoxy.
- Proszę pomóc Mattowi Edmanowi z dokumentacją i dokumentami jak-to-zrobić do
jego projektu Tor Controller i Vidalia.
- Przejrzyj i udokumentuj
naszą
listę programów, które można skonfigurować do współpracy z Torem.
- Potrzebujemy lepszej dokumentacji do dynamicznego przechwytywania połączeń
i wysyłania ich przez Tora. tsocks (Linux), dsocks (BSD),
i freecap (Windows) zdają się być dobrymi kandydatami, jako że lepiej
używałyby naszej nowej cechy TransPort.
- Mamy ogromną listę potencjalnie
użytecznych programów, które współpracują z Torem. Które z nich są
przydatne w jakich sytuacjach? Proszę pomóż nam je testować i zapisuj
swoje wyniki.
- Pomóż przetłumaczyć stronę WWW i dokumentację na inne języki. Spójrz na
wskazówki do
tłumaczenia, jeśli chcesz pomóc. Potrzebujemy zwłaszcza tłumaczy na język
arabski i Farsi dla wielu użytkowników Tora w cenzorowanych obszarach.
- Serwery Tora nie działają zbyt dobrze na Windows XP. Pod systemem Windows Tor
używa standardowej funkcji systemowej select(), która zużywa miejsce
w niestronicowanym obszarze pamięci, będąc
przyczyną dziwnych zachowań i padów systemu. Powinniśmy raczej używać
nakładającego IO. Jednym z rozwiązań byłoby nauczenie biblioteki libevent, jak używać nakładającego IO
zamiast select() pod Windows, po czym zaadaptować Tora do nowego interfejsu.
- Ponieważ serwery Tora muszą przechować i podać dalej każdą komórkę,
którą obsługują, serwery o wysokiej przepustowości używają wiele
megabajtów pamięci na same bufory. Potrzebujemy lepszej heurystyki do
określenia, kiedy skurczyć/rozszerzyć bufory. Może to powinno być zaprojektowane
podobnie jak bufory w jądrze Linuksa, gdzie jest wiele mniejszych buforów, które
łączą się wzajemnie, zamiast używać monolitycznych buforów?
- Potrzebujemy oficjalnej, centralnej strony, która odpowiadałaby na pytania
"Czy to jest adres serwera wyjściowego z sieci Tor?". Strona powinna dostarczyć klika
interfejsów, łącznie z interfejsem www i w stylu DNSBL. Powinna dostarczać najbardziej
aktualne odpowiedzi, przechowując lokalną kopię katalogów. Haczyk jest w tym, że
bycie serwerem wyjściowym to nie tylko prawda czy fałsz, więc pytanie powinno raczej
brzmieć: "Czy to jest adres serwera wyjściowego z sieci Tor, z którego można się
połączyć z moim adresem IP i portem?". Interfejs DNSBL będzie pewnie otrzymywał
setki zapytań na minutę, potrzeba więc mądrych algorytmów. Dodatkowe punkty, jeśli
aktywnie byłoby sprawdzane każdego węzła wyjściowego, z jakiego adresu IP naprawdę
wychodzą dane. Czytaj więcej tu.
- Czasami serwery Tora padają, komputery z tymi serwerami zostają odłączone od sieci
lub zdarzają się inne wypadki. Część operatorów Tora wyraziła zainteresowanie zapisaniem
się do usługi "powiadamiającej", która okresowo sprawdzałaby, czy ich serwer działa, i
wysyłała list przypominający, gdy serwer nie działa. Czy ktoś chce napisać kilka skryptów
CGI, kilka stron internetowych i używać jakiegoś sposobu z Wget lub czegoś bardziej
złożonego jak Nagios do monitorowania? Pierwsza wersja
mogłaby po prostu sprawdzać port w katalogu, np. przeglądając zapisaną stronę ze
stanem sieci w poszukiwaniu właściwego adresu IP i portu, po czym żądając strony
"/tor/server/authority".
- Byłoby wspaniale mieć LiveCD zawierające najnowsze wersje Tor, Polipo lub Privoxy,
Firefox, Gaim+OTR itp. Są tu dwa wyzwania: pierwszym jest udokumentowanie systemu i
możliwości wyboru dość dobrze, by ludzie zajmujący się bezpieczeństwem mogli wydać opinię
o tym, czy taki system byłby bezpieczny, a drugim wyzwaniem jest jak sprawić, by taki
system był łatwy w utrzymaniu, żeby nie ulegał szybkim przedawnieniom, jak AnonymOS.
Dodatkowe punkty, jeśli obraz CD zmieści się na małej płycie.
- W połączeniu z obrazem LiveCD, powinniśmy popracować nad intuicyjnie bezpiecznym
i dobrze udokumentowanym obrazem USB dla Tora i aplikacji obsługujących. Ciężką
częścią tutaj jest zdecydowanie, jakie konfiguracje są bezpieczne, dokumentowanie
tych decyzji i zrobienie czegoś, co łatwo będzie utrzymać w przyszłości.
- Nasz preferowany interfejs graficzny dla Tora, o nazwie
Vidalia, potrzebuje różnego rodzaju pracy włożonej
w rozwój.
- Musimy zacząć budować nasz projekt odporny na blokowanie. Wchodzi w to
przemyślenie projektu, zmiana wielu różnych elementów Tora, zaadaptowanie
Vidalii, by obsługiwała nowe cechy i
planowanie rozpowszechniania.
- Potrzebujemy elastycznego frameworka symulacji do badania ataków potwierdzenia
ruchu od nadawcy do odbiorcy (end-to-end). Wielu ludzi szybko wyciągnęło/napisało doraźne
symulatory odpowiadające ich intuicji, że albo ataki znakomicie się udają, albo
że obrona działa dobrze. Czy możemy zbudować symulator, który jest dobrze udokumentowany
i dość otwarty, by wszyscy wiedzieli, że daje rozsądną odpowiedź? To zacznie wiele nowych
badań. Spójrz na wpis poniżej o atakach potwierdzenia po szczegóły
strony badawczej tego zadania — kto wie, może gdy będzie skończone, pomożesz nam też
napisać dokumentację.
- Potrzebujemy badań pomiarowych/porównawczych Polipo
vs Privoxy. Czy Polipo jest rzeczywiście znacznie
szybszy, po wliczeniu opóźnienia spowodowanego Torem? Czy wyniki są takie same na
Linuksie i Windows? Związany z tym problem: czy Polipo obsługuje więcej stron poprawnie,
niże Privoxy, czy na odwrót? Czy są problemy ze stabilnością na jednej z popularnych
platform, np. Windows?
- W związku z powyższym, czy chciałbyś pomóc przenieść Polipo tak, by działało
stabilnie i wydajnie pod Windows?
- Potrzebujemy framework'a do testów rozproszonych. Mamy pojedyncze testy, ale byłoby
wspaniale mieć skrypt, który uruchamia sieć Tora, używa jej przez chwilę i weryfikuje,
że przynajmniej jej część działa.
- Pomóżcie Mike'owi Perry z jego biblioteką TorFlow
(TODO):
jest to biblioteka napisana w Pythonie, która używa protokołu kontroli Tora,
by instruować Tora do budowania obwodów na wiele różnych sposobów, po czym
mierzy wydajność i próbuje wykryć anomalie.
- Tor 0.1.1.x i późniejsze zawiera obsługę sprzętowych akceleratorów kryptograficznych,
poprzez OpenSSL. Ale nikt tego jeszcze nie przetestował. Czy ktoś chce
zdobyć kartę i powiadomić nas, jak to działa?
- Dokonać analizy bezpieczeństwa Tora z "fuzz". Sprawdzić, czy
istnieją jakieś dobre biblioteki "fuzz", których nam potrzeba. Zdobądź sławę
gdy wydamy nową wersję dzięki Tobie!
- Tor używa TCP do transportu i TLS do szyfrowania transmisji. To jest
ładne i proste, ale oznacza to, że wszystkie komórki na łączu zostają
opóźnione, gdy pojedynczy pakiet zostanie utracony, co oznacza, że rozsądnie
obsługiwać możemy tylko strumienie TCP. Mamy listę
powodów, dla których nie przenieśliśmy się na UDP, ale byłoby dobrze
skrócić tę listę. Mamy też proponowaną specyfikację dla Tora i
UDP — proszę dać znać, co z nią jest nie tak.
- Jesteśmy wcale niedaleko od obsługi adresów IPv6 jako docelowych (na węzłach
wyjściowych). Jeśli mocno ci zależy na IPv6, to jest to chyba najlepszy punkt
startu.
- Nie podoba ci się żaden z tych pomysłów? Spójrz na plan rozwoju Tora po więcej pomysłów.
- Nie widzisz tu swojego pomysłu? Prawdopodobnie i tak go potrzebujemy! Skontaktuj się
z nami, by to sprawdzić.
- "Atak na odciski palców stron WWW" (website fingerprinting attack): sporządź listę kilkuset
popularnych stron WWW, ściągnij ich strony i zrób listę "podpisów"
dla każdej z nich. Potem obserwuj ruch sieciowy klienta Tora. Jak
patrzysz na odbierane przez niego dane, szybko zgadujesz, którą
(jeśli w ogóle) on odbiera. Po pierwsze, jak bardzo ten atak jest
efektywny? Potem zacznij badać sposoby obrony: na przykład, moglibyśmy
zmienić rozmiar komórki Tora z 512 na 1024 bajty, moglibyśmy użyć
technik dopełniających, jak odrzucanie obronne (defensive dropping),
lub moglibyśmy dodać opóźnienia w ruchu. Jak wielki wpływ mają te
rozwiązania i jak wielki wpływ na używalność (używając odpowiedniego
sposobu mierzenia) ma udana obrona w każdym z przypadków?
- "Atak potwierdzenia w ruchu nadawca-odbiorca" (end-to-end traffic confirmation attack):
obserwując ruch od Alicji do Boba, możemy porównać
sygnatury ruchu i przekonać się, że obserwujemy ciągle ten sam strumień danych.
Jak na razie, Tor przyjmuje to jako pewnik i zakłada, że ten atak jest
trywialny we wszystkich przypadkach. Po pierwsze, czy tak rzeczywiście jest?
Jak wiele ruchu/danych o jakim rozkładzie jest potrzebne, by przeciwnik
upewnił się, że wygrał? Czy są jakieś sytuacje (np. nie wysyłanie wiele danych),
które spowolniłyby atak? Czy jakieś dopełnienia transmisji lub inne sposoby
kształtowania działają lepiej od innych?
- "Atak stref trasowania" (routing zones attack): większość literatury
mówi o ścieżce sieciowej między Alicją a jej węzłem wejściowym (i między
węzłem wyjściowym a Bobem) jako o pojedynczej ścieżce na jakimś grafie.
W rzeczywistości, ścieżka przemierza wiele systemów autonomicznych (SA), i często zdarza się, że
ten sam SA pojawia się zarówno na ścieżce wejściowej i wyjściowej.
Niestety, by dokładnie przewidzieć, czy podany czworobok
Alicja-wejście-wyjście-Bob jest niebezpieczny, musielibyśmy ściągnąć
całą strefę trasowania internetu i dokonać na niej czasochłonnych operacji.
Czy są jakieś praktyczne aproksymacje, jak np. unikanie adresów IP z tej
samej sieci /8?
- Inne pytania badawcze dotyczące różnorodności geograficznej rozpatrują
kompromis między wybieraniem obwodu wydajnego a losowego. Spójrz na dokument o
pozycjach Stephena Rollysona na temat tego, jak odrzucać szczególnie wolne
możliwości bez zbytniej utraty anonimowości. Ta argumentacja wymaga więcej pracy i
myślenia, ale wygląda bardzo obiecująco.
- Tor nie działa za dobrze, gdy serwery mają asymetryczne łącze
(np. kablówka czy DSL). Ponieważ Tor wykonuje oddzielne połączenia między
każdym skokiem, jeśli przychodzące bajty są przysyłane dobrze, a wychodzące
są wyrzucane, mechanizmy push-back w TCP nie transmitują tej informacji
z powrotem do strumienia przychodzącego. Być może Tor powinien odkryć, gdy
wyrzuca dużo pakietów wychodzących, i ograniczyć strumienie przychodzące,
by sam tym regulować? Można sobie wyobrazić schemat działania, w którym
najpierw wybieramy niski limit przepustowości, powoli go zwiększając aż do
chwili w której zaczęlibyśmy tracić pakiety - wtedy nastąpiłoby cofnięcie się.
Potrzebujemy kogoś dobrze znającego sieci by to zasymulował i pomógł
zaprojektować rozwiązania; musimy zrozumieć stopień degradacji wydajności i
użyć tego argumentu jako motywacji do ponownego rozpatrzenia transportu UDP.
- Powiązanym tematem jest kontrola zatorów. Czy nasz dotychczasowy projekt
okaże się wystarczający, gdy będziemy mieli duży ruch? Może powinniśmy
poeksperymentować z oknami o zmiennym rozmiarze zamiast z oknami o stałym?
To zdawało się działać nieźle w eksperymencie
przepustowości SSH. Będziemy musieli mierzyć i podkręcać, i być może
wykonać poprawki, jeśli wyniki okażą się dobre.
- Aby umożliwić dysydentom w innych krajach używanie Tora bez bycia
zablokowanym przez zaporę ogniową w ich kraju, potrzebujemy sposobu na
zdobycie dziesiątek tysięcy serwerów pośredniczących, nie zaledwie kilkuset.
Wyobrażamy sobie GUI klienta Tora, które na górze ma przycisk "Tor dla wolności",
który otwiera port i przekierowuje kilka kB/s ruchu do sieci Tor. (Kilka kB/s
nie powinno być dużym kłopotem i nie będzie wiele spraw o nadużycia, gdyż
nie będą to węzły wyjściowe.) Ale jak rozpowszechniać listę tych
klientów-wolontariuszy do dobrych dysydentów automatycznie w taki sposób, który
nie pozwoli krajowym zaporom ogniowym przechwycić i zliczyć ich? To prawdopodobnie
musi działać poziomie zaufania ludzkiego. Spójrz na nasz
wstępny dokument o
ochronie przed blokowaniem i na nasz wpis w FAQ
o tym, a potem przeczytaj sekcję w anonbib o
przeciwstawianiu się cenzurze.
- Obwody Tora są budowane po jednym elemencie na raz, więc teoretycznie
możemy uczynić, aby część strumieni wychodziła z drugiego węzła, część z
trzeciego itd. To wydaje się dobre, bo ogranicza zbiór strumieni wychodzących,
które dany serwer może zobaczyć. Ale jeśli chcemy by każdy strumień był
bezpieczny, "najkrótsza" ścieżka powinna, według naszego bieżącego rozumowania,
składać się z co najmniej 3 elementów, więc inne będą jeszcze dłuższe.
Musimy zbadać ten kompromis wydajność/bezpieczeństwo.
- Nie jest trudno wykonać atak DoS na serwery Tora lub serwery katalogowe.
Zagadki dla klientów (?) (client puzzles) są właściwą odpowiedzią? Jakie są
inne praktyczne podejścia? Dodatkowe punkty, jeśli są zgodne wstecz z
bieżącym protokołem Tora.
Daj nam znać, jeśli poczyniłeś postępy nad którąkolwiek z tych rzeczy!
