Projekt NLnet: Tor dla klientów o wolnym łączu
System Tor jest w tej chwili najbardziej nadający się do używania dla ludzi mających połączenie z Internetem o dużej przepustowości. W czasie uruchamiania klienta Tora pobierany jest ogromny plik z opisem wszystkich serwerów Tora. Ten plik to tak zwany Katalog Tora i umożliwia on klientowi wybieranie spośród serwerów w sieci Tora. Pobieranie całego katalogu jest wymagane w bieżącej wersji protokołu Tora. Ten plik z katalogiem jest zbyt duży dla użytkowników z modemami lub będącymi w sieciach mobilnych jak GPRS, jako że wstępne pobieranie uruchamiane przy każdym logowaniu użytkownika trwa od 10 do 30 minut na wolnym połączeniu. W wyniku tego, Tor nie jest zdatny do używania przez użytkowników modemów lub sieci mobilnych. Jednym z głównych celów Tora jest dostarczanie bezpiecznego anonimowego Internetu użytkownikom w krajach z dyktaturą lub represjami. Takie miejsca często mają wolne połączenia internetowe, przez modem albo niskiej przepustowości łącza do świata zewnętrznego. Poprzez umożliwienie tym użytkownikom używania sieci Tora można uczynić znaczny postęp w kierunku swobodnej komunikacji i informacji w tych krajach.
By Tor nadawał się do użycia na wolnych łączach, potrzebny jest rozwój protokołu Tora, by zmniejszyć rozmiar wstępnego pobierania. Nowa wersja protokołu Tora powinna zmienić sposób, w jaki klient otrzymuje informacje do stworzenia obwodu tak, by pierwsze pobieranie mogło być wykonane na linii modemowej 14.4k w czasie około trzech minut. Celem prac w tym projekcie jest umożliwienie wprowadzenia zmian w protokole i rozprowadzenia ich wśród użytkowników Tora w przeciągu 12 miesięcy. Stworzone oprogramowanie zostanie wydane na 3-punktowej licencji BSD, jak cały kod Tora. Wszystkie części będą całkowicie publiczne.
Ten projekt jest hojnie sponsorowany przez:
| Projekt | Czas zakończenia |
|---|---|
|
Część A: Projektowanie i sprawdzanie zmian protokołu W tej części zawarty jest szczegółowy projekt i oparte na symulacjach sprawdzenie niezbędnych zmian i modyfikacji projektu bieżącego protokołu Tora. Zmiany w protokole będą raczej istotne, więc wymaga to dokładnego sprawdzenia wszystkich możliwych skutków dla bezpieczeństwa i anonimowości sieci Tora. Dla tej fazy projektowania i sprawdzania przewidziany jest dwumiesięczny okres, zakończony wyczerpującą recenzją. Celem tej części jest m.in. zdefiniowanie wydajności do osiągnięcia w fazie implementacji. Celem projektowym jest zmniejszenie pobieranego rozmiaru Katalogu Tora do około 300 kilobajtów, co umożliwiłoby użytkownikowi łącza 14.4 kbps pobranie go w ciągu około trzech minut. Mogą być odstępstwa od tego celu, jeśli będą wymagane do zachowania bezpieczeństwa i anonimowości, ale to jest obszar, w który należy celować. |
15 Lipca 2008 |
|
Część B:Implementacja zmiany protokołu Po projekcie, sprawdzeniu i przeglądzie, zmiany muszą zostać zaimplementowane i zintegrowane z bieżącym kodem Tora. Sama implementacja niezbędnych zmian zajmie około trzech miesięcy. |
15 Października 2008 |
|
Część C:Testowanie Zmiana jest bardzo ważna dla bezpieczeństwa i anonimowości sieci Tora, wymaga więc dogłębnego testowania i szukania błędów w warunkach laboratoryjnych i rzeczywistych. Okres trzech miesięcy jest przewidziany na testowanie i usuwanie błędów, podczas którego odpowiedzialny za to programista poświęci 1/3 swojego czasu na testowanie. Część fazy testowania będzie okresem publicznej wersji beta. |
15 Stycznia 2008 |
|
Część D:Wypuszczenie Wypuszczenie zmian do sieci serwerów Tora będzie zsynchronizowane z regularnymi wydaniami Tora. Jako że regularne wydania zależą od wielu czynników zewnętrznych, jak zakończenie innych projektów, które powinny wyjść w tym samym wydaniu, właściwy czas wydania i instalacji u większości operatorów serwerów Tora może być różny. Z doświadczenia wiemy, że można oczekiwać okresu od trzech do czterech miesięcy. Wydanie będzie przeprowadzone jako część regularnego procesu wydawania Tora, który jest działaniem wykonywanym przez wolontariuszy i personel wynagradzany z innych grantów przeznaczonych na projekt Tor. |
15 Kwietnia 2009 |
Miesięczne raporty o bieżącym stanie
Łącznie będzie osiem miesięcznych raportów zaczynających się od pierwszej części 15. czerwca 2008 i kończących się na ukończeniu implementacji i testów 15. stycznia 2009.
| Miesiąc, | Raport o stanie |
|---|---|
| Czerwiec 08 |
Przeprowadziliśmy trochę wstępnych badan uruchamiania się klienta Tora.
Wyniki nie są zbyt zadziwiające: klient pobiera około 10kB certyfikatów, jeden
konsensus rozmiaru 140kB (teraz 90kB, zobacz kolejny paragraf) i około 1,5MB
deskryptorów serwerów (po pobraniu połowy zaczyna budować obwody).
Propozycja 138 zmniejsza rozmiar konsensusu od 30% do 40% i została już zaimplementowana i połączona ze specyfikacją. Implementacja jest częścią drzewa 0.2.1.x-alpha i odniesie skutek, gdy ponad dwie trzecie serwerów katalogowych (czyli 5 z 6) zainstalują nową wersję. Propozycja 140 nie jest bezpośrednio związana ze zmniejszeniem rozmiaru wstępnego pobierania, zamiast tego próbuje zmniejszyć kolejne pobierania dokumentów konsensusu i została wysłana na or-dev. Najpierw jest jeszcze kilka pytań wymagających odpowiedzi od innych deweloperów Tora, ale poza tym propozycja wydaje się być dobra i może być implementowana. Wielką Sprawą jest sprawienie, by klienci nie pobierali całych 1,5MB deskryptorów serwerów. Propozycja 141 została wysłana na or-dev. Składa się w chwili bieżącej z 3 podstawowych rzeczy: przenieść informacje o równowadze wykorzystania łącza do konsensusu (nie powinno być trudne), zaimplementować coś, co pozwoli klientom Tora pobieranie deskryptorów na żądanie od routerów na ich obwodzie w czasie jesgo budowania (opisane w szkicu), zabrać się za wybór punktu wyjścia. Ciągle tworzymy pomysły odnośnie ostatniej części; niektóre możliwości są wspomniane w szkicu. |
| Lipiec 08 |
Praca nad Propozycją
141 trwa: Są dwa podstawowe pomysły na to, jak przenieść informacje o
równowadze wykorzystania łącza do konsensusu: jeden pomysł mówi, że centra
katalogowe generują wagi, których klienci powinni używać i umieszczają to w
konsensusie, drugi jest taki, by po prostu umieścić w nim informacje o łączu
z deskryptora serwera. Ta druga opcja jest prawdopodobnie lepsza, gdy weźmie się
też pod uwagę Propozycję
140, gdyż unika to dużej ilości często zmieniających się liczb w konsensusie.
Odnośnie polityk wyjścia, list na liście mailingowej or-dev sugeruje dodanie hasza identyfikującego politykę wyjścia węzła do dokumentu konsensusu. Dodanie kolejnych 160 bitów o wysokiej entropii na każdy węzeł może budzić niepokój, ale naszym zdaniem wiele polityk wyjścia jest takich samych, więc dokument konsensusu powinien dobrze się kompresować. Pomiary trwają. |
| Sierpień 08 | Dokumenty głosowania serwerów katalogowych i ich algorytm tworzenia dokumentów konsensusu zostały zmienione, by uwzględniać informacje o przepustowości łącza i podsumowania polityk, według Propozycji 141. Gdy już pięć z sześciu działających centrów katalogowych zaktualizują się do wersji SVN co najmniej 16554, dokumenty konsensusu zaczną zawierać te informacje. |
| Wrzesień 08 | |
| Październik 08 | |
| Listopad 08 | |
| Grudzień 08 | |
| Styczeń 09 |