Zaprezentowano wydanie specjalistycznej przeglądarki Tor Browser 11.0.2, skupiającej się na zapewnieniu anonimowości, bezpieczeństwa i prywatności. Podczas korzystania z przeglądarki Tor cały ruch jest przekierowywany wyłącznie przez sieć Tor i nie jest możliwy bezpośredni dostęp poprzez standardowe połączenie sieciowe bieżącego systemu, co nie pozwala na śledzenie prawdziwego adresu IP użytkownika (jeśli przeglądarka zostanie zhakowana, napastnicy można uzyskać dostęp do parametrów sieciowych systemu, dlatego do pełnego zablokowania ewentualnych wycieków należy zastosować produkty takie jak Whonix). Kompilacje przeglądarki Tor są przygotowane dla systemów Linux, Windows i macOS.
Aby zapewnić dodatkowe bezpieczeństwo, przeglądarka Tor zawiera dodatek HTTPS Everywhere, który umożliwia szyfrowanie ruchu we wszystkich witrynach, jeśli to możliwe. Aby zmniejszyć ryzyko ataków JavaScript i domyślnie blokować wtyczki, dołączono dodatek NoScript. Aby przeciwdziałać blokowaniu i inspekcji ruchu, wykorzystuje się transport alternatywny. Aby chronić przed wyróżnianiem funkcji specyficznych dla odwiedzających, interfejsy API WebGL, WebGL2, WebAudio, Social, SpeechSynthesis, Touch, AudioContext, HTMLMediaElement, Mediastream, Canvas, SharedWorker, WebAudio, Permissions, MediaDevices.enumerateDevices i screen.orientation są wyłączone lub ograniczone narzędzia do wysyłania telemetrii, Pocket, Reader View, alternatywne usługi HTTP, MozTCPSocket, „link rel=preconnect”, zmodyfikowane przez libmdns.
Nowa wersja synchronizuje się z bazą kodu wersji Firefoksa 91.4.0, która naprawiła 15 luk, z czego 10 oznaczono jako niebezpieczne. Luki 7 są spowodowane problemami z pamięcią, takimi jak przepełnienie bufora i dostęp do już zwolnionych obszarów pamięci, i mogą potencjalnie prowadzić do wykonania kodu atakującego podczas otwierania specjalnie zaprojektowanych stron. Niektóre czcionki ttf zostały wyłączone z kompilacji dla platformy Linux, czego użycie doprowadziło do zakłóceń w renderowaniu tekstu w elementach interfejsu w Fedorze Linux. Wyłączona jest opcja „network.proxy.allow_bypass”, która kontroluje działanie ochrony przed nieprawidłowym użyciem API Proxy w dodatkach. Dla transportu obfs4 nowa bramka „deusexmachina” jest domyślnie włączona.
Tymczasem historia blokowania Tora w Federacji Rosyjskiej trwa. Roskomnadzor zmienił maskę blokowanych domen w rejestrze zabronionych stron z „www.torproject.org” na „*.torproject.org” i rozszerzył listę adresów IP podlegających blokowaniu. Zmiana spowodowała zablokowanie większości subdomen projektu Tor, w tym blog.torproject.org, gettor.torproject.org i support.torproject.org. forum.torproject.net, hostowane w infrastrukturze Discourse, pozostaje dostępne. Częściowo dostępne są gitlab.torproject.org i lists.torproject.org, do których początkowo dostęp został utracony, ale następnie przywrócony, prawdopodobnie po zmianie adresów IP (gitlab jest teraz kierowany na hosta gitlab-02.torproject.org).
Jednocześnie bramy i węzły sieci Tor, a także host ajax.aspnetcdn.com (Microsoft CDN), używany w transporcie meek-asure, nie były już blokowane. Najwyraźniej eksperymenty z blokowaniem węzłów sieci Tor po zablokowaniu strony Tor zostały wstrzymane. Trudna sytuacja pojawia się z lustrem tor.eff.org, które w dalszym ciągu działa. Faktem jest, że lustro tor.eff.org jest powiązane z tym samym adresem IP, który jest używany dla domeny eff.org EFF (Electronic Frontier Foundation), więc zablokowanie tor.eff.org doprowadzi do częściowego zablokowania witryna znanej organizacji praw człowieka.
Dodatkowo możemy odnotować publikację nowego raportu na temat możliwych prób przeprowadzenia ataków mających na celu deanonimizację użytkowników Tora powiązanych z grupą KAX17, identyfikowanych po konkretnych fikcyjnych adresach kontaktowych w parametrach węzła. We wrześniu i październiku projekt Tor zablokował 570 potencjalnie złośliwych węzłów. W szczytowym momencie grupie KAX17 udało się zwiększyć liczbę kontrolowanych węzłów w sieci Tor do 900, hostowanych przez 50 różnych dostawców, co odpowiada około 14% całkowitej liczby przekaźników (dla porównania w 2014 roku atakującym udało się przejąć kontrolę nad prawie połową przekaźników Tora, a w 2020 roku ponad 23.95% węzłów wyjściowych).
Umieszczenie dużej liczby węzłów kontrolowanych przez jednego operatora umożliwia deanonimizację użytkowników za pomocą ataku klasy Sybil, który można przeprowadzić, jeśli atakujący mają kontrolę nad pierwszym i ostatnim węzłem w łańcuchu anonimizacji. Pierwszy węzeł w łańcuchu Tora zna adres IP użytkownika, a ostatni zna adres IP żądanego zasobu, co umożliwia deanonimizację żądania poprzez dodanie pewnej ukrytej etykiety do nagłówków pakietów na stronie węzła wejściowego, która pozostaje niezmieniona w całym łańcuchu anonimizacji i analizując tę etykietę po stronie węzła wyjściowego. Dzięki kontrolowanym węzłom wyjściowym osoby atakujące mogą również wprowadzać zmiany w niezaszyfrowanym ruchu, na przykład usuwać przekierowania do wersji witryn HTTPS i przechwytywać niezaszyfrowaną treść.
Według przedstawicieli sieci Tor większość usuniętych jesienią węzłów służyła jedynie jako węzły pośrednie, nie wykorzystywane do przetwarzania żądań przychodzących i wychodzących. Niektórzy badacze zauważają, że węzły należały do wszystkich kategorii, a prawdopodobieństwo dotarcia do węzła wejściowego kontrolowanego przez grupę KAX17 wynosiło 16%, a do węzła wyjściowego – 5%. Ale nawet jeśli tak jest, to ogólne prawdopodobieństwo jednoczesnego trafienia użytkownika w węzeł wejściowy i wyjściowy grupy 900 węzłów kontrolowanych przez KAX17 szacuje się na 0.8%. Nie ma bezpośrednich dowodów na wykorzystywanie węzłów KAX17 do przeprowadzania ataków, ale nie można wykluczyć potencjalnych podobnych ataków.
Źródło: opennet.ru