Dodanie kolejnego szyfrowanego odcinka do ścieżki nie usuwa obserwatorów; przenosi ich, a czasem dokłada jednego. Pożytecznym ćwiczeniem jest narysowanie trasy i opisanie, kto na każdym etapie co widzi, ponieważ VPN przed Torem i VPN osiągany przez Tora dają przeciwne odpowiedzi na prawie każde pytanie warte zadania. Żadne z tych rozwiązań nie pokonuje przejętego punktu końcowego i żadne nie naprawia konta, które wskazuje użytkownika. Przejście ścieżki po kolei i pytanie, co się psuje, gdy warstwa znika, zamienia slogan w decyzję.

Przejdź ścieżkę i nazwij każdego obserwatora

Zacznij od zwykłego przypadku Tora i oznacz każdy skok. Sieć lokalna i dostawca internetu widzą połączenie z punktem wejściowym Tora wraz z jego rozmiarem i czasem. Strażnik wejściowy widzi adres klienta, dlatego strażnik jest relacją długoterminową, a nie przypadkowym wyborem. Węzeł wyjściowy widzi cel i tekst jawny wszystkiego, co nie jest szyfrowane od końca do końca, a cel widzi adres wyjściowy, do którego nie jest przypisany żaden adres klienta.

Zapisz te etykiety, zanim cokolwiek dodasz. Diagram jest argumentem i łatwo go sprawdzić.

Dwie kolejności dają różne obserwacje

VPN umieszczony przed Torem oznacza, że ruch opuszcza urządzenie w kierunku dostawcy VPN, wychodzi od tego dostawcy i dopiero potem trafia do wejścia Tora. Sieć lokalna w ogóle nie widzi już Tora, i to jest cały sens, gdy sieć go blokuje lub monitoruje. Strażnik wejściowy widzi teraz adres VPN zamiast adresu użytkownika, a dostawca VPN widzi, że konkretny klient łączy się z Torem w określonym wzorcu czasowym. Ten dostawca staje się nową stroną z cenną obserwacją, a jego polityka logowania jest teraz częścią modelu zagrożeń, a nie czymś poza nim.

Osiąganie VPN przez Tora odwraca kolejność i odwraca też to, co jest ujawniane: cel widzi adres VPN, wyjście Tora nie widzi już celu, a dostawca VPN widzi nadchodzący ruch Tora, a nie domowy adres klienta. Obciąża to też połączenie dwiema warstwami opóźnienia i wymaga wsparcia klienta, którego wiele aplikacji komercyjnych nie oferuje.

Wybór między nimi to pytanie, który obserwator ma największe znaczenie, a nie który brzmi bezpieczniej. Użytkownik ukrywający korzystanie z Tora przed siecią lokalną chce pierwszej kolejności; użytkownik próbujący nie pozwolić celowi dowiedzieć się czegokolwiek, co można mu przypisać, potrzebuje innej analizy, i żadna kolejność nie ukrywa nazwy konta.

Co nadal identyfikuje sesję

Obserwatorzy na poziomie adresu to tylko część obrazu i często nie część decydująca. Zalogowane konto wiąże aktywność z tożsamością niezależnie od tego, który adres wyjściowy niósł pakiet, a zapis płatności, który usługa może powiązać z osobą, robi to samo. Stan przeglądarki też się dokłada: trwałe ciasteczko, zapisane logowanie lub identyfikujące rozszerzenie mogą śledzić użytkownika przez obwody zaprojektowane jako niełączliwe.

Treść wysyłana do witryny to trzeci sygnał. Dokument z metadanymi, nazwisko wpisane w formularz albo unikalny styl pisania przetrwają dowolną liczbę warstw szyfrowania, a żadne z narzędzi przed nimi nie jest stworzone, by tego dotknąć. Prowadzenie uczciwej listy tych identyfikatorów chroni więcej niż dodanie kolejnego skoku.

Zaplanuj warstwę, która znika

Zachowanie przy awarii to miejsce, w którym rozwiązania naprawdę się różnią, i jest to właściwość konfiguracji, a nie funkcja któregokolwiek z narzędzi. Jeśli VPN padnie, gdy Tor jest ustawiony tak, by przez niego przechodził, czy Tor się zatrzymuje, czy po cichu łączy się ponownie zwykłą trasą? Drugi wynik nie jest wyciekiem do celu, ale ujawnia sieci lokalnej, że Tor jest używany, co być może było dokładnie tym, czemu rozwiązanie miało zapobiec.

Wyłącznik awaryjny na poziomie urządzenia może wymusić część odpowiedzi, odmawiając ruchu poza tunelem, i obejmuje tylko ruch, który urządzenie trasuje. Aplikacja wykluczona z tunelu omija tę ochronę, a resolver używany przy nawiązywaniu połączenia może ujawnić nazwy nawet gdy ładunek pozostaje w tunelu. Czytaj wykluczenia i konfigurację resolvera, zamiast zakładać, że wyłącznik obejmuje wszystko.

Zostaw pakiet przeglądarki w spokoju

Zabezpieczenia Tor Browser zależą od tego, czy cały pakiet zachowuje się zgodnie z projektem: własna konfiguracja proxy, izolacja między witrynami i obrona przed odciskami palców. Skierowanie zwykłej przeglądarki na lokalny port Tora albo dodanie rozszerzenia proxy do Tor Browser zmienia założenia, na których opiera się projekt. Własne wskazówki Tor Project dotyczące łączenia VPN z Torem traktują to połączenie jako zaawansowaną konfigurację, a ta ostrożność dotyczy właśnie tych interakcji, a nie dostawcy VPN.

Zanim połączysz narzędzia, umiej prostymi zdaniami przedstawić zwykłą trasę, trasę awaryjną i rolę każdego operatora. Jeśli jedynym uzasadnieniem jest to, że dwie warstwy brzmią bezpieczniej, nie ma wymagania, przeciw któremu projektować, a dodanym głównym elementem jest nowy tryb awarii.

Powiązane artykuły