Korelacja ruchu w Tor – jak można deanonymizować użytkownika bez łamania szyfrowania
Informatyka

Korelacja ruchu w Tor – jak można deanonymizować użytkownika bez łamania szyfrowania

Spis treści

Korelacja ruchu w Tor – jak można deanonymizować użytkownika bez łamania szyfrowania

Sieć Tor jest jednym z najważniejszych narzędzi ochrony prywatności w Internecie.

Jej podstawowa idea jest stosunkowo prosta: użytkownik nie łączy się bezpośrednio z serwerem docelowym. Ruch przechodzi przez kilka kolejnych węzłów, a każdy z nich zna tylko fragment całej trasy.

W uproszczeniu:

Użytkownik
    ↓
Guard
    ↓
Middle Relay
    ↓
Exit
    ↓
Internet

W przypadku usług onion schemat wygląda jeszcze inaczej, ponieważ połączenie nie wymaga klasycznego exit node.

Problem polega jednak na tym, że Tor nie musi zostać złamany kryptograficznie, aby anonimowość użytkownika została osłabiona.

Można próbować analizować coś zupełnie innego:

  • czas transmisji,
  • rozmiar pakietów,
  • częstotliwość komunikacji,
  • kierunek ruchu,
  • charakterystyczne wzorce,
  • korelacje pomiędzy obserwowanymi punktami sieci.

To właśnie prowadzi do jednego z najciekawszych zagadnień związanych z anonimowymi sieciami:

traffic correlation attack – atak korelacji ruchu.

I jest to znacznie bardziej zaawansowany temat niż popularne pytanie „czy Tor jest anonimowy?”.

Netbe omawia już podstawy problemu w artykule Czy TOR nadal jest anonimowy w 2026 roku?. Ten tekst pójdzie krok dalej i pokaże, dlaczego sama kryptografia nie rozwiązuje problemu analizy metadanych.


Tor szyfruje treść, ale nie eliminuje wszystkich metadanych

Najważniejsza rzecz do zrozumienia:

szyfrowanie nie oznacza automatycznie ukrycia całego wzorca komunikacji.

Jeżeli obserwator nie zna treści wiadomości, nadal może potencjalnie obserwować:

czas
rozmiar
częstotliwość
kierunek
intensywność
długość sesji

Przykładowo:

10:00:01  ███
10:00:02  ███████
10:00:03  ██
10:00:04  █████████

Sam fakt, że dane są zaszyfrowane, nie oznacza, że taki wzorzec przestaje istnieć.

To właśnie różnica pomiędzy:

Content

a:

Metadata

Na czym polega korelacja ruchu?

Wyobraźmy sobie obserwatora, który ma możliwość obserwowania dwóch różnych miejsc.

Po jednej stronie:

Użytkownik → Tor

Po drugiej:

Tor → Serwer

Obserwator nie musi znać treści komunikacji.

Może natomiast próbować sprawdzić:

Czy wzorzec A

jest statystycznie podobny do:

wzorca B?

Przykładowo:

INPUT

██ █████ ██ ████████ ███

OUTPUT

██ █████ ██ ████████ ███

Jeżeli wzorce są odpowiednio skorelowane, może powstać hipoteza:

ruch obserwowany w punkcie A może odpowiadać ruchowi obserwowanemu w punkcie B.

Nie jest to magiczne „odszyfrowanie Tor”.

To analiza zachowania ruchu.


Dlaczego to jest trudniejsze niż zwykłe podsłuchiwanie?

Ponieważ Tor został zaprojektowany tak, aby utrudnić bezpośrednie powiązanie:

User → Destination

Nie ma jednego urządzenia, które musi znać całą trasę.

Każdy przekaźnik zna tylko część informacji.

W klasycznym modelu:

User
 ↓
ISP
 ↓
Website

ISP może wiedzieć, z kim użytkownik się komunikuje.

W Tor:

User
 ↓
Guard
 ↓
Middle
 ↓
Exit
 ↓
Website

informacja zostaje rozdzielona.

Problem zaczyna się wtedy, gdy jeden obserwator może zobaczyć więcej niż jeden fragment tej ścieżki.


Globalny obserwator to zupełnie inny przeciwnik

W modelu zagrożeń warto rozróżnić kilka klas obserwatorów.

Lokalny obserwator

Może obserwować:

User → Guard

Obserwator po stronie serwera

Może obserwować:

Exit → Destination

Rozbudowany obserwator

Może mieć dostęp do wielu punktów:

User → Tor
+
Tor → Destination

Globalny obserwator

W najbardziej wymagającym modelu przeciwnik może obserwować bardzo dużą część infrastruktury.

To oczywiście znacznie silniejszy model zagrożenia niż typowy cyberprzestępca.

Ale właśnie wtedy pojawia się problem korelacji.


Nie trzeba łamać AES ani RSA

To jeden z najważniejszych elementów całej koncepcji.

Załóżmy, że szyfrowanie działa perfekcyjnie.

Atakujący nadal może zobaczyć:

Packet A
Packet B
Packet C
...

Nie zna ich zawartości.

Może jednak analizować:

A → czas
B → czas
C → czas

oraz:

rozmiar
kierunek
częstotliwość

W rezultacie problem wygląda tak:

Cryptography
       ↓
Protects Content

ale:

Traffic Analysis
       ↓
Studies Patterns

To dwa różne problemy.


Dlaczego czas transmisji ma znaczenie?

Wyobraźmy sobie bardzo uproszczony przykład.

Użytkownik rozpoczyna sesję:

12:01:03

Po chwili obserwowany jest charakterystyczny wzorzec ruchu:

12:01:04
12:01:05
12:01:07
12:01:08

W innym punkcie infrastruktury pojawia się podobna sekwencja:

12:01:04
12:01:05
12:01:07
12:01:08

Jeżeli obserwator posiada wystarczająco dużo danych, może próbować obliczyć podobieństwo obu szeregów czasowych.

Nie chodzi więc o:

„odszyfrujmy pakiety”.

Chodzi o:

„sprawdźmy, czy dwa strumienie zachowują się jak ta sama transmisja.”


Problem można traktować matematycznie

Możemy przedstawić ruch jako szereg czasowy:

X = [x1, x2, x3, ..., xn]

oraz obserwowany ruch w drugim punkcie:

Y = [y1, y2, y3, ..., yn]

Następnie można badać zależności statystyczne pomiędzy X i Y.

Jednym z intuicyjnych pojęć jest korelacja.

Jeżeli:

corr(X,Y) → wysoka

możemy otrzymać sygnał, że oba strumienie mogą być powiązane.

To jednak nie jest automatyczny dowód tożsamości użytkownika.

To ważne rozróżnienie.


Korelacja nie oznacza identyfikacji

W analizie bezpieczeństwa bardzo łatwo popełnić błąd:

High correlation
      ↓
„To na pewno ten sam użytkownik”

To nie musi być prawdą.

Możliwe są:

  • przypadkowe podobieństwa,
  • wielu użytkowników generujących podobny ruch,
  • błędy pomiarowe,
  • opóźnienia,
  • zmienność sieci,
  • dodatkowe źródła szumu.

Dlatego poprawny model wygląda raczej tak:

Observation
     ↓
Statistical correlation
     ↓
Hypothesis
     ↓
Additional evidence
     ↓
Attribution

To zupełnie inny proces.


Tor dodaje szum do całego procesu

Sieć Tor nie jest prostym tunelem punkt-punkt.

Pomiędzy użytkownikiem i usługą znajduje się infrastruktura pośrednia.

Występują:

  • opóźnienia,
  • zmiany przepustowości,
  • konkurencyjny ruch,
  • routing,
  • przeciążenia,
  • różnice pomiędzy relayami.

Dlatego:

Input pattern

nie musi wyglądać identycznie jak:

Output pattern

I właśnie dlatego analiza korelacyjna jest trudnym problemem statystycznym.


Onion routing nie oznacza traffic hiding

To bardzo ważne rozróżnienie.

Tor przede wszystkim rozdziela wiedzę o:

Who

oraz:

Where

pomiędzy różne elementy infrastruktury.

Ale nie oznacza to automatycznie:

No traffic patterns

Jeżeli przeciwnik posiada odpowiednio szeroki punkt obserwacji, metadane mogą być przedmiotem analizy.

Dlatego anonimowość Tor zależy również od modelu przeciwnika.


Dlaczego czasami „większa anonimowość” nie oznacza pełnej anonimowości?

Można to porównać do tłumu.

Jeżeli jedna osoba idzie przez pustą ulicę:

Person A

łatwo ją obserwować.

Jeżeli przez ulicę przechodzi:

1000 osób

trudniej wskazać konkretną osobę.

Ale jeżeli ktoś może obserwować:

wejście do ulicy
+
wyjście z ulicy

może próbować śledzić wzorce ruchu.

To właśnie intuicja stojąca za analizą korelacyjną.


Anonimowość jest własnością całego systemu

Nie wystarczy:

Tor

Samo używanie Tor nie gwarantuje, że użytkownik nie popełni błędu.

Problem może powstać na poziomie:

  • przeglądarki,
  • aplikacji,
  • systemu,
  • zachowania użytkownika,
  • kont,
  • cookies,
  • fingerprintingu,
  • czasu aktywności,
  • pobieranych plików,
  • dodatkowych połączeń.

Netbe analizuje jeden z tych problemów w artykule Jak przeglądarka Tor chroni przed fingerprintingiem i gdzie są jej granice.


Fingerprinting i traffic correlation to różne problemy

Warto ich nie mieszać.

Fingerprinting

Analizuje cechy klienta:

Browser
OS
Screen
Fonts
APIs
Configuration

Traffic correlation

Analizuje zachowanie komunikacji:

Timing
Volume
Direction
Burst patterns
Session duration

Oba mechanizmy mogą jednak zostać wykorzystane w szerszym procesie identyfikacji.


Zachowanie użytkownika może być ważniejsze niż kryptografia

Wyobraźmy sobie osobę, która używa Tor bardzo regularnie.

Na przykład:

09:00 → login
09:05 → activity
09:30 → logout

Jeżeli ten sam użytkownik wykonuje podobne działania codziennie, jego zachowanie może tworzyć charakterystyczny wzorzec.

To prowadzi do pojęcia:

Behavioral fingerprint

czyli swoistego „odcisku” zachowania.

Nie musi być to fingerprint techniczny.

Może być to:

kiedy
jak długo
jak często
w jakim rytmie

użytkownik korzysta z usługi.


Czas może być metadanymi

To szczególnie interesujące.

Załóżmy:

User activity
08:03–08:17

oraz:

Account activity
08:04–08:17

Jeżeli takie wzorce powtarzają się przez dłuższy czas, korelacja czasowa może stać się elementem analizy.

Dlatego anonimowość wymaga nie tylko ochrony treści.

Wymaga również ograniczania możliwości powiązania zachowań.


Problem ruchu burstowego

Jednym z ciekawszych zjawisk jest tak zwany burst.

Zamiast ciągłego ruchu:

████████████████

mamy:

███

████████

██

█████

Takie charakterystyczne skoki mogą tworzyć wzorzec.

Jeżeli podobny wzorzec pojawia się w innym miejscu sieci, może być przedmiotem korelacji.


Dlaczego usługi onion są interesujące?

W przypadku usług onion nie ma klasycznego:

Client → Exit → Website

Obie strony komunikują się w ramach infrastruktury Tor.

To zmienia model zagrożenia.

Ale nie oznacza, że wszystkie problemy z metadanymi znikają.

Nadal istnieją:

timing
traffic volume
availability patterns
application behavior
user behavior

Dlatego onion services mają własne problemy bezpieczeństwa.


Hidden Service nie oznacza „niewykrywalny”

To jeden z najbardziej utrwalonych mitów.

Adres .onion może być trudniejszy do powiązania z klasyczną infrastrukturą.

Ale bezpieczeństwo całej usługi może zostać osłabione przez:

  • błędy konfiguracji,
  • błędy aplikacji,
  • wycieki informacji,
  • fingerprinting,
  • błędy operatora,
  • powiązane usługi,
  • błędy OPSEC.

Netbe opisuje ten problem również w materiale Ryzyka wycieku tożsamości – deanonymization w sieci Tor i jak ich unikać.


OPSEC może zniszczyć najlepszą kryptografię

Możemy mieć:

Strong Encryption
+
Tor
+
Secure Browser

ale jednocześnie:

Weak OPSEC

i cały model prywatności może zostać osłabiony.

Przykład koncepcyjny:

Anonymous Account
        +
Same Writing Style
        +
Same Activity Hours
        +
Same External Identity

Każdy element osobno może niewiele znaczyć.

Razem może powstać silniejszy sygnał.


Korelacja wielu źródeł

Współczesna analiza nie musi ograniczać się do jednego strumienia danych.

Możemy mieć:

Network Data
+
OSINT
+
Blockchain
+
Account Activity
+
Infrastructure

następnie:

Correlation
      ↓
Graph
      ↓
Hypothesis

To właśnie jest podejście wieloźródłowe.

Netbe opisuje podobny sposób myślenia w artykule OSINT 2026 – jak znaleźć informacje o osobie w internecie.


Blockchain może stać się kolejnym elementem korelacji

Jeżeli analizowany użytkownik lub grupa korzysta z publicznego blockchaina, transakcje mogą dostarczać kolejnych metadanych.

Nie chodzi o to, że blockchain automatycznie „ujawnia Tor”.

Chodzi o możliwość połączenia różnych klas informacji:

Network Activity
        +
Blockchain Activity
        +
OSINT

Jeżeli czasowo i behawioralnie dane wykazują zależności, mogą stanowić dodatkowy element analizy.

Netbe rozwija ten temat w artykułach:

Blockchain jako narzędzie deanonymizacji Darknetu

oraz:

Śledzenie transakcji na blockchainie w celu wykrycia scamów na darknet markets.


Czy VPN rozwiązuje problem?

To jeden z najczęstszych mitów.

VPN może zmienić punkt, z którego operator sieci widzi połączenie.

Ale nie jest magiczną warstwą anonimowości.

Schemat:

User
 ↓
VPN
 ↓
Tor

nie oznacza automatycznie:

Perfect anonymity

VPN staje się po prostu kolejnym elementem modelu zaufania.

Netbe omawia ten problem w artykule Czy VPN naprawdę ukrywa użytkownika?.


Tor kontra I2P

Warto również pamiętać, że Tor nie jest jedynym systemem anonimowej komunikacji.

Istnieje również I2P.

Oba projekty mają inne założenia i architekturę.

Netbe szczegółowo porównuje je w artykule Anonimowe przeglądanie internetu – jak działają sieci Tor i I2P.

Dla analityka oznacza to jedno:

nie należy traktować wszystkich sieci anonimowych jako identycznych.


Czy da się całkowicie wyeliminować traffic analysis?

To bardzo trudny problem.

Można próbować stosować mechanizmy takie jak:

  • padding,
  • opóźnienia,
  • mieszanie ruchu,
  • generowanie dodatkowego ruchu,
  • bardziej zaawansowane protokoły anonimowości.

Ale pojawia się kompromis.

More privacy
     ↓
More overhead
     ↓
Lower performance

Jeżeli system będzie generował bardzo dużo sztucznego ruchu, może być bezpieczniejszy pod względem korelacji, ale jednocześnie mniej wydajny.


Prywatność kontra wydajność

To jeden z podstawowych problemów systemów anonimowych.

Możemy przedstawić go jako trójkąt:

        PRIVACY
          /\
         /  \
        /    \
 PERFORMANCE —— USABILITY

Poprawa jednego parametru często wpływa na pozostałe.

Dlatego projektowanie anonimowych sieci jest przede wszystkim problemem inżynierskim.

 

Korelacja ruchu w Tor – jak można deanonymizować użytkownika bez łamania szyfrowania
Korelacja ruchu w Tor – jak można deanonymizować użytkownika bez łamania szyfrowania

Dlaczego nie wystarczy „więcej szyfrowania”?

Ponieważ:

Encryption

i:

Anonymity

to nie są synonimy.

Szyfrowanie chroni przede wszystkim:

Content

Anonimowość próbuje chronić:

Identity
Relationships
Metadata

A prywatność obejmuje jeszcze więcej:

Identity
+
Behavior
+
Metadata
+
Content

Dlatego można mieć bardzo silne szyfrowanie i jednocześnie słabą anonimowość.


Największym problemem jest model przeciwnika

To jeden z najbardziej technicznych aspektów całego zagadnienia.

Pytanie nie powinno brzmieć:

„Czy Tor jest bezpieczny?”

Lepiej zapytać:

„Przed kim Tor ma chronić użytkownika?”

Przed:

ISP

to inny problem niż przed:

website

Jeszcze inny niż przed:

local attacker

a zupełnie inny niż przed:

global passive adversary

Bez określenia przeciwnika trudno mówić o „anonimowości” w sposób absolutny.


Tor jest systemem probabilistycznym z punktu widzenia analityka

W praktyce analiza może prowadzić do:

P(User A = Source B) = 0.72

a nie:

User A = Source B

To fundamentalna różnica.

Analityka ruchu często tworzy:

Probability

a nie:

Certainty

Dlatego poważne śledztwa wymagają korelacji wielu niezależnych dowodów.


Najciekawsze jest połączenie różnych metod

Wyobraźmy sobie:

Traffic Correlation
        ↓
Candidate
        +
OSINT
        +
Blockchain
        +
Infrastructure
        +
Behavior

Jeżeli wszystkie elementy wskazują podobny kierunek, hipoteza staje się znacznie mocniejsza.

To właśnie różni profesjonalną analizę od internetowego „namierzania IP”.


Co naprawdę oznacza deanonymizacja?

Deanonymizacja nie zawsze wygląda jak:

Tor user
   ↓
IP address
   ↓
Name

Znacznie częściej proces jest wieloetapowy:

Observed Activity
      ↓
Traffic Pattern
      ↓
Correlation
      ↓
Candidate
      ↓
Additional Data
      ↓
Identity Link

Właśnie dlatego współczesna deanonymizacja jest bardziej problemem korelacji danych niż pojedynczego „hacka na Tor”.


Darknet i traffic analysis

W kontekście Darknetu problem jest szczególnie interesujący.

Darknetowe usługi mogą wykorzystywać:

Tor
I2P
Cryptocurrency
Encrypted Communication
Anonymous Accounts

Każda warstwa ma chronić inną część infrastruktury.

Ale jeżeli kilka warstw zostanie połączonych w analizie:

Network
+
Behavior
+
Blockchain
+
OSINT

można uzyskać znacznie szerszy obraz.

To właśnie dlatego nowoczesne śledztwa cybernetyczne coraz częściej przypominają analizę grafową.


Najważniejsza lekcja dla użytkownika

Największym błędem jest myślenie:

„Używam Tor, więc jestem niewidzialny.”

Poprawniejsze stwierdzenie brzmi:

„Tor utrudnia określone rodzaje śledzenia, ale anonimowość zależy również od sposobu korzystania z sieci, aplikacji, zachowania użytkownika i modelu przeciwnika.”

To ogromna różnica.


Co warto zapamiętać?

1. Tor nie musi zostać złamany

Analiza może działać na metadanych.

2. Szyfrowanie nie ukrywa wszystkich wzorców

Czas i rozmiar ruchu mogą nadal mieć znaczenie.

3. Korelacja jest statystyczna

Nie oznacza automatycznie identyfikacji.

4. Model przeciwnika ma ogromne znaczenie

Lokalny obserwator i globalny obserwator to dwa zupełnie różne scenariusze.

5. OPSEC jest równie ważny jak technologia

Błąd użytkownika może osłabić nawet bardzo dobrą architekturę.

6. OSINT może uzupełniać analizę sieciową

Pojedynczy sygnał może być słaby, ale kilka niezależnych sygnałów może tworzyć mocniejszy obraz.

7. Blockchain jest kolejną warstwą danych

Publiczna historia transakcji może dostarczać informacji do dalszej korelacji.


Podsumowanie

Tor pozostaje jednym z najważniejszych narzędzi ochrony prywatności w Internecie, ale nie należy mylić anonimowego routingu z absolutną niewidzialnością.

Najciekawszym zagrożeniem nie jest koniecznie złamanie kryptografii.

Może nim być korelacja informacji.

Traffic
+
Timing
+
Volume
+
Behavior
+
OSINT
+
Blockchain

połączone razem mogą pozwolić analitykowi stworzyć hipotezę dotyczącą powiązań pomiędzy pozornie anonimowymi aktywnościami.

Dlatego współczesna deanonymizacja coraz częściej wygląda nie jak:

„złamaliśmy Tor”

ale jak:

dane
 ↓
korelacja
 ↓
wzorzec
 ↓
hipoteza
 ↓
kolejne dane
 ↓
atrybucja

I właśnie to jest najważniejsza rzecz, którą trzeba zrozumieć, analizując bezpieczeństwo Darknetu.

Najsilniejszą bronią przeciwko anonimowości nie zawsze jest złamanie szyfrowania. Czasami wystarczy możliwość obserwowania wystarczająco dużej liczby metadanych i umiejętność połączenia ich w jeden spójny obraz.

Powiązane artykuły Netbe

 

Polecane wpisy
Aktualizacja BIOS płyty głównej w laptopie
Aktualizacja BIOS płyty głównej w laptopie

Aktualizacja BIOS płyty głównej w laptopie BIOS to podstawowe oprogramowanie układowe, które ładuje się przed systemem operacyjnym i odpowiada za Czytaj dalej

Wi-Fi 7 – Specyfikacja i Nowe Możliwości Najnowszego Standardu Sieci Bezprzewodowej
Wi-Fi 7 – Specyfikacja i Nowe Możliwości Najnowszego Standardu Sieci Bezprzewodowej

Wi-Fi 7 – Specyfikacja i Nowe Możliwości Najnowszego Standardu Sieci Bezprzewodowej Wprowadzenie do Wi-Fi 7 Wi-Fi 7, znane również jako Czytaj dalej

Marek "Netbe" Lampart Inżynier informatyki Marek Lampart to doświadczony inżynier informatyki z ponad 25-letnim stażem w zawodzie. Specjalizuje się w systemach Windows i Linux, bezpieczeństwie IT, cyberbezpieczeństwie, administracji serwerami oraz diagnostyce i optymalizacji systemów. Na netbe.pl publikuje praktyczne poradniki, analizy i instrukcje krok po kroku, pomagając administratorom, specjalistom IT oraz zaawansowanym użytkownikom rozwiązywać realne problemy techniczne.