Zaprezentowano wydanie narzędzia Tor 0.4.7.7, które jest używane do organizacji pracy w anonimowej sieci Tor. Wersja Tor 0.4.7.7 uznawana jest za pierwsze stabilne wydanie gałęzi 0.4.7, która była rozwijana przez ostatnie dziesięć miesięcy. Gałąź 0.4.7 będzie wspierana w ramach standardowego cyklu wsparcia — wydawanie aktualizacji zakończy się za 9 miesięcy lub 3 miesiące po wydaniu gałęzi 0.4.8.x.
Najważniejsze zmiany w nowej gałęzi:
- Dodano implementację protokołu zarządzania przeciążeniem (RTT Congestion Control), który reguluje ruch w sieci Tor (między klientem a węzłem wyjściowym lub usługą onion). Protokół ten ma na celu zmniejszenie wielkości kolejek na relajach oraz przezwyciężenie obecnych ograniczeń przepustowości. Dotychczas prędkość jednego strumienia pobierania przez węzły wyjściowe i usługi onion wynosiła 1 MB/s, ponieważ okno wysyłki miało stały rozmiar 1000 komórek na strumień, a w każdej komórce można wysłać 512 bajtów danych (prędkość strumienia przy opóźnieniu w łańcuchu 0,5 sek = 1000*512/0,5 = ~1 MB/s).
Do prognozowania dostępnej przepustowości i określenia wielkości kolejki pakietów w nowym protokole wykorzystuje się ocenę czasu przejścia (RTT, Round Trip Time). Przeprowadzone symulacje wykazały, że zastosowanie nowego protokołu na węzłach wyjściowych i usługach onion spowoduje zmniejszenie opóźnień w kolejce, zniesienie ograniczeń prędkości strumienia, zwiększenie wydajności sieci Tor oraz bardziej optymalne wykorzystanie dostępnej przepustowości. Po stronie klienta wsparcie dla zarządzania ruchem będzie oferowane 31 maja w następnym znaczącym wydaniu Tor Browser, opartym na gałęzi Tor 0.4.7.
- Dodano uproszczoną ochronę Vanguards-lite przed atakami deanonimizacyjnymi krótkotrwałych usług onion, która zmniejsza ryzyko identyfikacji strażników (guard) usługi onion lub klienta onion, w sytuacjach gdy usługa działa krócej niż miesiąc (dla usług onion działających dłużej niż miesiąc zaleca się użycie rozszerzenia vanguards). Istotą metody jest to, że klienci onion oraz usługi automatycznie wybierają 4 długo działające węzły strażnicze („layer 2 guard relay”) do użycia w środkowej części łańcucha, a dane te są przechowywane przez losowy czas (średnio tydzień).
- Dla serwerów W katalogu wprowadzono możliwość przypisania flagi MiddleOnly do relacji z wykorzystaniem nowej metody osiągania konsensusu. Nowa metoda polega na przeniesieniu logiki ustalania flagi MiddleOnly z poziomu klienta na serwery katalogów. Dla relacji oznaczonych jako MiddleOnly automatycznie usuwane są flagi Exit, Guard, HSDir i V2Dir, a ustalana jest flaga BadExit.
Źródło: opennet.ru
