Tor: Wolontariusze

Kilka rzeczy, które każdy może zrobić już teraz:

Prosimy rozważyć uruchomienie przekaźnika sieci Tor, by wspomóc rozwój sieci Tora.
Rozpowiadaj o systemie Tor swoim znajomym. Spraw, by uruchomili przekaźniki sieci. Spraw, by uruchomili usługi ukryte. Spraw, by mówili o systemie Tor swoim znajomym.
Jeśli podobają ci się cele Tora, poświęć chwilę, by złożyć dotację, aby wspomóc przyszły rozwój Tora. Szukamy też dalszych sponsorów — jeśli znasz jakieś firmy, organizacje pozarządowe, agencje lub inne organizacje, które są zainteresowane anonimowością / prywatnością / bezpieczną komunikacją, daj im znać o nas.
Szukamy więcej dobrych przykładów użytkowników Tora i przypadków jego używania. Jeśli używasz Tora w sposób jeszcze nie przedstawiony na tamtej stronie i nie masz nic przeciw podzieleniu się z nami tym sposobem, z chęcią przyjmiemy taką wiadomość.

Aplikacje Wspomagające

Potrzebujemy więcej 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 przekaźnik sieci 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ść. Jest już po jednym skrypcie dla systemów Unix i Mac (korzystają z basha i crona), ale dalej potrzebne jest rozwiązanie dla użytkowników Windowsa.
Tor może wychodzić z sieci Tora używając 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), przechwytywał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 przekaźnikiem sieci 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?

Dokumentacja

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.

Dobre Projekty Programistyczne

Oto lista opmysłów zaproponowanych na Google Summer of Code 2008, które nie zostały przyjęte. Części bieżących propozycji może też brakować deweloperów. Jeśli Twoim zdaniem możesz nam pomóc, daj nam znać!

Ulepszenie Skanera Węzłów Tora (Tor Node Scanner)
Podobnie do skanera wyjściowego SoaT (lub może nawet w czasie jego działania), można gromadzić statystyki odnośnie wiarygodności węzłów. Te węzły, które źle działają dla pewnej części swoich obwodów nie powinny być używane do statusu Strażnika, i być może powinny też mieć zmniejszoną swoją zgłaszaną przepustowość, lub po prostu być oznaczane jako Nieważne. Dodatkowo, węzły wykazujące bardzo niską średnią przepustowość strumienia, lecz zgłaszają bardzo wysoką, też mogą być oznaczone jako Nieważne. Większość zbierania statystyk już jest zrobiona, dane te muszą tylko zostać przetworzone na coś, co może być wysłane Serwerom Katalogowym, by ukarały/wyłączyły ze swoich list te węzły w taki sposób, że klienci się o tym dowiedzą.
Dodatkowo, te same statystyki mogą być zbierane odnośnie ruchu przechodzącego przez węzeł. Do Protokołu Kontroli Tora można dodać zdarzenia mówiące, czy udaje się stworzyć obwód przechodzący przez ten węzeł, oraz można zbierać pasywne statystyki dotyczące zarówno przepustowości, jak i wiarygodności innych węzłów, poprzez oparty na węzłach program monitorujący takie zdarzenia. Taki skaner zgłaszałby też informacje o dziwnie zachowujących się węzłach do Serwerów Katalogowych, ale kanał łączności do tych celów jeszcze nie istnieje i też musiałby zostać stworzony.
Pomóż śledzić ogólny status Sieci Tora
Byłoby wspaniale uruchomić automatyczny system śledzenia stanu sieci w czasie, wyświetlanie wykresów itp. Częścią tego projektu byłoby wynalezienie lepszych miary do oceny stanu i wzrostu sieci. Czy wzrasta średni czas działania sieci? Ile węzłów kwalifikuje się do bycia Strażnikami w tym miesiącu w porównaniu z ubiegłym? Jaka jest rotacja w sensie pojawiania się nowych węzłów i znikania starych? Okresowo ludzie gromadzą krótkie migawki stanu, ale to robi się naprawdę interesujące dopiero, gdy zaczynamy śledzić te dane w czasie.
Dane powinny być zbierane z powyższego narzędzia "Skaner Węzłów Tora", z deskryptorów serwerów, które są publikowane przez każdy przekaźnik i z innych źródeł. Wyniki w czasie mogłyby być zintegrowane z jedną ze stron opisujących Stan Tora lub być trzymane osobno. Skoro mówimy o stronach stanu Tora, spójrzcie na listę życzeń stanu Tora napisaną przez Rogera.
Lepsze wsparcie i pakowanie dla Debiana
Vidalia obecnie nie współpracuje dobrze na Debianie i Ubuntu z domyślnymi paczkami Tora. Bieżące paczki Tora automatycznie uruchamiają Tora jako demona systemowego z konta użytkownika debian-tor i (rozsądnie) nie mają zdefiniowanego ControlPort w domyślnym torrc. Stąd Vidalia będzie próbować uruchomić własny proces Tora, bo nie może połączyć się z istniejącym, po czym proces Tora uruchomiony przez Vidalię zamknie się z błędem, którego użytkownik raczej nie zrozumie, jako że Tor nie będzie mógł podpiąć się pod swoje porty nasłuchowe, które są już zajęte przez pierwszy proces Tora.
Bieżące rozwiązanie to albo mówienie użytkownikowi, by zatrzymał istniejący proces Tora i pozwolił Vidalii uruchomić własny, albo tłumaczenie, jak ustawić port kontrolny i hasło w pliku torrc. Lepszym rozwiązaniem na Debianie byłoby używanie ControlSocket Tora, który umożliwia Vidalii komunikowanie się z Torem poprzez gniazdo w domenie Unix i mógłby być domyślnie włączony w paczkach Tora dla Debiana. Vidalia może wtedy uwierzytelnić się do Tora używając ciasteczek, jeśli użytkownik uruchamiający Vidalię jest w grupie debian-tor.
Pierwsza część tego projektu będzie polegała na dodaniu obsługi ControlSocket do Vidalii. Potem student stworzy i przetestuje paczki Vidalii na Debianie i Ubuntu, które będą zgodne ze standardami pakowania w Debianie, oraz upewni się, że działają dobrze z istniejącymi paczkami Tora. Możemy też stworzyć repozytorium apt zawierające nowe paczki Vidalia.
Kolejnym wyzwaniem byłoby znalezienie intuicyjnego sposobu, by Vidalia mogła zmienić konfigurację Tora (torrc) mimo iż ta jest w /etc/tor/torrc, a więc nienaruszalna. Najlepszy jak dotąd pomysł, na jaki wpadliśmy, to przekazanie Torowi nowej konfiguracji poprzez ControlSocket w czasie uruchamiania Vidalii, ale jest to zły pomysł, gdyż Tor za każdym razem uruchamia się z inną konfiguracją niż użytkownik by tego chciał. Drugi najlepszy pomysł jest taki, by Vidalia stworzyła tymczasowy plik konfiguracyjny i poprosiła użytkownika, by ręcznie przeniósł go do /etc/tor/torrc, ale to jest zły pomysł, gdyż użytkownicy nie powinni być zmuszani do bezpośredniego zajmowania się plikami.
Osoba podejmująca się tego projektu powinna znać system pakowania Debiana i mieć trochę doświadczenia z C++. Uprzednie doświadczenie z Qt będzie przydatne, ale nie jest wymagane.
Polepszanie naszych zdolności opierania się cenzurze
Wersje 0.2.0.x Tora robią znaczne postępy w opieraniu się narodowej i firmowej cenzurze. Ale Tor ciągle potrzebuje lepszych mechanizmów w niektórych częściach projektu anty-cenzurowania. Na przykład, bieżące wersje mogą nasłuchiwać połączeń tylko na jednym zestawie adres/port na raz. Istnieje propozycja zajęcia się tą sprawą i umożliwienia klientom łączenie się z danym Torem na wielu adresach i portach, ale wymaga to więcej pracy. Kolejny projekt przeciw cenzurze to próba uczynienia Tora bardziej odpornym na skanowanie. W chwili obecnej ktokolwiek może zidentyfikować mostki Tora po prostu łącząc się z nimi, zgodnie z protokołem Tora, i sprawdzając, czy odpowiadają. By rozwiązać ten problem, mostki mogłyby udawać serwery internetowe (HTTP lub HTTPS), gdy łączą się z nimi programy do skanowania portów, a nie zachowywać się jak mostki do chwili, gdy użytkownik poda klucz specyficzny dla mostka.
Ten projekt zawiera wiele badań i projektowania. Jednym z większych wyzwać będzie zidentyfikowanie i umiejętne wykorzystanie rozwiązań, które oprą się atakom nawet po tym, jak atakujący pozna projekt, po czym równoważenie odporności na cenzurę z użytecznością i siłą.
Framework automatycznej aktualizacji programów Tor/Polipo/Vidalia.
Potrzebujemy dobrego frameworka automatycznej aktualizacji. Vidalia już ma możliwość informowania, że użytkownik używa przestarzałej lub niezalecanej wersji Tora. W chwili obecnej Vidalia po prostu pokazuje małe okienko, które informuje użytkownika, że powinien dokonać ręcznej aktualizacji. Celem tego projektu jest rozszerzenie Vidalii o możliwość pobrania i zaktualizowania nowej wersji Tora za użytkownika. Jeśli czas pozwoli, chcielibyśmy móc aktualizować też inne aplikacje z paczek, jak Polipo czy Vidalia.
By wykonać ten projekt, student będzie musiał najpierw poznać istniejące mechanizmy aktualizacji (np. Sparkle na OS X), by zbadać ich mocne i słabe punkty, cechy bezpieczeństwa i możliwości zintegrowania z Vidalią. Jeśli żaden nie okaże się przydatny, student zaprojektuje własny framework aktualizacyjny, udokumentuje projekt i przedyskutuje go z innymi deweloperami na temat jego bezpieczeństwa. Potem zaimplementuje go (lub zintegruje istniejący) i przetestuje.
Osoba podejmująca się tego projektu powinna dobrze znać C++. Uprzednie doświadczenie z Qt będzie przydatne, ale nie jest wymagane. Powinno się mieć też podstawowe pojęcie o powszechnych praktykach bezpieczeństwa, jak weryfikacja podpisu paczki. Dobre zdolności w pisaniu też są ważne w tym projekcie, gdyż ważnym krokiem będzie zrobienie dokumentacji projektu do przejrzenia i przedyskutowania z innymi ludźmi przed implementacją.
Poprawiona i bardziej użyteczna mapa sieci w programie Vidalia
Jedną z istniejących cech Vidalii jest mapa sieci, która pokazuje użytkownikowi przybliżone lokalizacje geograficzne przekaźników sieci Tora i rysuje ścieżki, przez które przechodzi ruch użytkownika w sieci Tora. Mapa jest w tej chwili niezbyt interaktywna i ma raczej słabą grafikę. Wolelibyśmy użyć widgetu Marble z KDE, który daje mapę lepszej jakości i umożliwia lepszą interaktywność, jak na przykład pozwalanie użytkownikowi na klikanie w poszczególne przekaźniki lub obwody, by wyświetlić dodatkowe informacje. Moglibyśmy też rozważyć dodanie możliwości klikania przez użytkownika na dany przekaźnik lub kraj z co najmniej jednym przekaźnikiem i stwierdzenia "chcę, by moje połączenia do foo.com wychodziły stąd."
Podczas tego projektu, osoba najpierw zapozna się z Vidalią i API widgetu Marble. Potem zintegruje widget z Vidalią i zmieni go, by bardziej pasował do naszych zastosowań, np. można było klikać w obwody, zapisywać mapy we własnym katalogu Vidalii i dostosować część okien dialogowych widgetu.
Osoba podejmująca się tego projektu powinna dobrze znać C++. Uprzednie doświadczenie z Qt i CMake będzie przydatne, ale nie jest wymagane.
Interfejs zdarzeń stanu kontrolera Tora
Jest pewna liczba zmian stanu, o których użytkownik powinien być może być informowany. Na przykład, jeśli użytkownik chce uruchomić przekaźnik sieci Tor, a Tor stwierdzi, że nie jest on osiągalny z zewnątrz, użytkownik powinien zostać o tym poinformowany. W tej chwili wszystko, co dostaje użytkownik, to kilka wiadomości w "dzienniku wiadomości" Vidalii, których pewnie nie zobaczy, gdyż nie dostaje informacji, że coś poszło nie tak. Nawet jeśli użytkownik spojrzy na zapis logów, większość wiadomości będzie miała mały sens dla początkującego.
Tor ma możliwość informowania Vidalii o wielu takich zmianach stanu, a ostatnio zaimplementowaliśmy obsługę kilku takich zdarzeń. Jednak jest wiele więcej zdarzeń, o których użytkownik powinien być informowany i potrzebujemy lepszego interfejsu użytkownika do wyświetlania takich wiadomości.
Celem tego projektu jest zaprojektowanie i zaimplementowanie interfejsu użytkownika do wyświetlania wiadomości o stanie Tora. Na przykład, można byłoby umieścić mały znaczek na ikonie Vidalii w zasobniku, który alarmowałby użytkownika o nowych zmianach stanu, którym powinien się przyjrzeć. Podwójne kliknięcie tej ikonki pokazywałoby okienko dialogowe podsumowujące ostatnie zmiany stanu prostymi słowami i może sugerujące rozwiązania do negatywnych wiadomości, jeśli mogą one być naprawione przez użytkownika. Oczywiście to tylko przykład i można zaproponować inne podejście.
Osoba podejmująca się tego projektu powinna dobrze znać projektowanie i tworzenie interfejsu użytkownika i mieć trochę doświadczenia z C++. Uprzednie doświadczenie z Qt i Qt Designer będzie przydatne, ale nie jest wymagane. Przydatne mogą być też pewne umiejętności w pisaniu po angielsku, gdyż ten projekt prawdopodobnie będzie wymagał napisania małej ilości dokumentacji pomocniczej, która powinna być zrozumiała dla nie-technicznych użytkowników. Dodatkowe punkty za jakiś projekt graficzny /Photoshop fu, gdyż moglibyśmy chcieć/potrzebować nowych ikonek.
Ulepszenia naszego aktywnego testera konfiguracji przeglądarek - https://check.torproject.org
Mamy w tej chwili funkcjonalną stronę www, która sprawdza, czy Tor działa. Ma jednak parę miejsc, w których działa źle. Wymaga ulepszeń dotyczących domyślnych języków i funkcjonalności. W chwili obecnej odpowiada tylko po angielsku. Ponadto, jest to kawał skryptu Perla, który nigdy nie powinien był ujrzeć światła dziennego. Strona powinna prawdopodobnie zostać przepisana w Pythonie z uwagą na wielojęzyczności. Teraz używa listy punktów wyjściowych Tor DNS i powinna to robić w przyszłości. Może to dawać fałszywe pozytywne wyniki - te powinny zostać wykryte, udokumentowane i naprawione, gdzie to będzie możliwe. Ktokolwiek pracujący nad tym projektem powinien interesować się DNS, znać podstawy Perla lub lepiej - Pythona. Będzie musiał tylko minimalnie stykać się z Torem, by testować swój kod.
Jeśli chcesz, by ten projekt był bardziej ekscytujący i zawierał więcej projektowania i programowania, przeczytaj propozycję 131-verify-tor-usage.txt.
Ulepszenia w naszej usłudze punktów wyjściowych Tora - DNS Exit List - http://exitlist.torproject.org
Oprogramowanie to zostało napisane przez naszego wspaniałego wolontariusza - Tup. Jest to serwer DNS napisany w języku Haskell, obsługujące część naszego dokumentu projektowania listy punktów wyjściowych. W chwili obecnej, usługa jest funkcjonalna i używana przez check.torproject.org i innych użytkowników. Sprawy, które zostały do zrobienia to głównie estetyka. Tej wspaniałej usłudze przydałaby się o wiele lepsza strona z motywem wspólnym dla stron Tora. Lepiej by wyglądała z lepszą dokumentacją częstych usług korzystających z RBL. Przydałby się rozgłos. Osoba pracująca nad tym projektem powinna interesować się DNS, podstawową konfiguracją RBL dla popularnych usług i pisaniem dokumentacji. Osoba ta wymagałaby tylko minimalnego stykania się z Torem — co najmniej podczas testowania własnej dokumentacji. Ponadto, byłoby dobrze, gdyby interesowała się Haskellem i chciała zaimplementować więcej z sugestii w dokumencie torel-design.txt.
Testowanie integracji Tora z przeglądarkami dla użytkowników końcowych
Projektowi Tor brakuje obecnie solidnego testu do upewnienia się, że użytkownik poprawnie skonfigurował przeglądarkę. Taki test powinien sprawdzać tyle elementów, ile się da. Powinien spróbować zdjąć ukrycie użytkownika na każdy możliwy sposób. Dwie aktualne strony śledzące takie sprawy są prowadzone przez Grega i HD Moore'a. Greg trzyma ładną listę problemów wraz z dowodami jak ich użyć oraz listę błędów itp.. HD Moore prowadzi stronę metasploit decloak. Osoba zainteresowana obroną Tora mogłaby zacząć od zbierania jak największej liczby działających i znanych metod odkrywania użytkownika Tora. (Ta strona może być pomocna na początek.) Powinno się znać częste pułapki, ale też myśleć o nowych metodach "zdejmowania" osłony użytkowników. Strona powinna informować użytkownika, w czym ma problem. Powinna pomóc mu w naprawieniu problemu lub skierować go na właściwe kanały wsparcia. Osoba wykonująca powinna dobrze znać Tora i to, jak zapobiegać wyciekom.
Lepsza integracja Tora i Libevent
Tor powinien lepiej używać nowych cech biblioteki Libevent Nielsa Provosa. Tor już używa Libevent do niskopoziomowych funkcji wejścia/wyjścia i mógłby użyć coraz lepszych implementacji buforów sieciowych i HTTP. Nie byłaby to po prostu kwestia zastąpienia wewnętrznych funkcji Tor wywołaniami funkcji z Libevent - zamiast tego musimy zmienić Tora, by używał wywołań Libevent, które nie trzymają się modelu istniejących funkcji. Ponadto, będzie trzeba dodać pewne funkcjonalności do Libevent, jeśli będzie trzeba — prawdopodobnie najtrudniejsze będzie dodanie obsługi OpenSSL na abstrakcje buforów w Libevent. Niełatwe również będzie dodanie ograniczanie transferu do Libevent.
Tuneup Tor!
W chwili obecnej węzły Tora mierzą i zgłaszają własną przepustowość łącza, a klienci Tora wybierają, których węzłów używać po części opierając się na tej zgłaszanej przepustowości. To podejście jest podatne na ataki, w których węzły oszukują na temat przepustowości swoich łączy; by to zmienić, Tor aktualnie ogranicza maksymalną przepustowość każdego węzła, w którą jest w stanie uwierzyć. To jest ograniczone rozwiązanie i marnotrawienie przepustowości. Zamiast tego, Tor powinien w miarę możliwości mierzyć przepustowość łączą w rozproszony sposób, jak jest napisane w dokumencie "A Tuneup for Tor" autorstwa Snadera i Borisova. Można byłoby użyć bieżącego kodu testującego, by sprawdzić odkrycia napisane w tym dokumencie i zweryfikować, w jakim stopniu opisują one normalnie działającego Tora i określić dobre sposoby na wcielenie tych odkryć do sieci Tora bez dodawania niepożądanego ruchu wielkości między węzłami a serwerami katalogowymi.
Polepszenie procesu testów jednostkowych
Tor musi zostać znaczniej bardziej przetestowany. To jest projekt wieloczęściowy. Na początek, nasze testy jednostkowe powinny znacznie się wzbogacić, zwłaszcza w obszarach poza funkcjami narzędziowymi. Będzie to wymagało poważnych zmian niektórych części Tora, aby oddzielić jak najwięcej programu od zmiennych globalnych.
Ponadto, musimy zautomatyzować nasze testy wydajności dla wszystkich systemów. Mamy już buildbota do automatyzacji naszej zwyczajnej integracji i kompilacji testów (ale potrzebujemy osoby do uruchomienia tego pod Windows), ale musimy zaktualizować nasze testy symulacji sieci (takie, jak w TorFlow: spójrz na punkt "Ulepszenie Skanera Węzłów Tora") do nowszych wersji Tora i zaprojektować je tak, by uruchamiać sieci testowe albo na jednej maszynie, albo na kilku, abyśmy mogli automatycznie badać zmiany wydajności na maszynach pełniących różne zadania.
Pomóż wznowić niezależną implementację klienta Tora
Reanimuj jedno z podejść do implementacji klienta Tora w Javie, np. projekt OnionCoffee i spraw, by działał pod Androidem. Pierwszym krokiem byłoby przeniesienie istniejącego kodu i uruchomienie go w środowisku Android. Potem kod powinien zostać zaktualizowany, by obsługiwać nowsze wersje protokołu Tora, jak na przykład protokół katalogowy w wersji 3. Poza tym, obsługa żądań lub choćby dostarczania usług ukrytych Tora byłaby fajna, choć nie wymagana.
Perspektywiczny deweloper powinien rozumieć i umieć pisać nowy kod w Javie, łącznie z korzystaniem z kryptograficznego API Javy. Umiejętność czytania kodu w C też byłaby przydatna. Powinno się mieć chęć do czytania istniejącej dokumentacji, implementacji kodu w oparciu o nią oraz, jeśli będzie to potrzebne, poprawiać dokumentację, jeśli jest niejasna. Ten projekt składa się w dużym stopniu z pisania kodu i w mniejszym - z projektowania.
Ożywienie projektu moniTor
Zaimplementuj narzędzie podobne do top dla przekaźników siei Tora. Celem takiego narzędzia byłoby monitorowanie lokalnego przekaźnika sieci poprzez jego port kontrolny i dołączanie użytecznych informacji systemowych samej maszyny. Podczas działania, narzędzie to dynamicznie aktualizowałoby swoje informacje, tak jak program top robi to dla procesów linuksowych. Ta wiadomość na or-dev może być dobrą lekturą na początek.
Obsoba powinna znać lub być chętną do nauki administrowania przekaźnikiem Tora i konfigurowania go za pomocą portu kontroli. Jako że wstępny prototyp jest napisany w Pythonie, pewna wiedza na temat pisania programów w tym języku też byłaby przydatna. Ten projekt z jednej strony opiera się na określeniu wymagań dla takiego narzędzia i zaprojektowania dla niego interfejsu, a z drugiej strony wymaga również dużo programowania.
Ulepszenia w Torbutton
Jest parę ulepszeń, które można byłoby wprowadzić do Torbutton w wersji po 1.2. Większość z nich jest pisana jako prośby o ulepszenia w sekcji flyspray Torbuttona. Dobrymi przykładami są: wycinanie node.exit z nagłówków HTTP, lepsza kontrola blokowania wypełniania formularzy, ulepszone imitowanie odnośników do stron poprzednich (tzw. referrers) w oparciu o domenę strony (coś jak rozszerzenie refcontrol), bliższa integracja z Vidalią do zgłaszania stanu Tora, przycisk Nowa Tożsamość z integracją z Torem i zarządzanie wieloma tożsamościami, i cokolwiek jeszcze, co zdołasz wymyślić.
To zadanie składałoby się z niezależnego pisania w JavaScripcie i miłym świecie XUL, bez zbytniego zagłębiania się do wnętrzności Tora.
Przeniesienie Polipo na Windows
Pomóż przenieść Polipo na Windows. 1) obsługa spacji w ścieżkach i zrozumienie przestrzeni nazw systemu plików — przestrzeń nazw tu oznacza gdzie dane aplikacji, dane osobiste i program zwykle się znajdują w różnych wersjach Windows. 2) zdolność obsługi połączeń przez IPv6. 3) zdolność do asynchronicznego wysyłania zapytań do serwerów nazw. 4) używanie natywnych zdolności Windows odnośnie wyrażeń regularnych zamiast używania bibliotek GNU. 5) natywna obsługa zdarzeń i buforów (tj. w systemach uniksopodobnych Polipo domyślnie używa 25% pamięci RAM, a pod Windows jest to cokolwiek wpisane w plik konfiguracyjny). 6) jakieś narzędzie z graficznym interfejsem do konfiguracji i raportowania, dodatkowe punkty, jeśli ma ikonkę w zasobniku z opcjami menu po kliknięciu prawym przyciskiem myszy. Podwójny bonus, jeśli działa na wielu platformach.
Zrobienie naszych diagramów pięknymi i zautomatyzowanymi
Potrzebujemy sposobu na generowanie diagramów na stronie (na przykład, obrazków "Jak działa Tor" na stronie wprowadzenia ze źródeł, byśmy mogli je tłumaczyć jako tekst w UTF-8 zamiast edytować je ręcznie za pomocą GIMPa. Należy zintegrować to z plikiem WML, by tłumaczenie było proste, a obrazki generowane w wielu językach w czasie publikacji strony.
Ulepszenie oferty LiveCD dla społeczeństwa Tora
Jak można uczynić Incognito LiveCD łatwiejszym w utrzymaniu, ulepszaniu i dokumentowaniu?
Zmiana i rozszerzenie Blossom
Należy zmienić i rozszerzyć Blossom (narzędzie do monitorowania i wybierania właściwych obwodów Tora w oparciu o wymagania co do węzła wyjściowego podane przez użytkownika) do zbierania danych własnym sposobem, z łatwymi do zmiany przez użytkownika parametrami. Blossom jest aktualnie zaimplementowany jako pojedynczy skrypt Pythona, który łączy się z Torem używając interfejsu Kontrolera i opiera się na danych zbieranych o węzłach Tora przez zewnętrzne procesy takiej jak strona www pokazująca status węzłów wraz z publicznymi danymi z DNSów, whois itp. Ten projekt ma 2 części: (1) Określenie, jakie jeszcze dane mogą być potrzebne i przerobić Blossom tak, by sam zbierał dane zamiast polegać na zewnętrznych skryptach (to może, oczywiście, wprowadzić dodatkowe wątki i komunikację międzyprocesową) i (2) stworzenie metody łatwej konfiguracji Blossom przez użytkownika, zaczynając od pliku konfiguracyjnego i być może kończąc na konfiguracji przez przeglądarkę. Ważna jest znajomość Tora i Pythona; znajomość TCP, komunikacji międzyprocesowej i Perla też może się przydać. Zainteresowanie neutralnością sieci też jest ważne, gdyż zasady ewolucji i zrozumienie niespójności Internetu są podstawą projektu Blossom.
Ulepszenie Blossom: pozwolenie użytkownikom na jakościowy opis węzłów wyjściowych, z których chcą korzystać
Należy zaprojektować i zaimplementować możliwość dania użytkownikom programu Blossom opisania węzła wyjściowego, z którego chcą korzystać. Internet jest niespójnym miejscem: niektóre węzły wyjściowe Tora widzą świat inaczej niż inne. W bieżącej implementacji Blossom (narzędzie do monitorowania i wybierania właściwych obwodów Tora w oparciu o wymagania co do węzła wyjściowego podane przez użytkownika) nie ma dość bogatego języka, by opisać, jak bardzo różne są różne punkty widzenia. Na przykład, niektóre węzły wyjściowe mogą być w sieciach filtrujących pewne rodzaje ruchu lub strony. Inne węzły mogą dawać dostęp do specjalnej zawartości w związku ze swoją lokalizacją, być może jako rezultat dyskryminacji ze strony samych dostawców treści. Ten projekt składa się z 2 części: (1) stworzenie języka do opisywania charakterystyk sieci, w której znajdują się węzły, oraz (2) wprowadzenie tego języka do Blossom, by użytkownicy mogli wybierać ścieżki Tora w oparciu o ten opis. Ważna jest znajomość Tora i Pythona; znajomość TCP, komunikacji międzyprocesowej i Perla też może się przydać. Zainteresowanie neutralnością sieci też jest ważne, gdyż zasady ewolucji i zrozumienie niespójności Internetu są podstawą projektu Blossom.
Przynieś nowe pomysły!
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ć.

Inne pomysły związane z programowaniem i projektowaniem

Przekaźniki sieci 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. Znaczy to, że średnich rozmiarów przekaźnik sieci Tora zapełni dostępną przestrzeń, 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. Christian King zrobił pierwszy dobry krok lata roku 2007.
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ę.
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.

Badania

"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?
Powiązane pytanie brzmi: Czy prowadzenie przekaźnika/mostka daje dodatkową ochronę przed atakami opartymi na czasie? Czy ktoś z zewnątrz, kto nie może przeczytać linków zaszyfrowanych przez TLS, dalej jest w stanie prawidłowo rozpoznać poszczególne strumienie danych? Czy ilość ruchu jakoś zmniejsza tę możliwość? A co, jeśli klient-przekaźnik celowo opóźnia wychodzący ruch, by stworzyć kolejkę, która mogłaby być używana do udawania czasów pobierania danych przez klienta tak, by wyglądało, że ten ruch też jest przekierowany? Ta sama kolejka mogłaby być używana do maskowania czasów w ruchu wychodzącym, korzystając z technik adaptacyjnego dopełniania, ale bez potrzeby dodatkowego ruchu (wysyłania dodatkowych danych). Czy takie przeplatanie prawdziwych danych popsułoby mierzenie czasów u atakujących? Czy strategie te musiałyby by zmienione dla asymetrycznych łączy? Na przykład, czy jest możliwe na łączu asymetrycznym odróżnienie ruchu klienta od naturalnego wzmożenia ruchu ze względu na ich asymetryczną pojemność? Czy jest to jednak łatwiejsze niż dla łączy symetrycznych z innych przyczyn?
Powtórzcie atak z Oakland 05 Murdocha i Danezisa na bieżącej sieci Tora. Sprawdźcie, czy możecie dowiedzieć się, czemu działa on dobrze na niektórych węzłach, a gorzej na innych. (Moja teoria mówi, że szybkie węzły mające trochę wolnego pasma lepiej opierają się atakowi.) Jeśli to prawda, poeksperymentujcie z opcjami RelayBandwidthRate i RelayBandwidthBurst prowadząc węzeł używany jako klient do przekierowywania ruchu atakującego: jeśli zmniejszamy RelayBandwidthRate, czy atak jest trudniejszy? Jaki jest najwłaściwszy stosunek RelayBandwidthRate do rzeczywistej szybkości łącza? Czy to w ogóle jest jakiś stosunek? Skoro już przy tym jesteśmy, czy znacznie większy zbiór węzłów kandydujących zwiększa odsetek fałszywych wyników pozytywnych lub innych trudności dla tego rodzaju ataku? (Sieć Tora jest teraz większa o prawie dwa rzędy wielkości niż wtedy, gdy napisano ten dokument.) Przeczytaj też Nie zapychaj kolejki.
"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 przekaźnik sieci ma 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.
Nasze cele w opieraniu się cenzurze to m.in. zapobieganie temu, by napastnik podglądający ruch Tora mógł odróżnić go od normalnego ruchu SSL. Oczywiście, nie możemy osiągnąć idealnej steganografii i dalej mieć użyteczną i działającą sieć, ale w pierwszym kroku chcielibyśmy blokować jakiekolwiek ataki, które mogą się udać po obserwacji tylko kilku pakietów. Jednym z pozostałych ataków, którego nie zbadaliśmy za bardzo, polega na tym, że komórki Tora mają 512 bajtów, więc ruch w sieci może mieć długość będącą wielokrotnością 512 bajtów. Jak bardzo wkładanie nowych danych w nagłówkach TLS rozmywa ten fakt w transmisji? Czy inne strategie opróżniania bufora w Torze mają na to wpływ? Czy trochę dokładania może bardzo pomóc, czy jest o atak, z którym musimy żyć?
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 przekaźnik sieci 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 przekaźniki sieci Tora lub centra 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.
Programy takie jak Torbutton mają na celu ukrycie pola UserAgent przeglądarki, zastępując je jednakową odpowiedzią dla każdego użytkownika Tora. W ten sposób napastnik nie może złamać anonimowości Tora, patrząc na ten nagłówek. Aby się nie wyróżniać, program próbuje wybrać nazwy przeglądarek często używanych także przez tych, którzy nie używają Tora. Pytanie numer jeden: jak bardzo szkodzimy sami sobie, okresowo zwiększając wersję Firefoksa, za którego podaje się Torbutton? Jeśli aktualizujemy zbyt często, sami łamiemy swoją anonimowość. Jeśli za rzadko, to wszyscy użytkownicy Tora się wyróżniają ze względu na to, że twierdzą, iż używają starych wersji Firefoksa. Tutaj odpowiedź zależy pewnie na tym, które wersje Firefoksa są spotykane. Pytanie numer dwa: raz na jakiś czas ludzie pytają nas, byśmy krążyli po N nazwach UserAgent, zamiast trzymać się jednej. Czy to podejście pomaga, przeszkadza, czy nic nie wnosi? Weź pod uwagę: ciaseczka i rozpoznawanie użytkowników Tora poprzez ich zmieniające się nagłówki UserAgent, złe strony atakujące tylko określone przeglądarki; oraz to, czy odpowiedź na pytanie 1 wpływa na tę odpowiedź.
W chwili obecnej klienci Tora mogą używać tego samego obwodu w ciągu dziesięciu minut od jego pierwszego użycia. Celem tego jest uniknięcie przeładowania sieci zbyt wielką liczbą operacji przedłużania obwodów, równocześnie unikając używania obwodu tak długo, że węzeł wyjściowy mógłby stworzyć przydatny profil pseudonimowy użytkownika. Dziesięć minut to jednak prawdopodobnie znacznie za dużo, zwłaszcza gy przez ten sam obwód prowadzone sa połączenia różnych protokołów (np. IM i przeglądanie sieci). Jeśli nie zmienimy całkowitej liczby obwodów, które należy utrzymywać, to czy będą jakieś wydajniejsze lub bezpieczniejsze metody alokcaji strumieni do obwodów, lub do tworzenia wywłaszczających obwodów? Być może ten temat badań powinien być rozpoczęty poprzez zebranie śladów, jakie połączenia typowy użytkownik otwiera, by mieć coś realistycznego do optymalizacji.
Ile przekaźników mostkowych potrzeba, by utrzymać osiągalność? Powinniśmy zmierzyć zajętość w naszych mostkach. Jeśli jest duża, czy są jakieś sposoby na zwiększenie szans użytkowników mostków na pozostanie połączonymi?

Daj nam znać, jeśli poczyniłeś postępy nad którąkolwiek z tych rzeczy!