Projekt NLnet: Przyspieszenie usług ukrytych Tora

Usługi ukryte Tora pozwalają użytkownikom na zakładanie anonimowych serwisów informacyjnych, np. stron internetowych, które są dostępne tylko przez sieć Tora i są chronione przed identyfikacją komputera, na którym takie usługi są uruchomione. Najważniejsze ograniczenia usług ukrytych są: czas potrzebny na rejestrację usługi ukrytej w sieci i czas potrzebny na nawiązanie połączenia przez użytkownika. Z powodu spraw projektowych w oryginalnym protokole Tora połączenie z usługą ukrytą może trwać kilka minut, przez co większość użytkowników rezygnuje przed nawiązaniem połączenia. Używanie usług ukrytych do bezpośredniej interaktywnej komunikacji między użytkownikami (np. przesyłanie wiadomości) jest niemal niemożliwe z powodu długiego czasu tworzenia obwodu do usługi ukrytej.

Celem tego projektu jest przyspieszenie usług ukrytych Tora poprzez usprawnienie metody tworzenia obwodów między użytkownikiem a usługą, jak również sposobu, w jaki usługa jest rejestrowana w sieci. W pierwszym kroku poprowadzone będą dokładne pomiary zachowania usług ukrytych w warunkach laboratoryjnych i rzeczywistych, by znaleźć główne przyczyny opóźnień. Opierając się na wynikach pomiarów, zaprojektowane i zweryfikowane będą strategie optymalizacji niechcianych implikacji związanymi z bezpieczeństwem i anonimowością sieci Tora. Najbardziej obiecujące optymalizacje zostaną zaimplementowane, by dać użytkownikom widoczny efekt. Dokładne pomiary sukcesu zostaną stworzone w fazie diagnostyki, gdy już będzie jasne, gdzie tracony jest czas i jakie ulepszenia są możliwe. Ostatecznym celem jest umożliwienie wprowadzenia zmian w protokole usług ukrytych i rozprowadzenia ich wśród użytkowników Tora w przeciągu 12 miesięcy.

Ten projekt jest hojnie sponsorowany przez:

Projekt	Czas zakończenia
Część A: Analiza, pomiary i klaryfikacja problemu Jako że usługi ukryte Tora nie były aktywnie rozwijane przez około ostatni rok rozwoju Tora, niektóre aspekty tych problemów są nie do końca zbadane. Należy przeprowadzić dogłębną analizę przyczyn strat czasu, by znaleźć ich dokładne źródła. Część A będzie wymagać około miesiąca pracy. Wyniki analizy wpłyną na decyzje projektowe, które zostaną podjęte w Części B.	15 Czerwca 2008
Część B: Projektowanie i sprawdzanie niezbędnych zmian Zmiany w usługach ukrytych wpłyną na podstawy funkcjonowania protokołu i dlatego wymagają dokładnego sprawdzenia możliwych skutków dla bezpieczeństwa i anonimowości. Na projekt i sprawdzanie przewidziany jest dwumiesięczny okres, zakończony wyczerpującą recenzją.	15 Sierpnia 2008
Część C: Implementacja 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 dwóch miesięcy.	15 Października 2008
Część D: Implementacja i testowanie aż do wydania 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 2009
Część E: 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.	15 Maja 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	Pierwotny cel analizy problemu, który prowadził do spowolnienia usług ukrytych, został osiągnięty. Częścią tej analizy był pomiar opóźnienia doświadczanego przez użytkownika podczas tworzenia lub łączenia się z usługą. Ponadto, dane z kwietnia 2008 mogą zostać użyte do badania czasu wykonania wewnętrznych kroków nawiązywania połączenia z usługą ukrytą. Wyniki analizy zawarte są w 22-stronicowym raporcie upublicznionym na liście mailingowej deweloperów Tora. Analiza odkryła także kilka błędów odpowiedzialnych za część opóźnienia w udostępnianiu usługi ukrytej klientom. Kilka błędów zostało poprawionych po analizie, inne będą poprawione wkrótce. Badanie ukazało kilka możliwych podejść do polepszenia wydajności usług ukrytych. Część z tych pomysłów może zostać zastosowana natychmiast, inne wymagają głębszej analizy i nowych pomiarów. W trakcie analizy odkryliśmy, że część usprawnień wymaga głębszych zmian w Torze, które nie są bezpośrednio związane z usługami ukrytymi. Zmian tych nie da się osiągnąć w czasie przeznaczonym na ten projekt.
Lipiec 08	Wszystkie błędy znalezione w analizie zostały naprawione, łącznie z 2 błędami naprawionymi w czasie analizy i jeszcze 4 znalezionymi w ciągu ostatnich 30 dni. Podczas gdy usunięcie błędów usunęło niechciane wąskie gardła wydajności związane z błędami w programowaniu, część zmian projektowych zauważonych w poprzedniej analizie ma efekty uboczne na anonimowości lub sumarycznym obciążeniu sieci. Efekty te muszą zostać zanalizowane w odniesieniu do poszczególnych celów wydajnościowych. Raport został wydany na listę mailingową deweloperów, zawiera on 7 możliwych zmian projektu, które muszą zostać przedyskutowane. Okazało się, że część badań (pomiary wolnego łącza i wielki plan skalowania) zajmie więcej czasu, niż się spodziewano, więc zostały przełożonych na dalszą przyszłość niż część B. Bieżący plan zakłada przeprowadzenie tych badań do 15. stycznia i pracę z założeniami do czasu, gdy dostępne będą końcowe wyniki.
Sierpień 08	W przeciągu ostatnich 30 dni 7 zaproponowanych projektów zostało dalej rozpatrzonych i omówionych. Cztery z nich okazały się możliwe do zastosowania, biorąc pod uwagę wymagane zmiany kodu i możliwe implikacje na anonimowość. Jeden został zakwalifikowany jako błąd, a nie zmiana projektu. Dwa musiały zostać wykluczone ze względów albo nieprzewidywalnych problemów z anonimowością albo niepewnością co do zysków wydajności. Łącznie z wynikami z 15. licpa, faza projektowania została zakończona. Zadania dla zbliżającej się fazy implementacji są teraz całkiem jasne: należy usunąć jeden błąd i zaimplementować cztery zmiany projektowe. Ponadto, należy przeprowadzić badania zmienionego projektu, by sprawdzić jego przydatność. Raport z wynikami fazy projektowej został wydany na listę mailingową deweloperów.
Wrzesień 08	W czasie pierwszej połowy fazy implementacji naprawiono dwa błędy związane z usługami ukrytymi: pierwszy błąd został odkryty w już fazie projektowania i był odpowiedzialny za wysoki odsetek niepowodzeń w czasie udostępniania usługi ukrytej w systemie; drugi błąd został znaleziony w fazie implementacji i był odpowiedzialny za nieudane połączenia do działającej usługi ukrytej. Obie poprawki będą dołączone do najbliższej wersji niestabilnej i prawdopodobnie przeniesione do jednej z następnych wersji stabilnych. Cztery zmiany projektu, które zostały zaproponowane jako wynik fazy projektowania, zostały zaimplementowane w eksperymentalnej gałęzi drzewa rozwojowego wersji niestabilnej. Pierwsze testy funkcjonalne pokazały, że te zmiany działają i dają lepsze (widoczne) osiągi. To musi być potwierdzone przez następne cztery tygodnie testów wewnętrznych. Kolejnym celem jest przygotowanie wydania tej eksperymentalnej gałęzi, które można byłoby dać beta-testerom na początku zbliżającej się fazy testów.
Październik 08	Faza implementacji została zakończona. Poprawki błędów znalezionych w ciągu ostatnich 30 dni zostały wydane w wersji rozwojowej 0.2.1.6-alpha. Cztery zmiany projektu określone w fazie projektowania zostały zapisane w propozycji 155. Trzy zmiany projektu zostały umieszczone w kodzie rozwojowym i będą automatycznie dołączone w następnej wersji rozwojowej. Pierwsze dwie zmiany poprawiają nawiązywanie połączenia do usługi ukrytej, zmniejszając okres czasu z 60 do 30 sekund oraz poprzez wykonanie drugiej próby równolegle po 15 sekundach. Trzecia zmiana wpływa na ogłaszanie usługi ukrytej w sieci, poprzez przedstawianie usługi w 5 zamiast w 3 punktach równolegle, a nawiązanie 3 połączeń wystarczy do pomyślnego zakończenia operacji. Czwarta zmiana okazała się być dość mało wydajna, za to zwiększyłaby znacznie złożoność kodu, więc została porzucona. W tej chwili nie ma już znanych błędów ani nowych projektów. wszystkie zmiany są w kodzie rozwojowym i mogą być testowane w następnej fazie.
Listopad 08	Usprawnienia zaimplementowane w poprzedniej fazie zostały wydane w wersji Tora 0.2.1.7-alpha. Użytkownicy mogą pobrać tę wersję rozwojową ze strony Tora i sprawdzić usprawnienia minimalnym wysiłkiem. Ponadto, dwie poprawki błędów (1, 2), które znaleziono w trakcie projektu, zostały przeniesione też do gałęzi stabilnej i będą dołączone w najbliższej stabilnej wersji 0.2.0.32. Głównym celem ostatnich 31 dni było przeprowadzenie nowych pomiarów, by sprawdzić, czy nowe usprawnienia są efektywne, czy nie. Pomiary były prowadzone przez dwa dni, od 6. listopada do 8. listopada. Niestety, sieć Tora miała wtedy poważny problem: przedawniony certyfikat centrum katalogowego spowodował olbrzymi ruch w sieci Tor, który zmusił wielu operatorów do wyłączenia swoich przekaźników. Drugi pomiar został przeprowadzony między 13. a 15. listopada. Surowe dane są dostępne tutaj (40 MB). Ale wyniki pokazują, że całkowita wydajność sieci jest dalej gorsza niż w Czerwcu 2008, gdy dokonano pierwszych pomiarów usług ukrytych. Widać to, gdy porównuje się żądania do serwerów katalogowych Tora, na które nie wpłynęły usprawnienia i które pokazują znacznie gorszą wydajność niż przedtem. Efekty polepszenia wydajności są widoczne, ale wartości bezwzględne nie są w tej chwili porównywalne. Nowe pomiary zostaną przeprowadzone w grudniu z nadzieją, że efekty tego problemu zostaną złagodzone. Ponadto, może istnieć błąd w metodzie, której używa Tor do pobierania informacji katalogowych w czasie startu. Mimo iż nie jest to powiązane z usługami ukrytymi, polepszenie w tej kwestii poprawiłoby też publikację usług ukrytych. Część pracy w ciągu najbliższych 30 dni będzie poświęcona na zbadanie tego błędu.
Grudzień 08
Styczeń 09

Linki

Dokument badań Performance Measurements and Statistics of Tor Hidden Services ("Pomiary wydajności i statystyki usług ukrytych Tora") (PDF) napisali: Karsten Loesing, Werner Sandmann, Christian Wilms, i Guido Wirtz. We Wstępie do 2008 International Symposium on Applications and the Internet (SAINT), Turku, Finlandia, lipiec 2008.