Tor Entry Guards: dlaczego pierwszy węzeł ma tak duże znaczenie dla anonimowości

W poprzednich artykułach z serii o Darknecie analizowaliśmy, jak działa routing cebulowy oraz w jaki sposób można prowadzić Traffic Analysis przeciwko zaszyfrowanemu ruchowi.

Kolejnym elementem, który wymaga znacznie bardziej szczegółowego omówienia, jest Tor Entry Guard.

Dla użytkownika może wyglądać jak zwykły pierwszy przekaźnik w obwodzie Tor:

User
  ↓
Entry Guard
  ↓
Middle Relay
  ↓
Exit Relay
  ↓
Internet

W rzeczywistości jego rola jest znacznie ważniejsza.

Entry Guard jest pierwszym punktem infrastruktury Tor, z którym kontaktuje się klient. Zna więc adres IP użytkownika, ale nie powinien znać jego docelowej strony ani całej trasy komunikacji.

To tworzy bardzo interesujący kompromis:

im bardziej stabilny jest Guard, tym mniej różnych przekaźników musi znać użytkownik, ale jednocześnie każdy wybrany Guard staje się bardzo istotnym elementem modelu bezpieczeństwa.

Na Netbe podstawy wyboru węzłów opisaliśmy już w artykule Jak działa routing losowy (randomized routing) i czy naprawdę zwiększa anonimowość. Ten materiał skupia się wyłącznie na problemie Entry Guard i jego znaczeniu dla anonimowości.

Entry Guard nie jest po prostu „pierwszym serwerem”

W uproszczonym modelu Tor wygląda tak:

Klient
  ↓
Guard
  ↓
Relay
  ↓
Exit

Można więc odnieść wrażenie, że Guard jest tylko pierwszym etapem technicznym.

To jednak błędne podejście.

Guard ma szczególne znaczenie, ponieważ jest jednym z niewielu elementów sieci Tor, które bezpośrednio widzą:

Client IP

Jednocześnie nie powinien znać:

Client IP + Destination

To fundamentalne rozdzielenie informacji.

Co dokładnie wie Entry Guard?

W bardzo uproszczonym modelu:

Client
   │
   │ IP klienta
   ▼
Guard
   │
   │ zaszyfrowany ruch Tor
   ▼
Middle Relay

Guard może wiedzieć:

• że konkretny adres IP korzysta z Tora,
• kiedy rozpoczęła się komunikacja,
• jak długo klient pozostawał aktywny,
• pewne właściwości obserwowanego ruchu.

Nie powinien natomiast posiadać informacji pozwalającej bezpośrednio stwierdzić:

„Ten użytkownik odwiedza właśnie konkretną stronę.”

To właśnie różnica pomiędzy wiedzą o źródle a wiedzą o źródle i celu.

Dlaczego Tor nie wybiera całkowicie losowego Guard przy każdym połączeniu?

Na pierwszy rzut oka mogłoby się wydawać, że najlepszym rozwiązaniem byłoby:

Connection 1 → Guard A
Connection 2 → Guard B
Connection 3 → Guard C
Connection 4 → Guard D

Im większa losowość, tym trudniej przecież przewidzieć trasę.

Problem polega na tym, że takie podejście zwiększa liczbę różnych przekaźników, które mogą obserwować wejście użytkownika do sieci.

Zamiast tego Tor stosuje bardziej kontrolowany model.

W dużym uproszczeniu:

User
 ↓
Small set of Guards
 ↓
Different circuits

Czyli zamiast ciągłego losowania nowych pierwszych węzłów klient korzysta ze stabilniejszego zestawu Guardów.

To jeden z najciekawszych kompromisów w architekturze Tora.

Stabilność kontra losowość

Możemy przedstawić problem jako dwa skrajne modele.

Model A – pełna losowość

User
 ↓
Random Guard
 ↓
Random Guard
 ↓
Random Guard
 ↓
...

Zaleta:

• więcej różnych przekaźników.

Problem:

• użytkownik kontaktuje się z większą liczbą potencjalnych obserwatorów.

Model B – stabilny Guard

User
 ↓
Guard A
 ↓
Guard A
 ↓
Guard A
 ↓
Guard A

Zaleta:

• ograniczona liczba punktów wejścia.

Problem:

• kompromitacja wybranego Guardu może mieć większe znaczenie.

Tor musi więc znaleźć punkt pomiędzy tymi skrajnościami.

Dlaczego ograniczenie liczby Guardów może zwiększać bezpieczeństwo?

Wyobraźmy sobie użytkownika korzystającego z Tora przez długi czas.

Jeżeli za każdym razem wybierałby nowy Guard, jego aktywność mogłaby pojawiać się w wielu miejscach:

Day 1 → Guard A
Day 2 → Guard F
Day 3 → Guard K
Day 4 → Guard M
Day 5 → Guard R

W efekcie więcej operatorów przekaźników mogłoby potencjalnie obserwować moment wejścia tego użytkownika do sieci.

Stabilniejszy model:

Day 1 → Guard A
Day 2 → Guard A
Day 3 → Guard A
Day 4 → Guard A
Day 5 → Guard A

ogranicza ekspozycję na dużą liczbę różnych Guardów.

To bardzo ważna zasada:

większa losowość nie zawsze oznacza większą anonimowość.

Guard Discovery

Zanim klient zacznie korzystać z konkretnego Guardu, musi oczywiście wiedzieć, jakie przekaźniki są dostępne i które spełniają odpowiednie wymagania.

Nie jest to więc prosty proces:

Random()

System musi uwzględnić między innymi:

• dostępność węzła,
• jego właściwości,
• wagę,
• stabilność,
• wymagane flagi,
• aktualny stan sieci.

Dlatego wybór Guardu jest częścią większego mechanizmu zarządzania obwodami.

Guard musi być wystarczająco stabilny

Entry Guard jest szczególnie istotny dla stabilności połączenia.

Jeżeli klient bez przerwy zmieniałby pierwszy węzeł, pojawiałyby się dodatkowe problemy:

New Guard
   ↓
New connection
   ↓
New path
   ↓
New potential observer

Stabilność pozwala ograniczyć tę rotację.

Guard i pierwszy etap anonimowości

Możemy więc powiedzieć:

Client
  ↓
[ Guard ]
  ↓
Tor Network

Guard jest pierwszym miejscem, w którym prywatny adres IP klienta spotyka się z infrastrukturą anonimowej sieci.

Dlatego bezpieczeństwo Guardów ma znaczenie większe niż bezpieczeństwo przypadkowego middle relay.

Co się stanie, jeżeli Guard jest złośliwy?

To jeden z najczęściej zadawanych pytań.

Złośliwy Guard może potencjalnie obserwować:

Client IP
+
Timing
+
Traffic characteristics

Ale sam Guard nie powinien automatycznie otrzymać:

Client IP
+
Destination

To właśnie zaleta wielowarstwowej architektury.

Sam złośliwy Guard nie oznacza więc automatycznie:

„użytkownik został zdeanonimizowany”.

Problem staje się znacznie poważniejszy, gdy przeciwnik posiada dodatkowe możliwości obserwacji.

Guard + obserwator po drugiej stronie

Rozważmy:

Client
  ↓
Guard
  ↓
Middle
  ↓
Exit
  ↓
Destination

Jeżeli przeciwnik kontroluje lub obserwuje pierwszy i odpowiedni późniejszy punkt komunikacji, może próbować porównać:

Ingress Traffic
      ↕
Egress Traffic

To właśnie przechodzimy od problemu złośliwego Guardu do Traffic Correlation.

Netbe opisuje ten model również w artykule Monitoring ruchu w sieci Tor: czy rządy i agencje mogą śledzić aktywność?.

Guard nie zna całej trasy

W klasycznym obwodzie:

Guard → Middle → Exit

Guard nie powinien otrzymać kompletnej informacji o pozostałej trasie.

To konsekwencja onion routingu.

Podstawy tego mechanizmu można znaleźć w Jak działa routing cebulowy (onion routing).

Dzięki temu kompromitacja jednego elementu nie powinna automatycznie ujawniać całej komunikacji.

Guard i atak Sybil

Jednym z interesujących modeli zagrożeń dla sieci rozproszonych jest Sybil attack.

Atakujący próbuje wprowadzić do systemu dużą liczbę kontrolowanych przez siebie elementów.

W przypadku sieci Tor intuicyjny model wyglądałby tak:

Attacker
 ├── Relay A
 ├── Relay B
 ├── Relay C
 ├── Relay D
 └── Relay E

Jeżeli znaczna część dostępnej infrastruktury zaczęłaby należeć do jednego podmiotu, wzrastałaby szansa na wpływanie na wybór ścieżek.

Dlatego mechanizmy wyboru Guardów nie mogą być traktowane jako zwykłe losowanie.

Dlaczego „uruchomię własne 100 relayów” nie oznacza automatycznie kontroli Tora?

Ponieważ system wyboru węzłów uwzględnia właściwości i wagę przekaźników.

Sam fakt uruchomienia wielu maszyn nie powoduje natychmiastowego uzyskania proporcjonalnego wpływu na ruch.

Sieć musi uwzględniać między innymi:

• consensus,
• bandwidth,
• uptime,
• flagi,
• rolę węzła,
• ograniczenia bezpieczeństwa.

To właśnie dlatego analiza potencjalnych ataków na Guardy jest znacznie bardziej skomplikowana niż zwykłe liczenie serwerów.

Entry Guard a bandwidth

Wybór węzłów nie jest oderwany od wydajności.

Tor musi jednocześnie zapewniać:

Privacy
+
Security
+
Performance

Jeżeli system wybierałby wyłącznie najbardziej anonimowe węzły bez uwzględniania ich przepustowości, użytkownicy doświadczaliby znacznie większych opóźnień.

Dlatego mechanizm wyboru jest kompromisem pomiędzy różnymi właściwościami infrastruktury.

Dlaczego Guard może być interesujący dla analityka?

Ponieważ jest to punkt, w którym można obserwować:

User
 ↓
Tor

Jeżeli ktoś prowadzi badania sieciowe, Guard może dostarczyć informacji o:

• liczbie aktywnych klientów,
• czasie aktywności,
• wzorcach ruchu,
• obciążeniu,
• charakterystyce transmisji.

Nie oznacza to jednak, że operator Guardu zna treść komunikacji.

To właśnie rozdzielenie informacji jest jednym z fundamentów architektury.

Guard i Traffic Analysis

Tutaj pojawia się bezpośrednie połączenie z poprzednim artykułem.

Traffic Analysis może wykorzystywać:

Timing
Volume
Direction
Duration
Burst patterns

Guard znajduje się natomiast po stronie wejściowej.

Można więc wyobrazić sobie:

Client
 ↓
Guard
 ↓
========== Tor ==========
 ↓
Destination

Jeżeli obserwator ma dostęp tylko do Guardu, jego wiedza pozostaje ograniczona.

Jeżeli posiada drugi punkt obserwacyjny, pojawia się możliwość korelacji.

Guard i website fingerprinting

Website fingerprinting może działać na podstawie charakterystyki ruchu.

Jeżeli użytkownik odwiedza określoną stronę, generowany jest pewien wzorzec:

Request
 ↓
Response
 ↓
Additional resources
 ↓
Images
 ↓
Scripts

Obserwator po stronie wejściowej nie widzi treści, ale może analizować cechy transmisji.

To nie musi wystarczyć do identyfikacji konkretnej strony.

Może jednak stanowić element większego modelu klasyfikacyjnego.

Netbe opisuje związany z tym problem fingerprintingu przeglądarki Tor.

Guard a circuit isolation

Kolejnym interesującym mechanizmem jest circuit isolation.

Tor może wykorzystywać różne obwody dla różnych kontekstów komunikacji.

W praktyce:

Activity A → Circuit 1
Activity B → Circuit 2
Activity C → Circuit 3

Ma to ograniczać możliwość łatwego łączenia różnych aktywności.

Netbe ma osobny materiał Jak działa izolacja obwodów (circuit isolation) w sieci Tor.

Czy nowy circuit oznacza nowy Guard?

Nie należy tego upraszczać.

Jedną z kluczowych idei jest właśnie to, że użytkownik może tworzyć różne obwody przy zachowaniu stabilniejszego punktu wejścia.

Możemy więc mieć:

             ┌→ Middle A → Exit A
Guard ───────┼→ Middle B → Exit B
             └→ Middle C → Exit C

To bardzo istotna różnica.

Nowy circuit nie oznacza automatycznie nowego Guardu.

Dlaczego to rozwiązanie ma sens?

Ponieważ pozwala ograniczyć liczbę potencjalnych punktów wejściowych.

Zamiast:

User → A
User → B
User → C
User → D
User → E

możemy mieć:

              → Circuit 1
Guard ────────→ Circuit 2
              → Circuit 3
              → Circuit 4

Stabilny Guard ogranicza powierzchnię ekspozycji.

Guard failure

Każda infrastruktura może jednak ulec awarii.

Guard może:

• przestać działać,
• stać się niedostępny,
• utracić odpowiednie właściwości,
• zostać wycofany z sieci.

System musi więc posiadać mechanizmy radzenia sobie z awariami.

To kolejny przykład kompromisu:

Security
+
Availability

Guard rotation

Rotacja Guardów nie może być traktowana jak zwykłe:

every X minutes → new Guard

Zbyt agresywna rotacja zwiększa liczbę potencjalnych obserwatorów.

Zbyt mała rotacja może zwiększać znaczenie pojedynczego Guardu.

Dlatego zarządzanie Guardami jest elementem samego modelu bezpieczeństwa Tora.

Co jeżeli Guard zostanie przejęty?

Załóżmy:

Guard A
   ↓
Compromised

Nie oznacza to automatycznie:

User identity revealed

Bardziej realistycznie:

Compromised Guard
        ↓
Observation of client-side activity
        ↓
Potential metadata collection
        ↓
Potential correlation

Do pełnej deanonymizacji może być potrzebny dodatkowy sygnał.

Netbe opisuje różne scenariusze deanonymizacji w sieci Tor.

Guard + Exit = dużo większy problem

W bardzo uproszczonym modelu:

Client
 ↓
[Compromised Guard]
 ↓
Tor
 ↓
[Observed Exit]
 ↓
Internet

Przeciwnik może próbować porównywać:

Input pattern
      ↕
Output pattern

To właśnie tutaj Traffic Correlation staje się szczególnie istotne.

Nie chodzi o to, że Guard sam „widzi wszystko”.

Chodzi o możliwość połączenia informacji pochodzących z różnych miejsc.

Guard i Onion Services

W przypadku usług .onion model jest jeszcze ciekawszy.

Nie występuje klasyczny exit node w taki sposób jak przy połączeniu z publicznym Internetem.

Architektura wykorzystuje m.in. rendezvous mechanisms.

Możemy więc uprościć ją do:

Client
 ↓
Guard
 ↓
Tor
 ↓
Rendezvous
 ↑
Tor
 ↑
Onion Service

Więcej szczegółów znajduje się w artykule Jak działa mechanizm Onion Services – usługi .onion od strony technicznej.

Guard Bridges – jeszcze inny model

W sytuacjach, w których użytkownik znajduje się w sieci blokującej publiczne przekaźniki Tor, może wykorzystywać bridges.

Bridge nie jest tym samym co standardowy publiczny Guard.

Jego podstawowym zadaniem jest utrudnienie wykrycia lub zablokowania dostępu do Tora.

Netbe opisuje ten mechanizm w Jak działają ukryte mosty (bridges) w Tor i omijanie cenzury internetu.

Bridge nie rozwiązuje wszystkich problemów

Ważne jest rozdzielenie dwóch kwestii:

ukrywanie faktu korzystania z Tora

oraz:

anonimowość komunikacji w Torze.

Bridge może pomóc w pierwszym problemie.

Nie oznacza to automatycznie rozwiązania:

• traffic correlation,
• fingerprintingu,
• błędów OPSEC,
• kompromitacji endpointu.

Czy ISP widzi Entry Guard?

W klasycznym modelu ISP może widzieć, że użytkownik łączy się z określonym adresem IP.

To prowadzi do pytania:

„Czy ISP wie, że używam Tora?”

W wielu przypadkach może być w stanie to stwierdzić, szczególnie jeśli użytkownik łączy się bezpośrednio z publicznym przekaźnikiem.

Właśnie tutaj bridges i mechanizmy obfuscation mają znaczenie.

Guard i obfuskacja

Można więc połączyć kilka warstw:

Client
 ↓
Bridge / Obfuscation
 ↓
Guard
 ↓
Middle
 ↓
Exit

Celem nie jest tylko ukrycie treści.

Chodzi również o utrudnienie klasyfikacji samego ruchu.

Na Netbe opisano szerzej traffic obfuscation i ukrywanie metadanych ruchu.

Czy własny Guard zwiększa anonimowość?

To zależy od modelu zagrożenia.

Uruchomienie własnego przekaźnika nie oznacza automatycznie, że:

My Guard = Better anonymity

Pojawia się wiele dodatkowych problemów:

• reputacja węzła,
• bandwidth,
• konfiguracja,
• bezpieczeństwo serwera,
• monitoring,
• odpowiedzialność operatora,
• relacja z pozostałą infrastrukturą.

Dlatego własny relay należy traktować przede wszystkim jako element infrastruktury Tor, a nie jako magiczne narzędzie prywatności.

Guard jako element modelu zaufania

Jedną z najciekawszych cech Tora jest to, że użytkownik nie musi ufać jednemu serwerowi w zakresie całej komunikacji.

Zaufanie jest rozdzielone:

Guard
  ↓
zna źródło

Middle
  ↓
przekazuje ruch

Exit
  ↓
zna cel klasycznego połączenia

To jest podstawowy model distributed trust.

Co naprawdę może zobaczyć Guard?

Możemy podsumować:

To bardzo ważne rozróżnienie.

Największy błąd: „Guard mnie widzi, więc Tor jest złamany”

Nie.

Guard został zaprojektowany właśnie po to, aby znać pewną część informacji.

Bez tego sieć nie mogłaby działać.

Kluczowe pytanie brzmi:

ile informacji można połączyć z innych miejsc?

Jeżeli Guard zna IP, ale nie zna celu:

Privacy property preserved

Jeżeli inny obserwator zna cel, ale nie zna IP:

Privacy property preserved

Jeżeli jeden przeciwnik może połączyć oba:

Correlation risk increases

Najważniejszy kompromis Entry Guard

Cały mechanizm można sprowadzić do jednego problemu:

More Guard rotation
        ↓
More exposure to relays

Less Guard rotation
        ↓
More dependence on selected Guard

Tor musi więc znaleźć równowagę.

I właśnie dlatego Entry Guard jest jednym z najbardziej interesujących elementów architektury sieci anonimowej.

Czy można całkowicie wyeliminować ryzyko Guard?

Nie.

Można natomiast projektować system tak, aby kompromitacja jednego elementu nie prowadziła automatycznie do pełnej deanonymizacji.

To fundamentalna zasada bezpieczeństwa:

assume compromise, limit the damage.

W przypadku Tora oznacza to rozdzielenie informacji pomiędzy kolejne elementy ścieżki.

Entry Guard a przyszłość analizy ruchu

Wraz z rozwojem:

• machine learning,
• dużych zbiorów danych,
• automatycznej korelacji,
• network telemetry,
• behavioral analytics,

Traffic Analysis może stawać się coraz bardziej zaawansowana.

To nie oznacza, że Tor przestaje działać.

Oznacza raczej, że wyścig pomiędzy anonimowością a analizą ruchu będzie trwał dalej.

Najważniejsze wnioski

Entry Guard jest znacznie ważniejszy, niż sugeruje jego nazwa.

To nie tylko pierwszy serwer na trasie.

To element, który:

1. widzi adres IP klienta,
2. stanowi pierwszy punkt wejścia do sieci Tor,
3. ma ograniczoną wiedzę o dalszej trasie,
4. powinien być wybierany w sposób ograniczający niepotrzebną ekspozycję,
5. może być istotnym źródłem danych dla Traffic Analysis,
6. staje się szczególnie ważny w modelach ataków korelacyjnych.

Najważniejsze jest jednak to, że kompromitacja pojedynczego Guardu nie oznacza automatycznie złamania anonimowości użytkownika.

Ryzyko rośnie przede wszystkim wtedy, gdy przeciwnik może połączyć informacje z wielu punktów infrastruktury.

Podsumowanie

Entry Guards pokazują, że bezpieczeństwo Tora nie polega na maksymalnej losowości.

Wręcz przeciwnie.

W pewnych aspektach kontrolowana stabilność może zwiększać bezpieczeństwo, ponieważ ogranicza liczbę przekaźników, które mogą obserwować wejście użytkownika do sieci.

Jednocześnie każdy wybrany Guard staje się istotnym elementem modelu zagrożeń.

Najbardziej interesujący scenariusz nie wygląda więc:

Malicious Guard
      ↓
Instant deanonymization

ale:

Malicious / Observed Guard
          ↓
Client-side metadata
          ↓
Traffic Analysis
          ↓
Second observation point
          ↓
Traffic Correlation
          ↓
Potential attribution

I właśnie dlatego Entry Guards są tak ważne.

Nie dlatego, że sam pierwszy węzeł „łamie anonimowość”, ale dlatego, że znajduje się dokładnie na granicy pomiędzy użytkownikiem a anonimową infrastrukturą.

W kolejnych analizach warto pójść jeszcze głębiej: Guard Discovery, Guard Sets, kompromitacja wielu relayów, ataki Sybil oraz to, jak duży przeciwnik może próbować zwiększyć prawdopodobieństwo znalezienia się na ścieżce użytkownika.

Powiązane artykuły na Netbe

• Jak działa routing losowy (randomized routing) i czy naprawdę zwiększa anonimowość
• Jak działa routing cebulowy (onion routing)
• Jak działa sieć Tor – anonimowość, routing cebulowy i zagrożenia
• Monitoring ruchu w sieci Tor
• Ryzyka deanonymizacji w sieci Tor
• Izolacja obwodów w Tor
• Traffic Obfuscation
• Tor Browser i fingerprinting
• Ukryte mosty Tor Bridges
• Onion Services od strony technicznej

Polecane wpisy

Windows Copilot i prywatność danych: Czy sztuczna inteligencja to nowa luka?

🤖 Windows Copilot i prywatność danych: Czy sztuczna inteligencja to nowa luka? 📌 Wprowadzenie Wraz z premierą Windows 11 firma Czytaj dalej

Inżynieria Społeczna: Jak ludzie są najsłabszym ogniwem bezpieczeństwa? Techniki oszustwa i manipulacji

🎭 Inżynieria Społeczna: Jak ludzie są najsłabszym ogniwem bezpieczeństwa? Techniki oszustwa i manipulacji 🔐 Wstęp: Dlaczego człowiek to najsłabsze ogniwo? Czytaj dalej